Bug 52333

Summary:	Reduce overhead in calculating SampleResult#nanoTimeOffset
Product:	JMeter - Now in Github	Reporter:	Sebb <sebb>
Component:	Main	Assignee:	JMeter issues mailing list <issues>
Status:	RESOLVED FIXED
Severity:	enhancement
Priority:	P2
Version:	2.5.1
Target Milestone:	---
Hardware:	PC
OS:	All

Description Sebb 2011-12-14 17:57:13 UTC

When using System.nanoTime(), the SampleResult ctors calculate the current offset from currentTimeMillis().

This was previously done just once when the class was initialised, but this was found to cause problems because of drift - see Bug 51855.

Consider using a background thread to calculate the offset, rather than calculating it for each sample - this should reduce the overhead for high sample rates. So long as the time between refreshes is kept reasonably low, drift should not be sufficient to cause an issue.

Comment 1 Sebb 2011-12-14 19:55:00 UTC

Note: it looks like Thread.sleep() returns to the thread shortly after a clock transition (as might be expected).

Calculating the nanoTime offset immediately afterwards should ensure more consistent values.

With the current implementation - which may call currentTimeMills at any point in the clock cycle - the granularity of currentTimeMillis (generally 10ms-15ms) means that the offset can vary by that amount.

Comment 2 Sebb 2011-12-17 00:17:01 UTC

URL: http://svn.apache.org/viewvc?rev=1215361&view=rev
Log:
Bug 52333 - Reduce overhead in calculating SampleResult#nanoTimeOffset
Use a background thread to calculate the offset instead of doing it each sample

Modified:
   jmeter/trunk/bin/jmeter.properties
   jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java
   jmeter/trunk/test/src/org/apache/jmeter/samplers/TestSampleResult.java
   jmeter/trunk/xdocs/changes.xml
   jmeter/trunk/xdocs/usermanual/listeners.xml

Comment 3 The ASF infrastructure team 2022-09-24 20:37:48 UTC

This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2679