No, it is not committed into SVN, you'll need to build it from the sources.
Andrey Pokhilko On 12/04/2014 07:07 PM, Shmuel Krakower wrote: > 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 >>>> >>
