On 29 November 2014 at 12:14, Andrey Pokhilko <[email protected]> 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 >
