----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Saturday, April 30, 2005 1:38 AM
Subject: Re: Initial test of APR on Solaris
Mladen Turk wrote: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.
It was late in the day, and I had 'ab' already installed and not JMeter. I'm actually more interested in the JMeter results, but I also wanted to get out of the office ;-).
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.
I was surprised that it worked at 150. I guess my crappy XP box was too slow to give real throughput :).
The OOM message came from ThreadPool, which doesn't log stack traces. I'll need to hack ThreadPool to see where it's getting thrown from. The box is pretty old and small (which is why it's mostly a test-bed these days :), but the memory usage reported by 'top' wasn't that high. It's probably some other resource, since Sun throws OOM for everything. I'll see if I can find out Monday.
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
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
