How is the performance running RoR with Apache2 compared to running it
with PHP?
“Pål” == Pål Bergström [email protected] 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 D. <[email protected]>
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 D. wrote:
“P�l” == P�l Bergstr�m [email protected] 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 D. <[email protected]> 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).
“Pål” == Pål Bergström [email protected] 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 D. <[email protected]>
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
On Jun 9, 2006, at 1:05 PM, Pål Bergström wrote:
application in them both and then do benchmarks.
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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
Recently 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
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
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
Cheers-
-Ezra_______________________________________________
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
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.
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
On Wed, 2006-06-14 at 21:45 +0200, Joe R. wrote:
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
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
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
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 M.