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:

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

A response that, according to HTTP rules, may be cached by the DUT.

uncachable

Not cachable.

offered

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.

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

offered.miss

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.

hit

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

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

hit.ratio.byte

Byte hit ratio (BHR): 100 * hit.size.sum / (hit.size.sum + miss.size.sum). See also: hit.ratio.obj.

hit.ratio.obj

Document hit ratio (DHR): 100 * hit.size.count / (hit.size.count + miss.size.count). See also: hit.ratio.byte.

fill

cachable miss. Fill transactions populate DUT cache, if any. See also: cachable and miss.

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

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.

rep_to_redir

An HTTP response with 300, 302, 203, or 307 status code (e.g., HTTP 302 Found). See also: redired_req.

populus

Polygraph robot or server agents (as in "the phase script increased robot population by 5%")

populus.started

Polygraph robot or server agents activated during the reported interval. See also: X.level.mean

conn

A transport connection and the associated network socket. Currently, Polygraph only supports TCP connections. Multiple HTTP transactions may use a single HTTP/TCP connection.

conn.open

Transport connections with open file descriptors. See also: conn.estab and X.level.mean.

conn.estab

Transport connections that the operating system declared ready for I/O at least once. See also: conn.open and X.level.mean.

conn.ttl

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

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

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

conn_close.busy.use

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

conn_close.busy.ttl

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

resp_status_code

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.

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

auth.none

No authentication. Neither authenticatING nor authenticatED.

compound.X.exchanges

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

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.

ok_xact

Successful transactions. See also: err_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

Transaction error ratio: 100 * err_xact.count / (ok_xact.count + err_xact.count).

retr_xact

Failed transactions that were retried.

X.count

The total number of X measurements taken or X events seen. See also: X.mean.

X.sum

The total sum of X values. See also: X.mean.

X.mean

An arithmetic mean: X.sum/X.count.

X.started

the number of X created/opened/initiated. See also: X.finished and X.level.

X.finished

the number of X destroyed/closed/stopped/completed. See also: X.started and X.level.

X.level.last

the number of X at the end of the reporting interval. See also: X.started and X.level.mean.

X.level.mean

the average level of X during the reporting interval. See also: X.started and X.level.last.

3. Histograms

TBD.