Rails Webserver Wars [ Thin vs ModRails ] - Which is the best one ???

[Dinooz]

Rails Webserver Wars [ Thin vs ModRails ] - Which is the best one ???
http://railsforum.com/viewtopic.php?pid=59619#p59619

:: => Here is the Post:

This my personal benchmark between modrails.com and Thin. in a VPS
with 256 MB Ram and 4 RoR Applications:

=> After looking the Ryan Bates screencast at modrails.com:

1.- # gem install passenger-x.x.x.gem

2.- # passenger-install-apache2-module

3.- Copy the following lines in your httpd.conf

# Passenger for RoR - Apr 12 - 2008
LoadModule passenger_module /usr/local/lib/ruby/gems/1.8/gems/
passenger-1.0.1/ext/apache2/mod_passenger.so
RailsSpawnServer /usr/local/lib/ruby/gems/1.8/gems/passenger-1.0.1/bin/
passenger-spawn-server
RailsRuby /usr/local/bin/ruby

3.- Edit your Virtual Host Directives:

<VirtualHost 123.123.123.123:80>
ServerName www.domain_rails_app1.com
DocumentRoot /home/dinooz/rails/rails_app1/public
</VirtualHost>

<VirtualHost 123.123.123.123:80>
ServerName www.domain_rails_app2.com
DocumentRoot /home/dinooz/rails/rails_app2/public
</VirtualHost>

<VirtualHost 123.123.123.123:80>
ServerName www.domain_rails_app3.com
DocumentRoot /home/dinooz/rails/rails_app3/public
</VirtualHost>

<VirtualHost 123.123.123.123:80>
ServerName www.domain_rails_app4.com
DocumentRoot /home/dinooz/rails/rails_app4/public
</VirtualHost>

You can include some other Apache directives like:

ServerAlias www.rails_appx.com
ServerAdmin root@localhost
ErrorLog logs/rails_appx-error_log
CustomLog logs/rails_appx-access_log common
</VirtualHost>

Once everything is ready, just go a head and restart the Apache web
server:
[NOTE: My only problem was permissions trying to access the rails
application. Make sure you setup the user used in the deployment of
your web application, or make the group security changes to allow
access that directory.]

User apache
Group apache

To my case I just changed to:

User dinooz
Group dinooz

Maybe not a good idea, but I just want to get this rolling =)

# /etc/init.d/httpd restart

=> Ok let check the price on RAM for this solution withtout Running
HTTPD or THIN.

