This page describes lx output. The lx tool extracts raw measurements from Polygraph binary logs. Other than merging logs, lx performs very little statistical analysis and formatting. Its JSON-like output is intended mostly for automated processing and quick checks by humans. For a human-friendly alternative, see the reporter tool.
1. Measurement units
2. Simple measurements
Unless stated otherwise, lx uses the following measurement units:
Measurement Unit transaction time milliseconds (ms) interval time seconds (s) event rate events per second (1/s) size bytes (B) ratio percents (%)
The ugly table below documents some of the one-line measurements reported by lx.
Name or label Meaning basic
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.
cachable uncachable offered offered.hit
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 offered.hit.ratio).
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.
miss hit.ratio.byte hit.ratio.obj fill rptm
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 not counted.
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.
redired_req rep_to_redir populus populus.started conn conn.open conn.estab conn.ttl conn.use
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 conn_close.busy.use.
conn.X.level.mean conn_close.busy.use conn_close.busy.ttl resp_status_code authenticating
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".
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).
compound.auth.not ok_xact 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.
err_xact.ratio retr_xact X.count X.sum X.mean X.started X.finished X.level.last X.level.mean