Rail Performance in the Cloud - Opening

Rails Performance In the Cloud 1

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

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

Why Ruby on Rails? 5

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

Rails Conventions 7

So Developers Can Focus on The Application 8

Why Cloud Infrastructure? 9

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

Disposable Resources Mean… 11

Only Pay For What You Use 12

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

High Performance = Customer Satisfaction 14

High Performance = User Engagement 15

Satisﬁed Customers Tell Other People 16

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

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/ﬁles/delayexp.pdf 18

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

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

Performance = Competitive Advantage 21

Everyone Hates Waiting 22

Let’s Get More Concrete 23

HOME PAGE SEARCH 24

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

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

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

So How Do I…? 28

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 Efﬁcient Javascript Object Instantiation 29

There are Many Levers In" Performance Optimization 30

But Only A Few Matter 31

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

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

The Rules for Optimized Page Construction 1. Minimize HTTP Requests 12. Remove Duplicate Scripts 2. Use a Content Delivery Network 13. Conﬁgure 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

Engine Yard and Rails to the Rescue 1. Minimize HTTP Requests 12. Remove Duplicate Scripts 2. Use a Content Delivery Network 13. Conﬁgure 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

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

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

3. Suitable Architecture (For Your Scale) 38

Foundation: Patterns of Performance At Scale Non Difﬁculty of Implementation ACID Datastores Sharded Data Task Partitioned Asynch Data Processing Caches Scale 39

Foundation: High Performance Components 40

Engine Yard Stack 41

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

Foundation: Sufﬁcient Infrastructure Resources • Resource monitoring • Process monitoring • Uptime monitoring • React on-demand 43

Don’t make people wait 44

Focus on end user performance 45

Pull the right levers 46

Choose the right partners 47

http://www.engineyard.com	94
http://me:4000	3
http://staging.engineyard.com	3
http://www.slideshare.net	2

Rail Performance in the Cloud - Opening

by Engine Yard on Nov 04, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 102

Statistics

Rail Performance in the Cloud - Opening — Presentation Transcript