Scaling a Rails application

I'm by no means a "scaling expert", but I've recently been doing a lot of research into scaling web applications and the best ways to go about it. What you see below is a rough guide based on what I've learnt - it's not scaling gospel or even an accurate or thorough discussion of all different techniques or schools of thought that can be applied to scaling. So, what does this series of posts cover? * What scaling is; * When/who you should think about scaling; * The web server (two parts: the box and the software); * The static assets; * The database; * The Rails code; and * Caching ## What scaling is ## > In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added. An analogous meaning is implied when the word is used in a commercial context, where scalability of a company implies that the underlying business model offers the potential for economic growth within the company. <cite><a href="http://en.wikipedia.org/wiki/Scaling">http://en.wikipedia.org/wiki/Scaling</a></cite> ## When to scale ## Generally, the consensus seems to be that if your a start-up, fresh out of the oven, scaling is a waste of your time. Get some users first and build your product! Scaling is generally something you consider when your current server setup is getting hammered and the growth of your applications warrants taking things to the next level. ## The web server ## ### The box ### If you're going to be doing high traffic sites, you'd be stupid (in my opinion) not to get your own hardware - the cost of entry for some relatively good gear isn't that high and in the long run, the flexibility and power that comes with having your own hardware outweighs the hassle. I'm running a Dell PowerEdge 1850 which is housed in a datacentre here in Perth (which makes sense for what I'm hosting on it) - it's not new, but it doesn't need to be - the only reason it was being disposed of by the company I bought it off was because the three year warranty had run out - during the three years however, it hadn't failed once and had been the primary domain controller for the organisation in question. Something to consider carefully is location and if your site is targeted at an international audience, then you'll certainly want to pick a location to keep that new server of yours in a DC where there's good international pipes available (Perth isn't really blessed in this particular area). When picking a datacentre, look for something with n+1 redundancy, diverse entry points for both data carriers and power (preferably off completely different feeds) and good security - taking a look at what carriers provide feeds into the facility is also a must. ### The software ### For the operating system, I'm a fan of Ubuntu server edition - I'll admit, I've not tried much else (FreeBSD and Debian) and I always come back to Ubuntu - I think that's mainly because my first experiences with Linux were on an Ubuntu box. I keep the install down to the bear minimums - build_essential, iptables, fail2ban, denyhosts, mysql, nginx and a local postfix instance are all that are running (there's probably some other things, but you get the idea - no need for fruit) Personally, I use the nginx (/engine-x/) web server - it's fast at serving static assets and it knows when to get out of the way if I want to pass things off to my Rails app. High profile websites including Wordpress.com and Github are using nginx with great success when it comes to high traffic scenarios. Another part of my setup is Unicorn. Unicorn is written to make use of a number of existing system elements (threads, balancing, etc) which makes it stupidly efficient. For more, see this article by <a href="http://tomayko.com">Ryan Tomayko</a> called "<a href='http://tomayko.com/writings/unicorn-is-unix'>I like Unicorn because it's Unix</a>". Here's my config file: @@@ nginx upstream unicorn { server unix:/var/www/example/current/tmp/sockets/unicorn.sock; } server { listen 80; server_name example.org www.example.org; access_log /var/log/nginx/example.access.log; location / { root /var/www/example/current/public/; if (-f $request_filename) { expires 60h; break; # Static asset } if (-f $document_root/system/maintenance.html) { return 503; # Temporarily unavailable } if (!-f $document_root/system/maintenance.html) { # error_page 500 501 502 503 504 /500.html; proxy_pass http://unicorn; } proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_busy_buffers_size 64k; } # output compression saves bandwidth gzip on; gzip_http_version 1.0; gzip_comp_level 2; gzip_proxied any; gzip_types text/plain text/html text/javascript text/css text/xml application/x-javascript application/atom+xml; } @@@ I also use Passenger from the gang over at Phusion - it's fantastic for getting things going straight away and doesn't require too much hassle - it's what I use on my development box and for smaller sites where I don't need to fiddle with things in the same way. That's a long enough post, hopefully I'll get the next section on static assets and the database up soon. It's important to remember that this is just my opinion, based on my experiences to date (which are somewhat limited given my age) - take everything with a grain of salt and always do your research before diving into something this big.

2009-12-09T08:32:35Z

