On 29 November 2014 at 20:05, Philippe Mouawad <[email protected]> wrote: > Hi, > Interesting, +1 for me. > > By the way it would be nice to have some opinion from all dev team on this: > - https://www.mail-archive.com/[email protected]/msg03444.html
Please don't mix unrelated items in the same e-mail. > AFAIK, only Milamber gave some feedback. If you want more feedback, please add to the original thread. > Regards > Philippe > > On Sat, Nov 29, 2014 at 2:06 PM, sebb <[email protected]> wrote: > >> 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 >> > >> > > > > -- > Cordialement. > Philippe Mouawad.
