This document discusses optimizing performance for Ruby on Rails applications in the cloud. It begins with introductions and an agenda for the event. It then discusses why Rails development is faster and how its conventions allow developers to focus on the application. It explains how cloud infrastructure provides instant, programmable resources on demand and only charges for what is used. It outlines how performance impacts user satisfaction, engagement, organic search rankings and competitive advantage. It then gets more concrete by discussing performance thresholds and load times for 100 Rails sites. Finally, it discusses the top five sources of high performance and how to optimize page construction, application code, software architecture, component selection and infrastructure capacity.

1. Rails Performance
In the Cloud
1

2. About Me
Tom Mornini
• Co-founder and CTO of
Engine Yard
• Ruby on Rails advocate
2

3. Agenda
Time Topic
8:45 am – 9:10 am Introductions
9:10 am – 9:40 am Amazon Web Services
9:40 am – 10:10 am New Relic
10:10 am – 10:15 am Break
10:15 am – 10:55 am Engine Yard Cloud
10:55 am – 11:25 am CVSDude
11:25 am – 11:55 am CloudTest by Soasta
11:55 am – 12:00 pm Wrap Up
3

4. 4

5. Why Ruby on Rails?
5

6. Rails Development Is 2x - 5x Faster
Source: Engine Yard Developer Survey
6

7. Rails Conventions
7

8. So Developers Can Focus on The Application
8

9. Why Cloud Infrastructure?
9

10. Instant Programmable Infrastructure
# get a list of buckets
s3.get_service
# create a bucket
s3.put_bucket('bucketname')
# get the contents of that
bucket
s3.get_bucket('bucketname')
# delete that bucket
s3.delete_bucket('bucketname')
10

11. Disposable Resources Mean…
11

12. Only Pay For What You Use
12

13. Slow Pages Waste 4,908 Lifetimes Every Year! :)
13

14. High Performance = Customer Satisfaction
14

15. High Performance = User Engagement
15

16. Satisfied Customers Tell Other People
16

17. Wikia: Exit Rate vs. Page Load Time
30%
23%
• Wikia Source Data
15%
8%
0%
0.0 1.0 2.0 3.0 4.0 5.0
Seconds
Source: Velocity 2009
17

18. Google Search Latency Experiment
• Measure result of artificially
induced latency
• Search volume per user
decreased by 0.8% with an
artificial 400ms delay
• Effect cumulative over time
and persisted after
experiment’s timeframe
Source: http://code.google.com/speed/files/delayexp.pdf
18

19. High Performance = AdWord Ranking
http://adwords.google.com/support/aw/bin/answer.py?hl=en&answer=93112
19

20. High Performance = Organic Search Benefit?
• Certainty: very slow pages are skipped by indexer
• Possibility: slower pages = higher bounce rate = lower
organic search score
20

21. Performance = Competitive Advantage
21

22. Everyone Hates Waiting
22

23. Let’s Get More Concrete
23

24. HOME PAGE
SEARCH
24

25. The Four Stages of Performance
Delight
Satisfaction
(<1s)
Frustration
(1-4s)
Abandonment
(4-8s)
(8s+)
25

26. Conventional Wisdom: Performance Thresholds
Delight (<1s)
Satisfaction (1-4s)
Frustration (4-8s)
3.4s
Average Web
Load Time
Abandonment (8-20s)
Source: Apdex, http://blog.gomez.com/2009/08/a-look-at-the-browser-wars/
26

27. Page Load Performance: 100 Rails Sites
25
20 Google Analytics, Ads
DoubleClick FBConnect, CDNs…
15
10 3.1s Median Load Time
5
0
US average web-site load time 3.4s
Sources: Engine Yard Rails Site Survey, using Yahoo! YSlow
27

28. So How Do I…?
28

