Re: Initial apr results
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 2 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). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 2 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]
Re: Initial apr results
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 2 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]
Re: Initial apr results
if you need the test plan Tim, email me and I'll send it to you :) peter On 6/2/05, Bill Barker [EMAIL PROTECTED] wrote: 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 2 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial apr results
once I finally get the APR build working on my laptop, I will run my benchmarks and publish the results. peter On 6/1/05, Tim Funk [EMAIL PROTECTED] 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. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
