In a JMeter JTL row, what do the elapsed, Latency and Connect columns each measure?

These three columns are the reason a JTL is worth keeping. A screenshot of a graph tells you a number; the JTL tells you which clock produced it. Getting the three straight is the difference between an evidence file you can still defend six months later and a spreadsheet of numbers nobody can explain. ## One clock, three readings JMeter does not run three timers. It records a single start instant for the sample and then reads the elapsed wall clock at three moments: 1. **`Connect`** — read when the connection has been established. The manual states this includes the SSL handshake, and that on a connection failure the value is the time taken to hit the error, so a connection timeout shows up as roughly the configured connect timeout. 2. **`Latency`** — read just after the first part of the response has been received. The manual notes this therefore covers assembling the request as well as assembling the first chunk of the response, which in practice is more than a single byte. 3. **`elapsed`** — read just after the last part of the response has been received. ## They nest; they do not add up Because all three are measured from the same start, they are cumulative, not three consecutive segments: ``` sample start |<-- Connect -->| |<--------- Latency --------->| |<---------------- elapsed ---------------->| ``` The manual says it outright: *connect time is not automatically subtracted from latency*. If you want the server-side wait, that is `Latency - Connect`; if you want the body-transfer time, that is `elapsed - Latency`. Adding `Connect + Latency + elapsed` produces a number that means nothing, and it is the single most common misreading of this file. ## IdleTime comes out of all three `IdleTime` is time deliberately excluded from a sample, and JMeter subtracts it from each of the three readings — `elapsed` is end minus start minus idle, and both `Latency` and `Connect` are computed the same way. On an ordinary HTTP sample it is `0`; it becomes non-zero where a sample is explicitly paused, which is how JMeter keeps engineered waits from inflating a timing column. ## When a column is legitimately zero - `Connect` is `0` when no connection was opened for that sample — a reused keep-alive connection does no connecting, so there is nothing to time. - `Connect` is `0` for sampler families that never record it at all. - `Latency` can equal `elapsed` when the whole response arrives in one piece. - A parent row that aggregates sub-samples carries an `elapsed` stretched to cover all of them, because the parent's end time is extended to the end of the last child. ## What these columns are not `elapsed` stops at the last response byte. JMeter neither renders the response nor executes JavaScript, so the number is a protocol timing, not a page-load timing. And what you should *do* with a column full of these values — which summary to quote, how tails behave, how to compare offered and achieved rates — is reading-results and percentile material owned by the performance-testing foundations topics, not by the file format. Here the job is narrower and more useful: know exactly which instant each number was taken at, so nobody has to guess later.