How is the performance running RoR with Apache2 compared to running it with PHP? -- Posted via http://www.ruby-forum.com/.
>>>>> "P?l" == P?l Bergstr?m <pal@palbergstrom.com> writes:> How is the performance running RoR with Apache2 compared to running it > with PHP?That question makes no sense. Running Rails from PHP would be... unusual. If you''re really asking if Rails or PHP are faster, that''s not a question that can be answered. You''d have to write your application in them both and then do benchmarks. -- Calle Dybedahl <calle@cyberpomo.com> http://www.livejournal.com/users/cdybedahl/ "Being stomped on by some sexy commie chick and her perfectly vegan Doc Martens is not as hot as it sounds." -- babycola
Calle Dybedahl wrote:>>>>>> "P?l" == P?l Bergstr?m <pal@palbergstrom.com> writes: > >> How is the performance running RoR with Apache2 compared to running it >> with PHP? > > That question makes no sense. Running Rails from PHP would be... > unusual. If you''re really asking if Rails or PHP are faster, that''s > not a question that can be answered. You''d have to write your > application in them both and then do benchmarks. > -- > Calle Dybedahl <calle@cyberpomo.com> > http://www.livejournal.com/users/cdybedahl/ > "Being stomped on by some sexy commie chick and her perfectly vegan > Doc > Martens is not as hot as it sounds." -- babycolaSorry for the mixup in my question. I mean running Apache2 with php or RoR. What about the general consensus, if any? What I''m thinking on is to stay with Apache2 instead of learning Lighttpd (and try to get it started, which I haven''t been able to do). -- Posted via http://www.ruby-forum.com/.
On Jun 9, 2006, at 1:05 PM, P?l Bergstr?m wrote:> Calle Dybedahl wrote: >>>>>>> "P?l" == P?l Bergstr?m <pal@palbergstrom.com> writes: >> >>> How is the performance running RoR with Apache2 compared to >>> running it >>> with PHP? >> >> That question makes no sense. Running Rails from PHP would be... >> unusual. If you''re really asking if Rails or PHP are faster, that''s >> not a question that can be answered. You''d have to write your >> application in them both and then do benchmarks. >> -- >> Calle Dybedahl <calle@cyberpomo.com> >> http://www.livejournal.com/users/cdybedahl/ >> "Being stomped on by some sexy commie chick and her perfectly >> vegan >> Doc >> Martens is not as hot as it sounds." -- babycola > > Sorry for the mixup in my question. I mean running Apache2 with php or > RoR. What about the general consensus, if any? What I''m thinking on is > to stay with Apache2 instead of learning Lighttpd (and try to get it > started, which I haven''t been able to do). > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsRecently I have had great luck using apache2.2 with mod_proxy_balancer to load balance between mongrel backends. So you run your rails app in a few different mongrel processes and apache serves up static content while mongrel serves dynamic rails requests. Here is an example apache vhost to handle this sort of thing. <VirtualHost *:80> ServerName yourdomain.com DocumentRoot /var/rails/your_app/current/public <Directory "/var/rails/your_app/current/public"> Options FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> # Configure mongrel_cluster <Proxy balancer://mongrel_cluster> BalancerMember http://127.0.0.1:5000 BalancerMember http://127.0.0.1:5001 BalancerMember http://127.0.0.1:5002 </Proxy> RewriteEngine On # If there is a maintenence.html dile in your # public dir all requests will get rerouted to # this file. RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f RewriteCond %{SCRIPT_FILENAME} !maintenance.html RewriteRule ^.*$ /maintenance.html [L] # Rewrite index to check for static index.html RewriteRule ^/$ /index.html [QSA] # Rewrite to check for Rails cached pages with .html extentions RewriteRule ^([^.]+)$ $1.html [QSA] # All dynamic requests get sent to the mongrel cluster RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L] # Deflate AddOutputFilterByType DEFLATE text/html text/plain text/xml BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html ErrorLog logs/your_app_error_log CustomLog logs/your_access_log combined </VirtualHost> Cheers- -Ezra
>>>>> "P?l" == P?l Bergstr?m <pal@palbergstrom.com> writes:> I mean running Apache2 with php or RoR. What about the general > consensus, if any? What I''m thinking on is to stay with Apache2 > instead of learning Lighttpd (and try to get it started, which I > haven''t been able to do).At least with Rails, the time taken by the frontend webserver to shuffle the request off to the Rails backend should be an extrememly small part of the entire request. If you''re already comfortable with Apache, I''d say stay with that until the day you actually have a performance problem that''s not inside your Rails application. -- Calle Dybedahl <calle@cyberpomo.com> http://www.livejournal.com/users/cdybedahl/ "But that was in the gauzy realm of meat and oxygen, not this real world here on the screen." -- archbishopm, LiveJournal
P?l Bergstr?m wrote:> Sorry for the mixup in my question. I mean running Apache2 with php or > RoR. What about the general consensus, if any? What I''m thinking on is > to stay with Apache2 instead of learning Lighttpd (and try to get it > started, which I haven''t been able to do).In my experience, Lighty performs much better than Apache, uses less memory, and is easier to configure. Joe -- Posted via http://www.ruby-forum.com/.
Joe wrote:> P?l Bergstr?m wrote: > >> Sorry for the mixup in my question. I mean running Apache2 with php or >> RoR. What about the general consensus, if any? What I''m thinking on is >> to stay with Apache2 instead of learning Lighttpd (and try to get it >> started, which I haven''t been able to do). > > In my experience, Lighty performs much better than Apache, uses less > memory, and is easier to configure. > > JoeOn http://mongrel.rubyforge.org/docs/lighttpd.html it is said: "I?m sad to say that I have to recommend people not use lighttpd anymore. The author hasn?t updated the mod_proxy plugin and isn?t providing too much support for the bugs it has. If you?re running lighttpd and you constantly see 500 errors that are never recovered, then you should switch to Apache or another web server that can handle properly balancing backends." What should one expect from Lighttpd in the future? It''s not just performance that matters but also product stability and product development. -- Posted via http://www.ruby-forum.com/.
P?l Bergstr?m wrote:> Joe wrote: >> P?l Bergstr?m wrote: >> >>> Sorry for the mixup in my question. I mean running Apache2 with php or >>> RoR. What about the general consensus, if any? What I''m thinking on is >>> to stay with Apache2 instead of learning Lighttpd (and try to get it >>> started, which I haven''t been able to do). >> >> In my experience, Lighty performs much better than Apache, uses less >> memory, and is easier to configure. >> >> Joe > > On http://mongrel.rubyforge.org/docs/lighttpd.html it is said: > > "I?m sad to say that I have to recommend people not use lighttpd > anymore. The author hasn?t updated the mod_proxy plugin and isn?t > providing too much support for the bugs it has. If you?re running > lighttpd and you constantly see 500 errors that are never recovered, > then you should switch to Apache or another web server that can handle > properly balancing backends." > > What should one expect from Lighttpd in the future? It''s not just > performance that matters but also product stability and product > development.Hmm, that sucks. Zed, have you contacted Jan K? Can you elaborate? Looking at the docs, mod_proxy was last updated in 2004. Perhaps he takes patches. As for me, I haven''t had any 500 error problems. But yeah, mod_proxy leaves something to be desired and Lighttpd''s development seems to proceed very slowly - seems to be just Jan developing it. I guess Pound is one alternative. Not sure what other web server options there are (besides Apache and WebBrick (dev only)). Joe -- Posted via http://www.ruby-forum.com/.
On Wed, 2006-06-14 at 21:45 +0200, Joe Ruby wrote:> P?l Bergstr?m wrote: > > What should one expect from Lighttpd in the future? It''s not just > > performance that matters but also product stability and product > > development. > > Hmm, that sucks. Zed, have you contacted Jan K? Can you elaborate? > Looking at the docs, mod_proxy was last updated in 2004. Perhaps he > takes patches. As for me, I haven''t had any 500 error problems. But > yeah, mod_proxy leaves something to be desired and Lighttpd''s > development seems to proceed very slowly - seems to be just Jan > developing it. I guess Pound is one alternative. Not sure what other web > server options there are (besides Apache and WebBrick (dev only)).I haven''t contacted Jan because I know quite a few other folks already have. He seems to be busy working to make money right now, but I''m pretty sure if you worked up a patch he''d accept it. But don''t sell Apache short. It used to be a slow fat pig, but now it''s at least just a fat pig. Using the MPM worker people seem to get similar performance as lighttpd. Of course the config file still sucks hot ass, but it''s solid and is actively maintained. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/
> But don''t sell Apache short. It used to be a slow fat pig, but now it''s > at least just a fat pig. Using the MPM worker people seem to get > similar performance as lighttpd. Of course the config file still sucks > hot ass, but it''s solid and is actively maintained.Now there''s a charming image... I''m usually far more concerned with stability than with performance. Apache has an active user base of approximately thirty-seven bazillion high-demand high performance installations. It may not be the number one performer, but the number of people who honestly need to care about performance on those sorts of margins is tiny. And yes, the configuration can be nasty, but so what? Everyone already knows how to configure Apache, and there''s a vast amount of knowledge available if you don''t yet know what you''re doing. Any performance issues are going to be dominated by what your code''s doing, not so much the Apache side of things. Warning: the following contains benchmarks that should be taken with a fair amount of salt. They involved approximately three minutes of careful design. For example, sucking down my home page (locally, avoiding network issues) gives me about 69 requests per second served. This is with zero intelligent cacheing of basically static content, and a few database hits (the home page tells you if you''re logged in or not.) I''m hitting Apache 2 on a linux box, proxy balancer, and 12 mongrel sessions serving the content. Hardware is a Dell mumblemumble (I acutally forget what the thing is, and it''s in a datacenter) with two gigs of memory and a 2.8 P4. I''m sure it wouldn''t take much work to get that number higher by quite a bit, but at this point it''d be a waste of time. /usr/local/apache2/bin/ab -n 200 -c 12 http://localhost/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Finished 200 requests Server Software: Mongrel Server Hostname: localhost Server Port: 80 Document Path: / Document Length: 4904 bytes Concurrency Level: 12 Time taken for tests: 2.889503 seconds Complete requests: 200 Failed requests: 0 Write errors: 0 Total transferred: 1031800 bytes HTML transferred: 980800 bytes Requests per second: 69.22 [#/sec] (mean) Time per request: 173.370 [ms] (mean) Time per request: 14.448 [ms] (mean, across all concurrent requests) Transfer rate: 348.50 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 1 Processing: 19 168 312.9 65 1546 Waiting: 19 165 312.9 65 1545 Total: 19 168 312.9 65 1546 Percentage of the requests served within a certain time (ms) 50% 65 66% 92 75% 119 80% 146 90% 358 95% 1120 98% 1385 99% 1528 100% 1546 (longest request) Hitting the most database-intensive encrypted page drops down to 6 requests per second: /usr/local/apache2/bin/ab -n 200 -c 12 https://www.phonesonrails.com/phone_number/find_available_numbers_by_area_co de This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/ Benchmarking www.phonesonrails.com (be patient) Completed 100 requests Finished 200 requests Server Software: Mongrel Server Hostname: www.phonesonrails.com Server Port: 443 SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256 Document Path: /phone_number/find_available_numbers_by_area_code Document Length: 16636 bytes Concurrency Level: 12 Time taken for tests: 30.232052 seconds Complete requests: 200 Failed requests: 0 Write errors: 0 Total transferred: 3378400 bytes HTML transferred: 3327200 bytes Requests per second: 6.62 [#/sec] (mean) Time per request: 1813.923 [ms] (mean) Time per request: 151.160 [ms] (mean, across all concurrent requests) Transfer rate: 109.12 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 87 551 493.2 431 2846 Processing: 107 1255 652.5 1150 4491 Waiting: 0 562 558.4 408 3668 Total: 345 1807 784.2 1658 5023 Percentage of the requests served within a certain time (ms) 50% 1658 66% 1825 75% 2060 80% 2299 90% 3014 95% 3679 98% 3680 99% 4704 100% 5023 (longest request) It''s completely obvious to me that Apache is the wrong place to even start to think about performance - it''s all in my code. (And this code in particular could benefit heavily from some intelligent design to prefetch and calculate a bunch of things, but even then 6 pages a second is probably fine for the task it''s doing.) - James Moore
Well, back when I was using Apache, its processes would definitely hit the CPU and regularly show up near the top of "top." Plus they used lots of memory. Switching to Lighty made a big difference for me - it''s lean and mean. And it''s the same story with Apache''s modules - a lot of them are quirky and haven''t been updated in quite a while. Joe -- Posted via http://www.ruby-forum.com/.