In a JMeter results file, why is the Connect column zero on many rows?

`Connect` is the column people quietly delete from a kept results file because they assume it is broken. It usually is not. Understanding when it is legitimately zero is what lets you use the rest of the column as evidence. ## When JMeter writes the number JMeter times the connect step at the point a connection is established, and stores it as milliseconds since the sample started — the same origin as `Latency` and `elapsed`, and with `IdleTime` subtracted the same way. The manual adds two facts that matter for reading a file: - the value **includes the SSL handshake**, so an HTTPS sample's connect covers rather more than a TCP round trip; - connect time is **not** subtracted from latency, so the two columns overlap rather than tile. ## The three honest reasons for a zero 1. **Connection reuse.** The number is only recorded when a connection is opened. A sample served over a connection that was already open never reaches that code, so the field stays at its initial `0`. In a steady-state run with keep-alive in play, most rows look like this and that is the correct answer, not a gap. 2. **The sampler does not record it.** Since JMeter 3.1 the metric is computed for the TCP Sampler, the HTTP Request sampler and the JDBC Request sampler. Other sampler families leave it at zero permanently. 3. **The HTTP implementation.** For HTTP, the timing lives in the HttpClient4 implementation. The shipped `jmeter.properties` marks both `jmeter.save.saveservice.connect_time` and `jmeter.save.saveservice.sent_bytes` with the comment *Only available with HttpClient4*; run the sampler on the Java implementation instead and neither is populated. ## What a non-zero value is telling you | Reading | Likely meaning | |---|---| | `0` on most rows, non-zero on a few | Normal: the few are the samples that opened a connection | | Non-zero on nearly every row | Connections are not being reused | | One large value on an otherwise failed row | A connection error; the value is the time taken to hit it | | Always `0`, every row, every label | Wrong sampler family, or HTTP running on the Java implementation | That third row is the one worth remembering. On a connection failure the metric is set to the time it took to face the error — a connection timeout lands as roughly the configured connect timeout. So a `Connect` column is not just a performance figure; it is a fault signature, and it is one of the few columns that still says something useful about a run whose logs are long gone. ## Before you delete the column - Check the label: is the zero confined to one sampler family? - Check whether the run used the HttpClient4 implementation at all. - Check whether `jmeter.save.saveservice.connect_time` was even on — it defaults to `true`, but a plan's listener can carry its own saved configuration with it off, in which case the column is absent rather than zero, which is a different problem with a different fix. What to conclude from the distribution of connect times across a fleet — whether the pattern indicates a pool that is too small, or a saturation signal — is capacity reasoning owned elsewhere. Here the claim is narrower: know which zeros JMeter writes on purpose.