• Save
Rail Performance in the Cloud - Opening
Upcoming SlideShare
Loading in...5
×
 

Rail Performance in the Cloud - Opening

on

  • 2,497 views

Tom Mornini will walks through what to expect.

Tom Mornini will walks through what to expect.

Statistics

Views

Total Views
2,497
Slideshare-icon Views on SlideShare
2,395
Embed Views
102

Actions

Likes
0
Downloads
2
Comments
0

4 Embeds 102

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

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Rails devs consistently report being 2-5 times faster at delivering feaueatures
  • Convention over configuration
  • Average page views over one second

Rail Performance in the Cloud - Opening Rail Performance in the Cloud - Opening Presentation Transcript

  • 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
  • 4
  • 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
  • Satisfied 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/files/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 Benefit? • 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 Efficient 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. 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
  • 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
  • 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 Difficulty 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: Sufficient 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