Am 11.05.2018 um 15:23 schrieb Mark Thomas:
On 11/05/18 10:17, Rainer Jung wrote:
Running the unit tests for trunk on my relatively slow Solaris machine,
two of the performance tests run especially long:
javax.websocket.TestContainerProviderPerformance: about 25 minutes per
org.apache.jasper.runtime.TestTagHandlerPoolPerformance: about 5 minutes
These are both intended to be run outside of the unit tests. They are
they to check performance when experimenting with different approaches.
I'd suggest renaming them to Tester... so they are not included in the
That would at least scratch my itch :)
For the sake of consistency: the following trunk tests are of type
Performance.java but use the "Test" naming instead of "Tester" (longest
Test Duration(ms) on slow machine
The ones marked with "*" do not contain any test assertion, the ones
with "+" have at least one. Any of these 5 tests that you would put into
the same "Tester" reasoning (intended to be run outside of the unit tests)?
Alternatively at least for TestOneLineFormatterPerformance we could add
a speed comparison assertion for the two implementations that this test
measures. On my slow machine, the faster impl is 10 times as fast, so an
expected factor of 2 might be safe to test against, at least worth a try.
Thanks and regards,
I know that I can disable all performance tests using
test.excludePerformance, but apart from those two all others run
In test/javax/websocket/TestContainerProviderPerformance.java, there's
an iteration count, currently 250000. Is there a special reason, why it
is so high? Would fast machines still generate a reasonable test result
with something much smaller, like e.g. 10000? Phrased differently: how
fast does that test currently run on your machine?
The other test,
an iteration count of 5000000 and at least on my 2 core test system
doesn't scale well. It takes "just" 5 minutes, but still the question
is, whether we could lower the iteration count maybe to 1000000 without
making the test useless?
Note that the tests seem to not have any success or failure assertion.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org