Is it part of any nightly yet? I'll give it a try... www.beatsoo.org - free application performance monitoring from world wide locations. On Dec 3, 2014 4:17 PM, "Andrey Pokhilko" <[email protected]> wrote:
> Happened to be not so much work: > https://github.com/apache/jmeter/pull/11/files > > 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 <[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 > >> > >
