Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


I have an Email Marketing Rails application running on a CentOS QuadCore 16GB RAM server. But currently our webserver is taking too long to respond to requests on rush hours (Mongrel Cluster + Apache ). We monitoring it using ScoutApp ( ).

Scout Alerts Maximum Time(3 sec) exceeded on 668 requests Maximum Time(3 sec) exceeded on 120 requests

I contracted another server Dual Xeon 4GB RAM .

What is the best setup for distributing this application between 2 servers? I'm thinking about using the SERVER-1 (16GB RAM) with Mysql and Exim and migrate the application to SERVER-2 (4GB RAM) and use it as the WEB SERVER (Mongrel cluster + Apache) only.

Can anyone suggest me a better setup , tips or ideas?

share|improve this question
You need more data. Why is the app performing poorly; what are you short on -- disk I/O, RAM, CPU? Without numbers it's a haphazard change, and you may not get the performance improvement that you were hoping for. – Jesper Mortensen Sep 20 '10 at 15:26
A good first step is to split the data and application layers onto different servers, in almost all cases. But once (or before) you've done that you need to do performance analysis to figure out your current bottleneck, and then when you hit your next performance problem, you'll need to do it again. Very exciting. – mfinni Sep 20 '10 at 15:43
up vote 3 down vote accepted

... you should narrow the scope of the topic to "rails" in particular. (the subject is a bit misleading) I would highly suggest looking at the logs & trying to identify where the lag is coming from.

There are several reasons why a Rails app would run slow... and most of the time it has nothing to do with the database or the web server itself. I would look to make sure that caching is NOT disabled. (in development mode caching is disabled by default) Rails gets a lot of performance boosts from the many caching algorithms it has... Additionally, several of the debugging bits that are turned on in development also eat a bit of performance too.

If all is done that can be done... there are several steps into moving towards a "clustered rails environment." The debugging I suggested earlier can also tell you what you need to scale up. If you're constantly waiting on the database to respond... then moving the database server off that box & onto it's own... or clustering the database alone might be all you need. If you find the www server is the one lagging behind... scale up on the web server.

share|improve this answer

Splitting the web/http hosting and the database hosting on separate servers is a good first step. A nice second step is to get a duplicate web server and set it up with the first with some type of load balancer. Either hardware that sits in front of both servers, or a software based one.

edit: This assumes you are positive the database is not your limiting factor (which it very well could be). Moving the web server off the database server will help this situation, but the second web server I'm suggesting will only help if the processing of each request is slowing you down and not the database.

share|improve this answer

It's not the database that is calling the problem. When responses start to get slow, I checked mysql processes and mysql had no waiting processes. I think there's too many requests reaching the web server ( apache + mongrel cluster ). Even websites running on PHP can't be reached during rush hour. I only have ScoutApp monitoring my server.


I/O Wait 11.9 ms Read kBps 422.8 kB/s Reads/sec 61 Utilization 82% Write kBps 2,435.9 kB/s Writes/sec 196

Rails Aplication monitoring

Average db time 0.00 sec
Average request length 10.10 sec
Average view time 9.81 sec
Requests 13.93 req/min
Slow Requests 7.47 req/min
Slow requests percentage 54%

Apache Load

Requests Per Second 1.80 req/s
Total accesses: 19169 - Total Traffic: 461.9 MB
CPU Usage: u4 s.11 cu1.31 cs0 - .0648% CPU load
2.29 requests/sec - 56.5 kB/second - 24.7 kB/request
12 requests currently being processed, 9 idle workers

Exim Queue ( exim -bpc)


share|improve this answer
FYI - this should be edited into your original question, or added as a comment. You're not suggesting an answer, you are giving more data. So, yeah, you should split the data and web tiers, and profile the web tier first - but you should profile both tiers (all servers) going forward, so you know where bottlenecks are or will be. – mfinni Sep 20 '10 at 17:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.