Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5479B8B8.9010301@ya.ru>
References: <5479B8B8.9010301@ya.ru>
Date: Sat, 29 Nov 2014 13:06:44 +0000
Message-ID: 
 <CAOGo0VbiP2EgeD6RD-LeNta3R8Df7U6ciGSE2-VsGWFsCws8gg@mail.gmail.com>
Subject: Re: Introduce connect times for SampleResult?
From: sebb <sebbaz@gmail.com>
To: dev@jmeter.apache.org
Content-Type: text/plain; charset=UTF-8

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
>