Make Jmeter able to support nanoseconds for testing and reporting

[junyejiang]

In my test experience, when the performance of the system under test is much too fast (for example, when testing Redis), the milliseconds is too large to reflect the performance of the system under test, so the following changes are made:

1. Change the unit of Jmeter Result from milliseconds to nanoseconds.
2. Statistical calculations use BigDecimal/BigInteger to make the statistical results more accurate and no overflow.
3. The test report uses ms/ns as the final output unit according to the Properties configuration.

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• [ ] My code follows the code style of this project.
• [ ] I have updated the documentation accordingly.

[junyejiang]

I have not checked the way the report works, however, I have a few comments:

1. Have you checked sampleresult.useNanoTime JMeter property? If so could you describe why the property is not enough for you?
2. Please refrain from modifying the existing tests. In most cases, if you modify an existing test it means you break backward compatibility which is unwanted.
3. Please create new tests for the feature you add
4. Please refrain from combining multiple unrelated changes into a single commit. I think the change of double -> BigDecimal should be discussed and measured separately

1. Yes I did tried sampleresult.useNanoTime, and finally find out that report was still in ms, this property will not help.
2. My PR do break backwark compatibility, as the former JTL file was stored in ms format, My PR will change it to ns format. So that the former tests wold not pass until updated.
3. The same as Q2
4. Changes in calculators from Long to BigDecimal is because, firstly every test timestamp is 1 million bigger than before so Long could be easily overflow during accumulation; secondly BigDecimal/BigInteger is more precise than Long in calculation.

[vlsi]

My PR do break backwark compatibility, as the former JTL file was stored in ms format, My PR will change it to ns format. So that the former tests wold not pass until updated.

I am afraid we can't merge such PRs then. We can't break everybody's workflows when releasing a new version.

[junyejiang]

My PR do break backwark compatibility, as the former JTL file was stored in ms format, My PR will change it to ns format. So that the former tests wold not pass until updated.

I am afraid we can't merge such PRs then. We can't break everybody's workflows when releasing a new version.

Understood. Thanks.

[vlsi]

It would be great if we could support both formats at the same time, however, keeping the old scripts workable and old files parseable is important

[ra0077]

+1 to have the support of both formats

[junyejiang]

It would be great if we could support both formats at the same time, however, keeping the old scripts workable and old files parseable is important

I will try to make it. Reopen this PR

[junyejiang]

@vlsi https://github.com/apache/jmeter/commit/fd12dc39aa688011475c7466cb7c1a2e1f43e38f Made following changes:

1. Introduced new metadatas in csv, jtl and xml, these metadatas are dedicated to store ns timestamp, old metadatas are untouched. When Jmeter loads csv, jtl or xml, it tries to read and load ns timestamp first if possible, otherwise it goes the old fasioned way.
2. Added new setter functions in SampleResult.java, these functions are ns timestamp related only, original constructors and factory funcions are untouched.

Above 2 changes are for backward compability.

3. Renamed ns/ms key in reportgenerator.properies.
4. Added test to check my changes.

If my PR is not accepted finally some how, I still suggest to update in calculators from Long to BigInteger/Bigdecimal, which brings better precision and will not cause overflow.