On Friday, October 31, 2014, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote:
> Hi, > > I analyze jmeter csv raw results via both jmeter listeners (e.g. > AggregateReport) and build my own reports via r. > > It works pretty much fine, however I faced an issue with transaction > controllers and timers. > > Here's the issue: by default the log (e.g. raw log in csv) does _not_ > include duration of the timers, so there is no way to tell when > transaction finished. > There is a similar problem with regular samplers: it is hard to tell > why there is a gap between two samplers. > > One of my reports is a sequence chart of jmeter transactions with > actions in the system under test, thus I need precise information on > the start and end timestamps. > Gaps between JMeter requests bothers me since I do not know if they > are caused by JMeter or by a bad script or whatever else. > > I've scanned through jmeter.properties and identified that > jmeter.save.saveservice.idle_time=true solves solves the problem to a > certain degree. > With this option, log for transaction controller does report delay time. > However, there still no way to map those delays to the timeline: > individual samplers always show 0 in the "idle time column" > > Can you please clarify: > 1) Why "save idle time" is not enabled by default? Sometimes there is no real explanation, so in recent versions we tried and continue to improve the default settings (for example jmeter.save.saveservice.thread_counts will be saved starting from 2.12) but task is still in progress. But regarding this one I would say that under load test ( once you're sure you don't have issues in your plan you are not interested by this info). So as long as you can change it in user.properties it seems fine to me. Maybe needs to be better documented if it took you some time to find it. 2) Is there an option to enable logging of "preprocessors duration" > and "postprocessors duration" for the samplers? No, it would require a patch. If JMeter could log those timings it might have a good purpose: > identify inefficient regexps, eliminate surprises when analyzing "gaps > in between requests", etc. > > Note that in future 2.12, an important known bug 56160 has been fixed that could create gaps between requests if it was met. Try nightly build if your gaps seem abnormal. > -- > Regards, > Vladimir Sitnikov >
