This section ... is under construction ...
The statistics reported by webclient
are basically the same
as those reported by webmon
with the following major difference.
Statistics reported by webclient
are based on each page fetched
(including the gifs), whereas statistics reported by webmon
are based on each HTTP request. Thus, for login, webclient
will report the total time to fetch the html page and its
related gifs, whereas webmon
will report the time to fetch
the page and the time to fetch each gif. Since webmon
sits
between the browser and the server, webmon basically does
not know when requests related to this page end and requests
related to the next page begin. (Well, it can make a pretty
good guess as to when this occurs, but the current version
of webmon
does not do this). Also webclient
will treat
a redirect as being part of a request, while webmon
treats
a redirect as new and unrelated request.
With this distinction in mind, here is the description of
the statistics that webclient
prints:
elapsed time from just before the TCP/IP connection to the server, until last byte of data for the last gif is received. This time includes that needed for redirects, SSL negotiation, and SSL encryption/decryption. The time needed to resolve a server address is *not* included. (Since DNS/YP/resolv.conf name resolution tends to be highly variable and subject to OS caching, and a variety of other "noisy" factors).
time from first connect until the last byte of html data is received. Redirects are processed and counted as part of the delay.
sum of times (over all gifs fetched) from connect through last data byte.
the amount of idle time spend between the end of the request, and the dispatch of the next request. This statistic is useful to find out what the actual think times were for a run. This is useful when using a randomized think time, because the actual average will never exactly equal the requested average (although would eventually get close). That is, if a 60 second think time is requested, the actual average think time might come out to be 58.27 or 60.835 after statistical variation.
the sum, more or less, of the response time plus the think time. The sum is not exact because the request time is measured from before that start of the request, until after the end of the think period, while the response times are measured at the socket level, and do not include much of the client overhead.
The sum of html and gif times equals the total response time; that is, response_times = html_response_time + gif_response_time
time from first connect until first message containing html body data arrives. If a file is redirected, the first data response timer does not stop until the first message containing body data in the first non-redirected file is received.
sum of time required to establish a connection with the host, summed over all files fetched this page. If SSL is enabled, this time includes the SSL connection negotiation. Note that webclient will automatically attempt to reuse SSL session_id handles for all subsequent connects. Webclient will reset the SSL session_id at the end of a webclient session. Thus, typically the very first fetch will take a time (about a second) while the cipher suite is negotiated, while subsequent connects will occur much more quickly (50 to 100 mS) as the SSL session_id is reused.
sum of time required to fetch all headers, timed from just before the first byte of the request is sent, to just after the last byte of the header has arrived.
sum of times required to transfer the bodies of the files (excluding header).
The sum of connect delays, header delays, and transfer times equals the total response time. That is,
response_time = connect_times + header_delays + transfer_times;
If SSL is enabled, the following statistics are also printed:
the time spent in TCP/IP code, sending data, and waiting for responses from the server, summed over all files and gifs/jpegs for this page.
the time spent on the local host in the SSL routines, summed over all files this page. Encryption and decryption can require significant amounts of CPU cycles; this provides a measure of the time spent on the client only.
the time spent in TCP/IP code, sending data, and waiting for response from the server, from connect until the last byte of html on the first non-redirected page is received
the time spent in SSL routines on the client, from first connect until the last byte of html on the first non-redirected page is received
the time spent in TCP/IP code, sending data, and waiting for response from the server, from connect to last byte of data, summed over all gifs fetched this page
the time spent in SSL routines on the client, from connect to end of gif, summed over all gifs this page
time required to do TCP/IP connects, summed over all files this page. This time includes the time needed to create the socket, bind a name to it, and return from the system connect() call. It does *not* include any SSL negotiation time.
time spent in TCP/IP code, sending data, and waiting for responses while negotiating an SSL connection summed over all files this page. This is a measure of how long the SSL negotiation takes, not counting the CPU overhead in the webclient SSL processing code.
time spent in SSL routines on the client, while negotiating an SSL connection, summed over all files this page. This measures the efficiency/performance of the particular SSL implementation used by webclient.
time spent in TCP/IP code, sending data, and waiting for responses while asking for and obtaining the HTTP header, summed over all files this page
time spent in SSL routines on the client, while requesting and receiving the HTTP header, summed over all files this page
time spent in TCP/IP code, sending data, and waiting for responses while transferring the body of the message, summed over all files this page
time spent in SSL routines on the client, while transferring the body of the file, summed over all files this page
The following invariants are true for these statistics:
response_times = net_delay + ssl_ovhd;
html_response_times = html_net_delay + html_ssl_ovhd;
gif_response_times = gif_net_delay + gif_ssl_ovhd;
connect_times = tcp_connect_times + ssl_connect_ovhd + ssl_net_delay_connect;
header_delays = ssl_header_ovhd + ssl_net_delay_header;
transfer_times = ssl_transfer_ovhd + ssl_net_delay_transfer;
When an SSL connection is first established, a negotiation is performed so that the client and server can agree on private keys to use for the selected encryption algorithm. This negotiation uses public key encryption and is hence, quite slow. Once this negotiation has been performed, subsequent HTTP requests from the client to that same server use a cached session ID to reestablish the connection.
Hence, we would expect the first connect times to be larger than subsequent connect times. To make sure that the connect times from each repetition of a session are comparable, the SSL session_id is discarded at the end of each execution of the session and it must be renegotiated at the time of the next logon.
Summary statistics for a collection of URL's can be obtained by using the <<MARK>> keyword to delimit a block of URL's. Thus, for example, the input file
<<START>>
GET /pageone.html
GET /pagetwo.html
<<MARK>>
GET /pagethree.html
GET /pagefour.html
GET /more.html
<<MARK>>
GET /another.html
GET /andmore.html
<<MARK>>
GET /last.html
<<END>>
will print statistics not only for each to the individual URL's, but also for four "blocks": The first two URL's combined, then the next three, combined, then the next two, and the final lone URL.
Although webclient is designed to run a series of sessions, and then
compute statistical timing information from the resulting measurements,
information about each individual transaction can be printed out.
The -x
flag will cause request timestamps to be printed; the -e
flag
will cause per-request broken-down statistics to be printed.
The -x
flag causes timestamps signifying the beginning and end of each
transaction are printed into the report file. The timestamps are in
the form of floating point numbers, representing seconds since the
beginning of the epoch Jan 1,1970
The actual format is as follows:
TPUT <<START>> try="try" date = "session_start_date"
TPUT <URL> try="try" req="nreq" url = "url"
TPUT <START> try="try" req="nreq" date= "request_start_date"
TPUT <END> try="try" req="nreq" date= "request_completion_date"
TPUT <SKIP> try="try" req="nreq"
TPUT <OBS> try="try" req="nreq" datum="obs_name" value="value"
TPUT <<END>> try="try" date = "session_completion_date"
TPUT <<INTERRUPTED>>
where:
try is number of the session trial,
nreq is the number of the request,
url is the url of the request,
session_start_date is the current date/time just before the
first request is issued,
session_completion_date is the current date/time just after the
response to the last request has been received.
request_start_date is the current date/time just before the URL
is sent to the web server,
request_completion_date is the current date/time just after the last
byte of the last webpage or gif/image associated
with this URL has been received
obs_name is the name of the observed (measured) item
value is the value of the observed item
<<START>> denotes the beginning of a session (trial)
<<END>> denotes the end of a session (trial)
<START> denotes the beginning of a request observation
<END> denotes the end of a request observation
<SKIP> denotes that the indicated request was not issued.
<OBS> delimits a detailed timing observation
<<INTERRUPTED>> denotes that a signal was caught.