I've finally had some time to get the new APR Connector compiled on my Solaris box, and my initial 'ab' tests seem to show that the Http11Protocol wins. I can see if I can get some time to do better tests next week.
ab is great for measuring throughput, and that's it. This matches (to some extent) my (bad localhost) benchmarks with ab, where I got around - 20-25%. This is (by far) the worst situation, however. Mladen apparently got better results on Linux (which would be cool, because from what I've seen most production Tomcats run on Linux).
APR does very well when not using keepalive (reminding that the cool object allocation when using the regular IO API is *not cool*), but there must be a problem transferring bytes. Or I did something really stupid that I missed (I didn't profile anything yet).
There will be large benefits when:
- serving large files (BTW, can you determine the optimal minimal sendfile size on your platfrom ? Thanks)
- using a somewhat realistic test (connections being closed sometimes, and having non zero keepalive times between requests)
The test consists of running 'ab' from an XP box like: ab -n 1000 -c 300 -k http://myserver:8080/tomcat.gif Except for the maxThreads noted below, the Tomcat settings are simply the default ones.
The results for Http11AprProtocol (with maxThreads = 150): Concurrency Level: 300 Time taken for tests: 19.281250 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 1000 Total transferred: 2164000 bytes HTML transferred: 1934000 bytes Requests per second: 51.86 [#/sec] (mean) Time per request: 5784.375 [ms] (mean) Time per request: 19.281 [ms] (mean, across all concurrent requests) Transfer rate: 109.59 [Kbytes/sec] received
The results for Http11Protocol (with maxThreads = 350) Concurrency Level: 300 Time taken for tests: 13.515625 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 1000 Total transferred: 2164000 bytes HTML transferred: 1934000 bytes Requests per second: 73.99 [#/sec] (mean) Time per request: 4054.688 [ms] (mean)
The latency's too high. 300 concurrency with ab is probably never a good idea.
Time per request: 13.516 [ms] (mean, across all concurrent requests) Transfer rate: 156.34 [Kbytes/sec] received
Keeping the maxThread count low is the only way I can keep Apr alive at all: It fails with OutOfMemoryErrors if I give it 350 threads.
I don't know about that, but I think since the threads will be actually doing stuff, anything over 200/core would probably be a bad idea. Does increasing the VM memory / perm size fix the problem ?
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
