The simple and practical approach to performance monitoring used at Touristly. Sponsored by Touristly and presented at Ruby Tuesdays, 7 Nov 2017, Kuala Lumpur.

1. Performance
Monitoring Made Easy
@kriskhaira

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. Why monitor?

4. “To measure is to know. You can’t
improve what you don’t measure”
Lord Kelvin

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. 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. Nobody uses Ruby for
speed
• Easy and nice to use
• Proven
• Ecosystem
• Conventions
• Usually not the problem

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. April 2016 EDM
Expectations / goals: >500,000 users, 30% open rate, 6% CTR rate
😅

10. Measure in
production first

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. perflint
$ perflint -u $URL -k $PERFLINT_API_KEY
https://touristly.com:
[====-----------------] 6.3 Timeout at 120s

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. Skylight

18. ScoutApp APM

19. New Relic APM

20. HTTP benchmarking /
load testing for API
requests
for development or staging

21. 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

22. autocannon
$ autocannon -d 30 -c 5 $URL
Running 30s test @ http://localhost:3000/...
5 connections
running [==== ] 20%

23. 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

24. Scratching the surface
• Benchmarking Ruby
• Network latency
• Finding optimal CDN locations

25. Thank you
• Touristly
• Kevin Francis for proofreading
• Ruby Tuesdays
• Liang Zheng Gooi
• LRT photo: Yosri042005PuteraLRT.jpg by Yosri,
Wikimedia Commons

26. careers.touristly.com