Rail Performance in the Cloud - Opening
•
0 likes•803 views
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.
Report
Share
More Related Content
What's hot
What's hot (20)
Similar to Rail Performance in the Cloud - Opening
Similar to Rail Performance in the Cloud - Opening (20)
Recently uploaded
Recently uploaded (20)
Rail Performance in the Cloud - Opening
- 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
- 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
Editor's Notes
- Rails devs consistently report being 2-5 times faster at delivering feaueatures
- Convention over configuration
- Average page views over one second