Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Performance Monitoring Made Easy

149 views

Published on

The simple and practical approach to performance monitoring used at Touristly.

Sponsored by Touristly and presented at Ruby Tuesdays, 7 Nov 2017, Kuala Lumpur.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Performance Monitoring Made Easy

  1. 1. Performance Monitoring Made Easy @kriskhaira
  2. 2. 6 months ago • After a past Ruby Tuesdays meet up • Same train ride home with Liang Zheng Gooi from OnApp • Talked about performance monitoring and Gooi asked me to speak about what we use at Touristly • So here I am. Hope you find it useful.
  3. 3. Why monitor?
  4. 4. “To measure is to know. You can’t improve what you don’t measure” Lord Kelvin
  5. 5. Performance issues accumulate over time • Uncompressed images • Too many API queries in 1 page • N+1 queries • Not caching things that should be cached • Network latency • Technical debt
  6. 6. Distractions • A lot of irrelevant advice out there • “Use GraphQL” • “Use NoSQL” • “That image is too big.” • “No animated GIFs” • “Ruby can’t scale.”
  7. 7. Nobody uses Ruby for speed • Easy and nice to use • Proven • Ecosystem • Conventions • Usually not the problem
  8. 8. Don’t optimise randomly • 80:20 rule • Think about the user • Page load time + perceived page load time • Set goals • Know your targets—how many users, sessions, open rate, CTR, conversions, etc
  9. 9. April 2016 EDM Expectations / goals: >500,000 users, 30% open rate, 6% CTR rate 😅
  10. 10. Measure in production first
  11. 11. Page load time • lighthouse (DevTools > Audits) — “first meaningful paint” • Google’s PageSpeed Insights, Analytics • webpagetest.org — “first interactive time” • gtmetrix.com — for lazy people, also uses YSlow • perflint
  12. 12. perflint $ perflint -u $URL -k $PERFLINT_API_KEY https://touristly.com: [====-----------------] 6.3 Timeout at 120s
  13. 13. Big improvements require teamwork • DevOps • Single point of reference • Easy to inspect together • One-person CLI tools for measuring development make it difficult for others
  14. 14. Skylight
  15. 15. ScoutApp APM
  16. 16. New Relic APM
  17. 17. HTTP benchmarking / load testing for API requests for development or staging
  18. 18. wrk $ wrk -d30s $URL Running 30s test http://localhost:3000/... 2 threads and 10 connections Thread Stats Avg Stdev Max Latency 801.96ms 137.24ms 1.68s Req/Sec 6.77 4.74 48.00 371 requests in 30.06s, 3.40MB read Requests/sec: 12.34 Transfer/sec: 115.96KB
  19. 19. autocannon $ autocannon -d 30 -c 5 $URL Running 30s test @ http://localhost:3000/... 5 connections running [==== ] 20%
  20. 20. Local bandwidth throttling Slow down ports 3000 and 4200 to GPRS-like speeds $ comcast --device=eth0 --latency=500 -- target-bw=50 --default-bw=1000000 --packet- loss=2% --target-addr=8.8.8.8,10.0.0.0/24 -- target-proto=tcp,udp,icmp —target- port=4200,3000
  21. 21. Scratching the surface • Benchmarking Ruby • Network latency • Finding optimal CDN locations
  22. 22. Thank you • Touristly • Kevin Francis for proofreading • Ruby Tuesdays • Liang Zheng Gooi • LRT photo: Yosri042005PuteraLRT.jpg by Yosri, Wikimedia Commons
  23. 23. careers.touristly.com

×