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.
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
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
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
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
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
39. Foundation: Patterns of Performance At Scale
Non
Difficulty of Implementation
ACID
Datastores
Sharded
Data
Task
Partitioned
Asynch
Data
Processing
Caches
Scale
39