jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <>
Subject Re: Introduce connect times for SampleResult?
Date Wed, 03 Dec 2014 14:15:43 GMT
Happened to be not so much work:

Please, review it and point me at any changes needed.

Andrey Pokhilko

On 11/29/2014 04:06 PM, sebb wrote:
> On 29 November 2014 at 12:14, Andrey Pokhilko <> wrote:
>> Hi,
>> Many times I see a sence to have connect times measured separately, in
>> addition to latency that we have in SampleResult. It is important when
>> measuring a time for SSL handshake and DNS resolving, when users want to
>> see it separate share in total Response Time.
>> Connect time is available as separate metric in Grinder and Yandex.Tank.
>> The latter has following details on response time pars: connect, send,
>> latency, receive. Sometimes some parts are zero, but at least there is a
>> technical possibility to see when it is non-zero. It should be noted
>> that full breakdown would be: dns, connect, send, latency, receive.
>> Send and receive times are not of great importance, IMO. And I would
>> cope with connect time including DNS resolve time. But having connect
>> time would add interesting aspect on results.
> [I expect DNS resolve time might be very tricky to measure in Java]
>> For implementation it will require adding one more property with getters
>> and setters to SampleResult, modifying SampleSaveConfiguration and UI
>> settings to configure saving, using this new field in HTTP sampler, TCP
>> sampler, maybe there are other samplers that can respect this field.
> The docs would need to be updated to state whether a sampler supports
> the metric or not.
>> As separate question I would raise if latency should not include connect
>> time, for me it sounds logical, but changes existing behavior.
> Connect time is currently included in both latency and elapsed.
> The simplest would be to just add connect as a separate time, but not
> subtract it from latency or elapsed.
> This would allow further analysis without changing behaviour.
> Maybe add an option to perform the subtraction.
> I don't think we should change the default behaviour.
>> Any opinions?
> I can see its use and am not against it, but it needs quite a lot of
> work to implement fully.
>> --
>> Andrey Pokhilko

View raw message