Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAH9fUpYZGU9FZSkv437udGJ+xhNbdPrHHh85rpR+aE30bD9+6g@mail.gmail.com>
References: <5479B8B8.9010301@ya.ru>
	<CAOGo0VbiP2EgeD6RD-LeNta3R8Df7U6ciGSE2-VsGWFsCws8gg@mail.gmail.com>
	<CAH9fUpYZGU9FZSkv437udGJ+xhNbdPrHHh85rpR+aE30bD9+6g@mail.gmail.com>
Date: Sun, 30 Nov 2014 17:45:59 +0000
Message-ID: 
 <CAOGo0VbZqYDWhkCjqFU4X1L10rLG27m2p-3vaEx82USXHDumhg@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 20:05, 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

Please don't mix unrelated items in the same e-mail.

> AFAIK, only Milamber gave some feedback.

If you want more feedback, please add to the original thread.

> 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.