29. Just Follow These Few Simple Strategies…
No XMLhttprequest
DatamapperTuned
SQL
Asynchronous Processing
Avoid eval
Multiple Asset Hosts
SMP Hardware
JRuby
No CSS Expressions
Close your HTML tags
Tokyo Cabinet
InterNAP
Work Brokers
Preloading
Linux Tuning Fragment Caching
Nehalem
Less Gzip
No Redirects
Lockrun
NoSQL
10 GiGE
Redis
SSD’s
More Gzip
CDN
eTag Caching In
memory caching
Cassandra
Script Decoalescing
http caching Native Hardware
Virtualized Hardware
Page Caching
iFrames
Multi-cast
DB Sharding
memcached
Action Caching
Xen Tuning
Ruby 1.9
AMQP
Cookie Free Domains
Minimize DOM
CSS Sprites
MongoDB
Script coalescing
Message Buses Lazy Loading
No Image Resizing
Minify Text
JVM Flags
Unicorn
Image Pre-Compression
Efficient Javascript Object Instantiation
29

30. There are Many Levers In"
Performance Optimization
30

31. But Only A Few Matter
31

32. Five Sources of High Performance
1. Page Construction
2. Application Code
3. Software Architecture
4. Component Selection
5. Infrastructure Capacity
32

33. 1. Page Construction
• Page size
• Javascript size
• Load order
• Image configuration
• http requests
• Domain configuration
• CSS layout
• …
33

34. The Rules for Optimized Page Construction
1. Minimize HTTP Requests
12. Remove Duplicate Scripts
2. Use a Content Delivery Network
13. Configure ETags
3. Expires or Cache-Control Headers
14. Make AJAX Cacheable
4. Gzip Components
15. Use GET for AJAX Requests
5. Put StyleSheets at the Top
16. Reduce the Number of DOM Elements
6. Put Scripts at the Bottom
17. No 404s
7. Avoid CSS Expressions
18. Reduce Cookie Size
8. Make JavaScript and CSS External
19. Use Cookie-Free Domains
9. Reduce DNS Lookups
20. Avoid Filters
10. Minify JavaScript and CSS
21. Do Not Scale Images in HTML
11. Avoid Redirects
22. Make favicon.ico Small and Cacheable
Source: ySlow Performance Checks
34

35. Engine Yard and Rails to the Rescue
1. Minimize HTTP Requests
12. Remove Duplicate Scripts
2. Use a Content Delivery Network
13. Configure ETags
3. Expires or Cache-Control Headers
14. Make AJAX Cacheable
4. Gzip Components
15. Use GET for AJAX Requests
5. Put StyleSheets at the Top
16. Reduce the Number of DOM Elements
6. Put Scripts at the Bottom
17. No 404s
7. Avoid CSS Expressions
18. Reduce Cookie Size
8. Make JavaScript and CSS External
19. Use Cookie-Free Domains
9. Reduce DNS Lookups
20. Avoid Filters
10. Minify JavaScript and CSS
21. Do Not Scale Images in HTML
11. Avoid Redirects
22. Make favicon.ico Small and Cacheable
Rails 3 Bringing Even More: CSS Sprite Support and Lazy JavaScript
35

36. Engine Yard Rails Site Survey Findings
• # of HTTP requests and JavaScript payload size were
the statistically significant contributors to load time
• Each http request adds 0.04s to page download time
• Each 100Kb of JavaScript = 0.74s added to load time
• Many pages constructed with blocking JavaScript loads
• 25% of payload is now JavaScript
36

37. 2. Patterns of Fast Rails Application Code
• Eager loading of associations
• Do as little as possible during the http request cycle
• Gem due diligence
37

38. 3. Suitable Architecture (For Your Scale)
38

39. Foundation: Patterns of Performance At Scale
Non
Difficulty of Implementation
ACID
Datastores
Sharded
Data
Task
Partitioned
Asynch
Data
Processing
Caches
Scale
39

40. Foundation: High Performance Components
40

41. Engine Yard Stack
41

42. Rails 3 + Ruby 1.9 Benchmarks
• Substantial effort to refactor out slowness in common
operations
• Micro-benchmarks seeing 2-8x + improvements
• Hello World
• Render
• Partials
• 10 Partials
• Collections
42

43. Foundation: Sufficient Infrastructure Resources
• Resource monitoring
• Process monitoring
• Uptime monitoring
• React on-demand
43

44. Don’t make people wait
44

45. Focus on end user performance
45

46. Pull the right levers
46

47. Choose the right partners
47