Hi Mark - I tried to test apache with stress test using JMETER and results are not really good compared to sun one web server 6.1 running on the same machine. ab results is good now (after I have used -k option a suggested by you) Apache jmeter test output - count average min max stddev error% rate bandwidth average_bytes 10000 253 32 2507 235.54 0 262.295082 4982.32582 19451 sun one jmeter test output - count average min max stddev error% rate bandwidth average_bytes 10000 111 31 1897 106.08 0 383.5532372 6779.228555 18099 i guess worker mpm should work better than prefork..right? I didn't try prefork yet but do you think it's worth to check with that mpm once? I have tried so many things to tune config but all the time no better result than shown above for apache. You can see sun one web server had better numbers in each fields. could you or anyone else please help me further? On Fri, Apr 1, 2011 at 12:16 AM, Ishita Kapadiya <ishimegh@xxxxxxxxx> wrote: > Thanks Mark. It really helps. Once I have used keep alive in > benchmark response time reduced from 1900ms to 5 ms! > It should have come to my mind before. But thanks for your valuable > hints.. I can now breath :) > Next thing I am targetting is to use this server for stress test and > will let you know in case of any concern. > > Once again thanks for your help > > On Thu, Mar 31, 2011 at 7:56 AM, Mark Montague <mark@xxxxxxxxxxx> wrote: >> On March 30, 2011 19:44 , Ishita Kapadiya <ishimegh@xxxxxxxxx> wrote: >>> >>> Hi Mark, >>> >>> Thanks for your suggestion. I tried below settings in httpd.conf - >>> >>> <IfModule ssl_module> >>> #SSLRandomSeed startup builtin >>> #SSLRandomSeed connect builtin >>> SSLRandomSeed startup file:/dev/urandom 1024 >>> SSLRandomSeed connect file:/dev/urandom 1024 >>> </IfModule> >>> >>> the commented line was there when I initially posted my query and now >>> I changed it with mentioned lines. But still got the same result. >>> Even i tried with /dev/random option but that option didn't work at >>> all (may be not supported with my OS config) >>> Could you or anyone please help me to resolve this problem. I want to >>> resolve it. I tried to google it but couldn't find any solution. >>> Any help will be great. >> >> I had to scale things back a bit in the VM guest that I use for development, >> but here is what I'm seeing: >> >> ab -n 10000 -c 10 http://f14dev1.catseye.org/index.html >> Time taken for tests: 2.579 seconds >> >> ab -n 10000 -c 10 https://f14dev1.catseye.org/index.html >> Time taken for tests: 197.999 seconds >> >> This is a ratio ( time for HTTPS / time for HTTP ) of 76.77. In your >> original message, you had a ratio of 62.74. >> >> >> The following Q&A observes the same thing, and it includes a number of >> explanations: >> >> http://serverfault.com/questions/43692/how-much-of-a-performance-hit-for-https-vs-http-for-apache >> >> >> In other words, there is likely not anything wrong with your configuration. >> >> >> A final note: the performance difference does seem to center around the TLS >> session negotiation rather than encryption. If I enable keepalive for my >> benchmark, the time for HTTP decreases from 2.575 seconds to 1.437 seconds; >> but the time for HTTPS drops from 197.999 seconds to 4.237 seconds (yes, 193 >> seconds quicker simply by reusing connections!) >> >> I hope this helps. >> >> -- >> Mark Montague >> mark@xxxxxxxxxxx >> >> >> --------------------------------------------------------------------- >> The official User-To-User support forum of the Apache HTTP Server Project. >> See <URL:http://httpd.apache.org/userslist.html> for more info. >> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx >> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx >> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx >> >> > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|