2 I'm by no means a "scaling expert", but I've recently been doing a lot of research into scaling web applications and the best ways to go about it.What you see below is a rough guide based on what I've learnt - it's not scaling gospel or even an accurate or thorough discussion of all different techniques or schools of thought that can be applied to scaling.So, what does this series of posts cover?<ul> <li>What scaling is;</li> <li>When/who you should think about scaling;</li> <li>The web server (two parts: the box and the software);</li> <li>The static assets;</li> <li>The database;</li> <li>The Rails code; and</li> <li>Caching</li> </ul> <h2>What scaling is</h2><blockquote>In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added. An analogous meaning is implied when the word is used in a commercial context, where scalability of a company implies that the underlying business model offers the potential for economic growth within the company. <cite><a href="http://en.wikipedia.org/wiki/Scaling">http://en.wikipedia.org/wiki/Scaling</a></cite></blockquote><h2>When to scale</h2>Generally, the consensus seems to be that if your a start-up, fresh out of the oven, scaling is a waste of your time. Get some users first and build your product!Scaling is generally something you consider when your current server setup is getting hammered and the growth of your applications warrants taking things to the next level.<h2>The web server</h2><h3>The box</h3>If you're going to be doing high traffic sites, you'd be stupid (in my opinion) not to get your own hardware - the cost of entry for some relatively good gear isn't that high and in the long run, the flexibility and power that comes with having your own hardware outweighs the hassle.I'm running a Dell PowerEdge 1850 which is housed in a datacentre here in Perth (which makes sense for what I'm hosting on it) - it's not new, but it doesn't need to be - the only reason it was being disposed of by the company I bought it off was because the three year warranty had run out - during the three years however, it hadn't failed once and had been the primary domain controller for the organisation in question.Something to consider carefully is location and if your site is targeted at an international audience, then you'll certainly want to pick a location to keep that new server of yours in a DC where there's good international pipes available (Perth isn't really blessed in this particular area).When picking a datacentre, look for something with n+1 redundancy, diverse entry points for both data carriers and power (preferably off completely different feeds) and good security - taking a look at what carriers provide feeds into the facility is also a must.<h3>The software</h3>For the operating system, I'm a fan of Ubuntu server edition - I'll admit, I've not tried much else (FreeBSD and Debian) and I always come back to Ubuntu - I think that's mainly because my first experiences with Linux were on an Ubuntu box. I keep the install down to the bear minimums - build_essential, iptables, fail2ban, denyhosts, mysql, nginx and a local postfix instance are all that are running (there's probably some other things, but you get the idea - no need for fruit)Personally, I use the nginx (/engine-x/) web server - it's fast at serving static assets and it knows when to get out of the way if I want to pass things off to my Rails app. High profile websites including Wordpress.com and Github are using nginx with great success when it comes to high traffic scenarios.Another part of my setup is Unicorn. Unicorn is written to make use of a number of existing system elements (threads, balancing, etc) which makes it stupidly efficient. For more, see this article by <a href="http://tomayko.com">Ryan Tomayko</a> called "<a href="http://tomayko.com/writings/unicorn-is-unix">I like Unicorn because it's Unix</a>".Here's my config file:<div class="highlight nginx code highlight"><pre>upstream unicorn { server unix:/var/www/example/current/tmp/sockets/unicorn.sock; } server { listen 80; server_name example.org www.example.org; access_log /var/log/nginx/example.access.log; location / { root /var/www/example/current/public/; if (-f $request_filename) { expires 60h; break; # Static asset } if (-f $document_root/system/maintenance.html) { return 503; # Temporarily unavailable } if (!-f $document_root/system/maintenance.html) { # error_page 500 501 502 503 504 /500.html; proxy_pass http://unicorn; } proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_busy_buffers_size 64k; } # output compression saves bandwidth gzip on; gzip_http_version 1.0; gzip_comp_level 2; gzip_proxied any; gzip_types text/plain text/html text/javascript text/css text/xml application/x-javascript application/atom+xml; } </pre></div>I also use Passenger from the gang over at Phusion - it's fantastic for getting things going straight away and doesn't require too much hassle - it's what I use on my development box and for smaller sites where I don't need to fiddle with things in the same way.That's a long enough post, hopefully I'll get the next section on static assets and the database up soon.It's important to remember that this is just my opinion, based on my experiences to date (which are somewhat limited given my age) - take everything with a grain of salt and always do your research before diving into something this big. scaling-a-rails-application-part-1 Scaling a Rails application - Part 1

2009-12-12T07:49:14Z