[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 36 219 0
0 0
-/+ buffers/cache: 36 219
Swap: 0 0 0
[root@fedora conf]#

Lets start Apache with the Mod_Rails Module:

[root@fedora conf]# /etc/init.d/httpd start
Starting httpd: [ OK ]

[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 59 196 0
0 0
-/+ buffers/cache: 59 196
Swap: 0 0 0

Looking good, very samll footprint... but lets start opening some of
the URLs' of the sites


Opening Browser at http://www.rails_app1.com
[ NOTE: I should said this open in about 5 secons when Thin open a lot
faster in about 2 ]

[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 133 122 0
0 0
-/+ buffers/cache: 133 122
Swap: 0 0 0

Wow a lot of RAM used about 74MB in the VPS maybe in 32bit machine
will use 36MB. Still is kind of high compared with Thin which uses in
my experience about [40MB and around 20MB in a 32bit machine]

Running simple benchmark for rails_app1.com

$ ab -n 1000 -c 100 http://www.rails_app1.com/

... From ApacheBench using ModRails...
Server Software: Apache/2.2.6
Server Hostname: www.rails_app1.com
Server Port: 80

Document Path: /
Document Length: 7617 bytes

Concurrency Level: 100
Time taken for tests: 66.197872 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8128206 bytes
HTML transferred: 7620699 bytes
Requests per second: 15.11 [#/sec] (mean)
Time per request: 6619.787 [ms] (mean)
Time per request: 66.198 [ms] (mean, across all concurrent
requests)
Transfer rate: 119.90 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 95 289 738.4 99 3259
Processing: 3123 6070 3161.6 5106 19337
Waiting: 2955 5966 3161.7 5002 19233
Total: 3272 6360 3360.4 5209 22587

Percentage of the requests served within a certain time (ms)
50% 5209
66% 5248
75% 5317
80% 5353
90% 14458
95% 15084
98% 15234
99% 20947
100% 22587 (longest request)

If you keep eye on the memory will be used very quick. I strongly
recommend to check the settings for Apache:

# prefork MPM
<IfModule prefork.c>
StartServers 1
MinSpareServers 1
#MaxSpareServers 5
MaxSpareServers 2
#ServerLimit 10
ServerLimit 4
#MaxClients 10
MaxClients 4
#MaxRequestsPerChild 4000
MaxRequestsPerChild 1000
</IfModule>

# worker MPM
<IfModule worker.c>
StartServers 1
#MaxClients 10
MaxClients 4
MinSpareThreads 1
#MaxSpareThreads 4
MaxSpareThreads 2
#ThreadsPerChild 25
ThreadsPerChild 10
MaxRequestsPerChild 0
</IfModule>

According with:
http://izumi.plan99.net/blog/index.php/2008/03/31/benchmark-passenger-mod_rails-vs-mongrel-vs-thin/
Is possible to customize: Passenger: RailsMaxPoolSize is set to 10.
But I did not play with that yet !!!.

Whey I try to benchmark the second domain HTTP Died.

Once HTTP Server crash the last resort is to restart Apache.
[ NOTE: This test is in a VPS with 256 MB and Fedora 6. Very minimal
resources about 40MB for all the system and all the 200MB for the Web
Server =), This might not apply to your scenario, is just my own
particular experience].

Trying Thin:

Nothing fantasy here just as described in previous post:
http://railsforum.com/viewtopic.php?id=17284

We have a ProxyBalancer pointing to some Thin Clusters as:

<Proxy balancer://my_railsapp1>
BalancerMember http://127.0.0.1:3000
BalancerMember http://127.0.0.1:3001
BalancerMember http://127.0.0.1:3002
BalancerMember http://127.0.0.1:3003
BalancerMember http://127.0.0.1:3004
</Proxy>

<VirtualHost 123.123.123.123:80>
ServerAdmin webm...@railsapplicationtip.com
ServerName railsapplicationtip.com
ServerAlias www.railsapplicationtip.com
RewriteEngine on
ProxyPass / balancer://my_railsapp1/
ProxyPassReverse / balancer://my_railsapp1/
ErrorLog logs/railsapplicationtip-error_log
CustomLog logs/railsapplicationtip-access_log common
</VirtualHost>

Exactly 4 Virtual Domains just as we present earlier:

Starting Apache & THin Servers.

[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 38 217 0
0 0
-/+ buffers/cache: 38 217
Swap: 0 0 0
[root@fedora conf]# /etc/init.d/httpd start
Starting httpd: [ OK ]
[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 51 204 0
0 0
-/+ buffers/cache: 51 204
Swap: 0 0 0
[root@fedora conf]# /etc/init.d/thin start
[start] /etc/thin/thin_gm.yml ...
Starting server on 0.0.0.0:6011 ...
[start] /etc/thin/thin_gmt.yml ...
Starting server on 0.0.0.0:6001 ...
[start] /etc/thin/thin_gt.yml ...
Starting server on 0.0.0.0:6006 ...
[start] /etc/thin/thin_nca.yml ...
Starting server on 0.0.0.0:6003 ...
[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 190 65 0
0 0
-/+ buffers/cache: 190 65
Swap: 0 0 0
[root@fedora conf]#

Ok lets benchmark:

$ ab -n 1000 -c 100 http://www.rails_app1.com/

... From ApacheBench using Thin...
Server Software: Thin
Server Hostname: www.rails_app1.com
Server Port: 80

Document Path: /
Document Length: 7617 bytes

Concurrency Level: 100
Time taken for tests: 54.319373 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8468000 bytes
HTML transferred: 8001000 bytes
Requests per second: 18.41 [#/sec] (mean)
Time per request: 5431.937 [ms] (mean)
Time per request: 54.319 [ms] (mean, across all concurrent
requests)
Transfer rate: 152.23 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 97 291 739.6 100 3265
Processing: 312 4885 936.9 5191 5995
Waiting: 207 4779 938.3 5087 5891
Total: 422 5177 1057.1 5296 9260

Percentage of the requests served within a certain time (ms)
50% 5296
66% 5316
75% 5348
80% 5394
90% 5472
95% 6232
98% 7817
99% 8518
100% 9260 (longest request)

[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 215 37 0
0 0
-/+ buffers/cache: 215 40
Swap: 0 0 0

Memory stay solid on the same level which is really good, and best of
all once I repeat for rails_app2.com The server never crashed !!!.

[root@fedora conf]# free -m
total used free shared buffers
cached
Mem: 256 214 41 0
0 0
-/+ buffers/cache: 214 41
Swap: 0 0 0

Facts:
1.- Simple opening page Thin: 2 Seconds / ModRails: 6 Seconds
2.- ApacheBench Test Thisn: 54 Seconds / ModRails: 66 seconds
3.- Configuration Time: Both are really simple and easy to setup !!!.
Perhaps ModRails is what bigger hosting companies need to make it
easier for the users since does not require any tcp/ip port
configuration.
4.- ModRails will require more resources than Thin in terms of RAM.
5.- I did not have chance to test the: RailsMaxPoolSize really like to
see how impact the benchmark.

Conclusions:
1.- Both Thin & ModRails are great and I'm really happy to see
ModRails solution out ;-)
2.- VPS 256MB (64Bit) with Fedora 6 and 4 Virtual Domains / 4 RoR
Applications: Thins is Faster than ModRails and don't crash at least
as easy as Apache.
3.- Maybe the most important of all. Keep close eye on your resources.
The best web server is the one that works for you. The environment
used for this test is very pool [256MB =( ] But is just for fun, will
show you how to optimize & manage your resources wisely. If I Linux
can do this with limited resource, think about what can you do with
512MB or 1024MB ???. For the time been I'll stick around Thin, really
like it fast & reliable ;-)

[Hongli Lai]

Hi Dinooz.

It's actually very important that you set 'RailsMaxPoolSize', because
that controls the maximum number of Rails processes spawned by
Passenger. If you leave it at the default setting (20), and you run
'ab -n 1000 -c 100' then Passenger will spawn 20 processes. That's
effectively the same as running 20 Thins. For this comparison to be
fair, you should set it to 4, equal to the number of Thins that you're
running.

Also, you might notice "Passenger ApplicationSpawner" and "Passenger
FrameworkSpawner" processes in the process list. These processes are
meant to improve the speed of subsequent spawns. They have idle
timeouts. The framework spawner will go away after 1 hour of idling,
and the application spawner will go away after 2 minutes of idling,
thereby releasing all their resources. Thus, the high memory usage
that you see is only temporary.

With kind regards,
Hongli Lai
- phusion.nl

On Apr 13, 3:37 pm, Dinooz <bernardino.lo...@gmail.com> wrote:
> Rails Webserver Wars [ Thin vs ModRails ] - Which is the best one ???http://railsforum.com/viewtopic.php?pid=59619#p59619

> Opening Browser athttp://www.rails_app1.com

> [ NOTE: I should said this open in about 5 secons when Thin open a lot
> faster in about 2 ]
>
> [root@fedora conf]# free -m
>              total       used       free     shared    buffers
> cached
> Mem:           256        133        122          0
> 0          0
> -/+ buffers/cache:        133        122
> Swap:            0          0          0
>
> Wow a lot of RAM used about 74MB in the VPS maybe in 32bit machine
> will use 36MB. Still is kind of high compared with Thin which uses in
> my experience about [40MB and around 20MB in a 32bit machine]
>
> Running simple benchmark for rails_app1.com
>

> $ ab -n 1000 -c 100http://www.rails_app1.com/

> According with:http://izumi.plan99.net/blog/index.php/2008/03/31/benchmark-passenger...

> Is possible to customize: Passenger: RailsMaxPoolSize is set to 10.
> But I did not play with that yet !!!.
>
> Whey I try to benchmark the second domain HTTP Died.
>
> Once HTTP Server crash the last resort is to restart Apache.
> [ NOTE: This test is in a VPS with 256 MB and Fedora 6. Very minimal
> resources about 40MB for all the system and all the 200MB for the Web
> Server =), This might not apply to your scenario, is just my own
> particular experience].
>
> Trying Thin:
>
> Nothing fantasy here just as described in previous post:http://railsforum.com/viewtopic.php?id=17284
>
> We have a ProxyBalancer pointing to some Thin Clusters as:
>
> <Proxy balancer://my_railsapp1>
> BalancerMemberhttp://127.0.0.1:3000
> BalancerMemberhttp://127.0.0.1:3001
> BalancerMemberhttp://127.0.0.1:3002
> BalancerMemberhttp://127.0.0.1:3003

> BalancerMemberhttp://127.0.0.1:3004
> </Proxy>
>
> <VirtualHost 123.123.123.123:80>
> ServerAdmin webmas...@railsapplicationtip.com
> ServerName railsapplicationtip.com
> ServerAliaswww.railsapplicationtip.com

> $ ab -n 1000 -c 100http://www.rails_app1.com/

[Mel Brand]

Hi,

Simplistic benchmarks can be very deceptive and many times they tell
you only the half of the story. I have no idea what kind of a site you
have but you should at the very least test few features of your apps
while benchmarking. For example, if you have a site where people are
uploading things to your site, that action should be a part of the
test. Why? Well, different servers have VERY different ways of dealing
with long running processes. Thin blocks a whole process when you're
uploading something so that would show up in your benchmark. I have no
idea how mod_rails handles long running processes but I know Mongrel
performs a lot better than thin (or any other evented server) in those
situations.

The point I'm trying to make is that you should pick a solution that's
suited for your site and you should learn about different pros and
cons of each and pick one that's the best for your situation. Picking
a server just because it scores 5-10% on some artificial benchmark is
a sure way to end up with some headaches.

Mel

[Adam Byrtek]

On Wed, Apr 16, 2008 at 7:06 PM, Mel Brand <big...@gmail.com> wrote:
> test. Why? Well, different servers have VERY different ways of dealing
> with long running processes. Thin blocks a whole process when you're
> uploading something so that would show up in your benchmark. I have no

By the way Thin has a threaded mode (as far as I know still
experimental). Ebb has an interesting way of handling the issue of
long requests, see:
http://four.livejournal.com/856000.html

Regards,
Adam

--
Adam Byrtek | Alpha
http://www.adambyrtek.net
http://www.codesprinters.com