Building & Testing Scalable Rails Applications

Mike Smith

• Technical Lead - Blitz.io

• Ruby developer

• @evilmike

Building a scalable app

A typical Rails stack

• Passenger forwards HTTP requests

• Rails processes generate responses

• Database is shared by all Rails processes

Nginx+Passenger

Rails concurrency

• Multiple Rails worker processes per server

• # of processes is limited by available memory

• Each Rails process handles one request at a time

Key Concept!

• There’s a finite number of requests that can be handled concurrently

• Additional requests wait until the next Rails process becomes available

Speed up your slow requests

Database Queries

• Identify slow database queries

• Optimize queries & add table indexes

• ActiveRecord::Base.explain (Rails 3.2)

Rails Caching

• Page Caching

• Action Caching

• Fragment Caching

• Low-level Caching

Long-running Tasks

• Don’t execute long-running tasks in the request handler

• Use background workers

Resque, Delayed Job

Free Rails to handle dynamic requests

Static Content

• Serve with Nginx, Apache, etc.

• CSS, Images & Javascript

• User-uploaded & generated files (S3, etc)

• Consider using a CDN

HTTP Caching

• Caching layer in front of your Rails process

• Varnish & Rack::Cache

• Expiration model• Expires: Fri, 28 Sep 2012 01:12:32 GMT

• Validation model (Conditional GET)• Last-Modified: Wed, 29 Aug 2012 04:58:08 GMT

• ETag: ae7d971f0

Scale your infrastructure up

Scale vertically

Increase the size of your servers

• More memory, More CPU

• Good for Database servers & Caching servers

Scale horizontally

Add more servers

• Serve more requests at a time

• Good for Application servers & Background workers

Two app servers

Nginx+Passenger Nginx+Passenger

HTTP Load Balancer

4 Application Server Instances

2 Application Server Instances

Load testing tips

Test in a realistic environment

• Use realistic data

• Use an environment that replicates production

Consider your location

• Latency can affect load test results

• Consider running your load test from the region where most of your users originate

Consider the effects of caching

• To test worst-case performance, you may need to bust some caches

• Vary the URL or query parameters

GET /blog/article_1GET /blog/article_2GET /blog/article_3

...

Pay attention to request headers

• Emulate the HTTP headers of your expected clients

•Accept-Encoding: gzip, deflate

• Accept: */*

• User-Agent:

Try

• Sign up & test with 250 virtual users for free

• Engine Yard Cloud users

• http://cloud.engineyard.com/addons/blitz

• Or signup directly

• http://blitz.io