4 ms·
Each request to Rails block a Mongrel while it servers it, but even on my home server I am getting upwards of 50 requests per second on my app (all logged in pa
by fendale 19y ago
Each request to Rails block a Mongrel while it servers it, but even on my home server I am getting upwards of 50 requests per second on my app (all logged in pages, so no caching). That means you could have 50 people all requesting the page at the same time and each of them will have it returned inside a second even with a single Mongrel.
You need to be careful that you don't tie up some of your Mongrels doing long running tasks - if you have actions that cause tasks to run that take on the order of seconds, consider queuing them up to be serviced by some other background process (which is what I decided to do).
As someone else mentioned here, try to cache as much as possible - cached full pages take the load off Rails completely, cached fragments reduce the time to serve a request inside Rails, so you can get more from each Mongrel. Make sure and not cache logged in pages though!
Other general advice for a database application - hit the database as little as possible - in Rails don't do things like:
@user = User.find(params[:id])
@products = @user.products.find(:all)
@profile = @user.profile.find(:all)
That would result in 3 database queries, while this will do it in 1:
@user = User.find(params[:id], :include => [:products, :profile])
etc ...
- goodgoblin 19y agoI'm really trying to figure out how much money serving 120K users is going to cost me in servers and bandwidth. Thanks for the tips - I've farmed the image uploads out to merbs running in EC2 - there are some other long running (6+ second) tasks that users could perform frequently - I'll start to farm those out as well.