This presentation is the first in a series on Improving Rails application performance. This session covers the basic motivations and goals for improving performance, the best way to approach a performance assessment, and a review of the tools and techniques that will yield the best results. Tools covered include: Firebug, yslow, page speed, speed tracer, dom monster, request log analyzer, oink, rack bug, new relic rpm, rails metrics, showslow.org, msfast, webpagetest.org and gtmetrix.org. The upcoming sessions will focus on: Improving sql queries, and active record use Improving general rails/ruby code Improving the front-end And a final presentation will cover how to be a more efficient and effective developer! This series will be compressed into a best of session for the 2010 http://windycityRails.org conference

1. Performance Monitoring
John McCaffrey
1. Why does performance matter?
2. Know your Business Metrics
3. Quick ways assess application performance
4. Monitoring tools to help you track performance

2. Why does performance matter?
• Revenue
• Costs
• Time
• Competition
• User satisfaction

3. Why does performance matter?
• Google cares!
• "Speeding up websites is important .. faster sites don't
just improve user experience...improving site speed also
reduces operating costs. Like us, our users place a lot of
value in speed - that's why we've decided to take site
speed into account in our search rankings. "

4. When should I start caring?
• Capacity planning
• Design
• Growth
• Development
• Testing
• Deployment
• Monitoring

5. What am I tracking?
Business Metrics
• Page visits per day
• Page visits per user per day
• Time on site
• Searches performed
• Products views
• Orders

6. SHOPZILLA
Improving
from 6 sec
down to
1.2
seconds
6

7. Netflix:
43% drop in outbound traffic
after enabling gzip
7

8. Making a business case

9. So we know that performance matters.
Now what?
9

10. Performance Terms
Latency = seconds per job, or "how long it takes"
Throughput = jobs per second, or "how many workers"
Average Response time = average latency
Requests per second = average throughput
If 1 worker that can compute 1 job in .5 sec
latency = .5 secs per job
throughput = 2 jobs per sec

11. Quick ways to check your stats
• Eyeball the log files
• Use Log reading tool
• Use browser tools
o Confirm your dev env vs staging
• External site tests
o Compare values outside of your network
o Repeatable tests

12. Eyeball it
Processing UserSessionsController#new (for 127.0.0.1 at
2010-05-15 10:11:09) [GET]
Parameters: {"action"=>"new", "controller"=>"user_sessions"}
Rendering template within layouts/login
Rendering user_sessions/new
Completed in 202ms (View: 105, DB: 42) | 200 OK [http://localhost/
login]

13. Log analyzer
gem install request-log-analyzer
request-log-analyzer log/development.log

14. Yslow

15. Page Speed

16. Speed Tracer

17. Microsoft tools
– Dynatrace
– MsFast
– VRTA
– Fiddler
– Developer tools

18. Dom Monster
http://javascriptrocks.com/performance/
18

19. Are these numbers right?
• Are they consistent?
• Do they seem reasonable
• How can we repeat the tests?
• Can we reproduce them in all environments?
• What should we investigate next?

20. External tools
– http://zoompf.com
– http://webo.name/
– http://tools.pingdom.com/
– http://gtmetrix.com
– http://www.webpagetest.org/
– http://www.site-perf.com/
– http://webwait.com

21. GtMetrix.com
21

22. Don’t change anything!
– Resist the urge to change a bunch of stuff
– Test coverage
– repeatable perf tests
– don't break anything!
– focus on low hanging fruit first
– get your monitoring in place before you make any
major changes
– don't make it less maintainable
– pair & share

23. Taking multiple measurements
– Monitor performance over time
– Manually keep an eye on your yslow/resp time
– http://loadimpact.com/
– Apache Bench, Httperf
– Jmeter

24. showslow.com
http://127.0.0.1/showslow/

25. New Relic

26. New Relic

27. Rails Metrics
27

28. Rack Bug
28

29. Now What?
– Summarize and describe your observations
– Prioritize based on ease of change and expected
impact
– Make your changes in a branch
– Compare your results
– Look for patterns of optimization
– Work with your team

30. Nuggets of Wisdom
• Gzip
• Get very familiar with yslow
• Look through your logs, analyze them
• Turn on slow query logging for db
• Upgrade your libraries (js, plugins)
• Use RVM (try new plugins, rails, ruby)
30

31. Upcoming Presentations
– Chicago Javascript
– Improving Page performance
– ChicagoRuby
– Improving Rails app performance
– Improving Developer performance!
– WindyCityRails 2010
– Improving Rails Application Performance
– twitter: @j_mccaffrey

32. References
– http://railsperformance.blogspot.com/ (me)
– Railslab http://railslab.newrelic.com/
– Steve Souders http://www.stevesouders.com/blog/
– http://velocityconference.blip.tv/
– http://code.google.com/events/io/2010/
– http://speedgeeks-la.blip.tv/
– http://developer.yahoo.com/performance/
– http://code.google.com/speed/page-speed

33. References
• http://guides.rubyonrails.org/performance_testing.html
33