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 Sat, 29 Nov 2014 21:42:29 GMT
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" <philippe.mouawad@gmail.com>
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/dev@jmeter.apache.org/msg03444.html
>
> AFAIK, only Milamber gave some feedback.
>
> Regards
> Philippe
>
> On Sat, Nov 29, 2014 at 2:06 PM, sebb <sebbaz@gmail.com> 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
> > >
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

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