Web Polygraph 

    Reference Manual
       Simulation models
       Command options
       User-defined distr
       Loadable modules
·         Lx
    User Manual


    Wish List
    Mailing List

    Other Tools


Home · Search · Print · Help 

Lx output

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.

Table of Contents

1. Measurement units
2. Simple measurements
3. Histograms

1. Measurement units

Unless stated otherwise, lx uses the following measurement units:

transaction timemilliseconds (ms)
interval timeseconds (s)
event rateevents per second (1/s)
sizebytes (B)
ratiopercents (%)

2. Simple measurements

The ugly table below documents some of the one-line measurements reported by lx.

Name or label Meaning

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.


Not cachable.


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 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.


The opposite of hit: The received response most likely came from the origin server during this transaction. See also: offered.miss.


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: hit.ratio.byte.


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 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.


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 X.level.mean.


Total duration (Time To Live) of a transport connection (from open to close). See also: conn.open and X.level.mean.


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.


The average number of concurrent connections in state X during the reported interval. See also: X.started


conn.use for connections that were closed when they were not idle. See also: conn.use and conn_close.busy.ttl.


Duration of connections that were closed when they were not idle. See also: conn_close.busy.use.


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 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).


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 transaction.


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 retried.


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.

3. Histograms


Home · Search · Print · Help