On 29 November 2014 at 12:14, Andrey Pokhilko <a...@ya.ru> 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
