Forum: Ruby on Rails RoR with Apache2 - performance?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-07 17:48
How is the performance running RoR with Apache2 compared to running it
with PHP?
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-06-08 09:35
(Received via mailing list)
>>>>> "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
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-09 22:05
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).
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-06-09 22:35
(Received via mailing list)
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
> Rails@lists.rubyonrails.org
> 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
   </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_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-06-12 11:17
(Received via mailing list)
>>>>> "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
429500a5a54600958c9c7ac032a37f66?d=identicon&s=25 Joe (Guest)
on 2006-06-12 21:32
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
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-14 18:08
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.
856436f34742e0ddf3bb0e1061742dc1?d=identicon&s=25 Joe Ruby MUDCRAP-CE (joe)
on 2006-06-14 21:45
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
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-06-14 22:13
(Received via mailing list)
On Wed, 2006-06-14 at 21:45 +0200, Joe Ruby 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
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
87a1b4114f307e1a4f4c9968ccb92a04?d=identicon&s=25 James Moore (Guest)
on 2006-06-14 22:50
(Received via mailing list)
> 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_av...
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
856436f34742e0ddf3bb0e1061742dc1?d=identicon&s=25 Joe Ruby MUDCRAP-CE (joe)
on 2006-06-14 23:00
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
This topic is locked and can not be replied to.