|Name or label
A "simple" transaction. For HTTP, these are GET
transactions without such complications as If-Modified-Since (IMS) header,
Range header, redirects, aborts, etc. A basic transaction may still be
involved in complex phenomena such as SSL encrypted connections.
A response that, according to HTTP rules, may be
cached by the DUT.
Something optional that Polygraph has offered to
the DUT. It applies to things like HTTP requests for possibly cached by the
proxy objects and SSL sessions that the proxy may be able to resume.
An cache-friendly request for a previously
requested cachable object. Whether the proxy can or will serve that request
from its cache is unknown to Polygraph -- Polygraph is only "offering" the
proxy to save resources and serve something from the proxy cache. A
hypothetical omnipotent proxy with an infinite cache should be able to satisfy
all offered hits from its cache, achieving perfect hit ratio (reported as
The opposite of offered.hit: A transaction
with a request that is not cache-friendly, for a previously unseen object,
and/or for an uncachable object. Due to normal HTTP race conditions among
concurrent transactions, it is possible for DUT and Polygraph's idea of "seen"
to occasionally differ, even without HTTP violations.
In lx context, a response that was probably delivered
from the DUT cache rather than from Polygraph server. Polygraph uses HTTP
extension headers to collect hit-related statistics during a test. Comparing
client- and server-side transaction counters (after the test) is a different
way of measuring hit ratios. See also: offered.hit.
The opposite of hit: The received response most likely
came from the origin server during this transaction. See also:
Byte hit ratio (BHR): 100 * hit.size.sum /
(hit.size.sum + miss.size.sum). See also: hit.ratio.obj.
Document hit ratio (DHR): 100 *
hit.size.count / (hit.size.count + miss.size.count). See also:
cachable miss. Fill transactions populate DUT cache,
if any. See also: cachable and miss.
Total transaction response time, including all steps
such as DNS resolution, TCP connection establishment, sending request headers,
and receiving the entire response body. Please note that many steps may
overlap in time and some are optional. The timer starts when Polygraph agent
starts working on the transaction and ends when the same agent completes the
transaction. There is one known exception: The time spent in the robot queue
waiting for an open connection slot (see open_conn_lmt) is currently
Client-reported response time is meant to represent an end-user perceived
delay. A DUT, especially a busy one, often measures response time differently
because it does not (and cannot) account for such things as the time it takes
the DUT the notice the request in its incoming queue. Similarly, the
server-side reported response time usually differs from client-side reported
time, especially if the DUT is slow and/or there are hits.
Transaction triggered by receiving a redirect
response (e.g., a request for the Location URI in an HTTP 302 Found response).
See also: rep_to_redir.
An HTTP response with 300, 302, 203, or 307
status code (e.g., HTTP 302 Found). See also: redired_req.
Polygraph robot or server agents (as in "the phase
script increased robot population by 5%")
Polygraph robot or server agents activated
during the reported interval. See also: X.level.mean
A transport connection and the associated network
socket. Currently, Polygraph only supports TCP connections. Multiple HTTP
transactions may use a single HTTP/TCP connection.
Transport connections with open file descriptors. See also:
conn.estab and X.level.mean.
Transport connections that the operating system
declared ready for I/O at least once. See also: conn.open and
Total duration (Time To Live) of a transport
connection (from open to close). See also: conn.open and
The total number of protocol transactions
initiated on a connection. For example, in HTTP tests without persistent
connections, conn.use.max cannot exceed 1. See also: conn.ttl and
The average number of concurrent
connections in state X during the reported interval. See also:
conn.use for connections that were
closed when they were not idle. See also: conn.use and
Duration of connections that were
closed when they were not idle. See also:
Response status code (e.g., HTTP 200 OK)
received by a robot or, if you are looking at the Polygraph server statistics,
sent by a server.
A transaction that either started or
continued a yet-unfinished multi-transaction authentication process.
Some HTTP authentication schemes (e.g., Negotiate) require several message
exchanges before the request is considered "authenticatED".
No authentication. Neither authenticatING nor
The number of individual transactions
or "exchanges" per compound transaction of type X. Compound transactions
consist of several individual transactions (e.g., an HTTP CONNECT followed by
a GET inside a tunnel established by the first CONNECT).
A single individual transaction not
inside any compounded transaction. In other words, this is a degenerate case
of a compounded transaction consisting of a single individual
Successful transactions. See also: err_xact.
Unsuccessful transactions (these should be
reported as errors in Polygraph console logs, but not all reported errors are
transaction errors because some errors can be bypassed or retried, leading to
an overall successful transaction). See also: ok_xact.
Transaction error ratio: 100 *
err_xact.count / (ok_xact.count + err_xact.count).
Failed transactions that were
The total number of X measurements taken or X
events seen. See also: X.mean.
The total sum of X values. See also: X.mean.
An arithmetic mean: X.sum/X.count.
the number of X
created/opened/initiated. See also: X.finished and X.level.
the number of X
destroyed/closed/stopped/completed. See also: X.started and X.level.
the number of X at the end of the reporting
interval. See also: X.started and X.level.mean.
the average level of X during the reporting
interval. See also: X.started and X.level.last.