ab can not put an wait between the keep-alive requests, so basically you are just choking you network throughput and killing keep-alive cons. Since it can not put an wait neither the poller can have a chance to work. When using ab for testing then you should not exceed the maxThreads, because you have a 300 concurrent users doing requests. The trick with APR implementation is by presuming that all connected users will not actually make request concurrently, but let's say from 1000 connected users, only 100 will be doing requests. Presuming something like that we can keep the thread count low while having a large number of connected users.
So to test the performance with ab you should not go over maxThreads. You can use Peter Lin's test plans for JMeter, that simulates the real-life scenario, and see how that behaves. Also an tests the results from Http11Protocol/Http11AprProtocol should be more or less equal, because like side, no chance for a poller to do anything.
Right, good catch, I missed that, so you can disregard some of my previous email :(
With ab, you need maxThreads > c, otheriwise the results will indeed be wrong. We need to find the reason why maxThreads can't go to 300 when using APR :) Any ideas Bill ? At least getting an OOM is a good sign that it could be fixed with the right settings, unlike a VM crash.
BTW, I don't want to hear "The trick with APR implementation is by presuming that all connected users will not actually make request concurrently", as I would like APR connectors throughtput to be at least equal to the regular connectors throughput, so you can get the much better scalability and resource usage without the raw performance costs (otherwise, we'd have to go with NIO). As far as I can see, this is mostly achieved by APR, but we're going to need more tests to confirm it.
Anyway, I'm off until Monday evening. Bye :)
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
