Quick & Dirty Rails Scaling Tips for PBBG’s

I wrote a PBBG in Rails that lives on Facebook, so I’ve had some scaling issues to deal with. Here are some tips I collected along the way on scaling Rails.

Serve statics from somewhere else

In the beginning, letting your Rails setup serve everything is very easy. But as your game grows in popularity, you’ll notice that your app spends a lot of time serving up things that never change.

The first thing we did was separate out all the static images onto a separate server running nginx. Nginx is notoriously fast at serving static content and it did a good job for us. This left our Rails instances to serve only game-related activities.

Another useful bit was using a plugin called bundle_fu. Bundle_fu takes all the javascrips and stylesheets you use in your app and creates a single file for the browser to download. So, instead of the browser having to make 6 connections to get all those pieces, it makes 1. This functionality is built into Rails since version 2.0.

Optimize your environment

Initially, we ran Apache proxying to 5 to 10 mongrel servers running Rails. Then we switched to Nginx/mongrels which gave us a bit of speed and a bit of memory back, after doing some more searching we eventually switched entirely to the Litespeed webserver with no mongrels. Litespeed is an awesome product and we have had rock solid performance with it for the last year. Although, all my latest Rails deployments have been with Apache & mod_rails (Passenger) running with the Ruby Enterprise Edition.

One big upside to Litespeed and Passenger is that you don’t have to manage mongrels anymore and restarting the website is super fast. Also, Ruby Enterprise Edition (REE) can reduce your memory requirements up to 30%.

Memcached

I think the biggest anecdotal speed increase we got was from integrating support for memcached. It was as simple as adding the acts_as_cached plugin and marking a few models to be cached. From there, we began optimizing which models were cached for the best performance.

Watch for slow queries

Edit your mysql.cnf file to start logging slow queries and then watch that log like a hawk. When you see a query that isn’t using an index, make sure you add the appropriate index to get that query to be fast again. This won’t help much if the query only runs once a day, but if it runs every few seconds — you’ll notice the difference.

Throttling the game

Early on when there were only a few hundred people in our game we added a bunch of notifications to our chat system so that people would know that others were there and something was happening. Crank that up to several thousand people and those notifications are nothing but annoying. So, we added code that checked for the number of currently online people and throttled those informative messages when things got busy and brought them back when things calmed down again. This made a big improvement in the quality of play during busy times.

These are just a few of the things we tried, but they were the most successful at improving the performance of our game.

If you’d like to see it, browse over to Tooth & Claw

Wish there was more?

I'm considering writing an ebook - click here.

.

Tags:

Friday, January 2nd, 2009 optimization, rubyonrails
blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames