I'd also be interested in such a separation. One point which will also need to be addressed is the availability of listeners support for that. I'm unsure of the effort but having native jmeter support in the summary or agg table listeners for the additional connect field (maybe also for the latency) on top of the current response time only, would be must have.
Best www.beatsoo.org - free application performance monitoring from world wide locations. On Nov 29, 2014 10:06 PM, "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 > > AFAIK, only Milamber gave some feedback. > > 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. >
