jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shmuel Krakower <shmul...@gmail.com>
Subject Re: Introduce connect times for SampleResult?
Date Thu, 04 Dec 2014 16:07:25 GMT
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" <apc4@ya.ru> 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 <apc4@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
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message