You might also want to dig up Peter's JMeter test plan. This one is the
opposite of the 'ab' test, in that it tests the ability to handle a lot of
socket connections without necessarily much throughput.
As Remy said, the 'ab -k' tests should be close unless either your JVM
vendor or your APR implementation s*cks. Both connectors do much the same
thing with this test execpt for sendfile (and 'tomcat.gif' is too small to
for Tomcat to use sendfile by default).
----- Original Message -----
From: "Tim Funk" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Thursday, June 02, 2005 3:41 AM
Subject: Re: Initial apr results
Excellent. In my future tests, I'll keep the concurrency lower and the
hits higher. I'll also use different size files. I am only able to use a
1.4.2 JVM. I might be able to get 1.5 on - but its highly doubtful.
-Tim
Remy Maucherat wrote:
Tim Funk wrote:
My test box was an HP-UX 9000/800/L1000-44 - Dual CPU (440 MHz)
On my initial tests with the APR connector - the APR connector "seemed"
slower the "old" http connector. But the difference is mild and my
initial numbers are flaky. On the same hardware - I am running 6 other
instances (of different versions) of tomcat at the same time which may
be throwing my numbers off.
During some slow time - I might be able to take most of them down and
run some more tests to try to ensure I am hogging all the resources to
the box and not sharing them.
For those curious - for /tomcat.gif - my requests per second range
anywhere from 1200+ to 5000+ - Due to such a large range - I have no
confidence in my numbers so far to reach any conclusion.
I was using the command:
/usr/local/httpd/bin/ab -n 1000 -c 100 -k
http://myserver:8090/tomcat.gif
With keepalive off - I was still easily over 1000 requests per second
for tomcat.gif.
I can't assert yet that there are no bugs at the moment (performance or
otherwise). So far, performance seems good on Windows, and Linux. To give
a comparison on Windows with this test, APR HTTP is within 5% of regular
HTTP, and gets closer depending on the JVM (I suppose if it's better at
JNI - I've noticed slightly better results with Sun JDK 1.5 Server
compared to 1.4.2 client).
I think you should use -n 20000 at least: if the test duration is too
small, ab is going to produce random results. In this test, increasing
concurrency isn't particularly useful either.
Obviously, the results of this kind of testing are not really important
as long as the results stay relatively close (for example, I think
the -25% result I got when using polling exclusively was really good).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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]
