tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Initial test of APR on Solaris
Date Sat, 30 Apr 2005 18:46:25 GMT

----- Original Message ----- 
From: "Remy Maucherat" <remm@apache.org>
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.



Mime
View raw message