tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Two especially slow performance tests on trunk
Date Mon, 14 May 2018 08:58:04 GMT
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
>> connector.
>> org.apache.jasper.runtime.TestTagHandlerPoolPerformance: about 5 minutes
>> per connector.
> 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
> user tests.

That would at least scratch my itch :)

For the sake of consistency: the following trunk tests are of type but use the "Test" naming instead of "Tester" (longest 
running first):

Test Duration(ms) on slow machine
*org.apache.juli.TestOneLineFormatterPerformance 80355
+org.apache.catalina.mapper.TestMapperPerformance 16856
+org.apache.catalina.connector.TestResponsePerformance 7233
*javax.servlet.jsp.el.TestScopedAttributeELResolverPerformance 392

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
>> reasonably fast.
>> In test/javax/websocket/, 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,
>> test/org/apache/jasper/runtime/, uses
>> 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.
>> Regards,
>> Rainer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message