Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Brace for impact

Brace for impact

How to prepare for high load scenarios and traffic spikes - Fight the "Slashdot Effect". Held at @bephpug, Berlin.

Christoph Lühr

December 04, 2012
Tweet

More Decks by Christoph Lühr

Other Decks in Programming

Transcript

  1. @bephpug 2012
    Christoph Lühr
    @chluehr
    Brace for impact

    View Slide

  2. basilicom

    View Slide

  3. View Slide

  4. High Load Scenarios
    (short term)

    View Slide

  5. §
    DISCLAIMER
    PHP

    View Slide

  6. ( if successful )
    ==
    TV

    View Slide

  7. /.
    "Slashdot Effect"
    ( now: Facebook, Bild.de, ... )

    View Slide

  8. Bäm!

    View Slide

  9. Why care?

    View Slide

  10. $$$
    TV ads are expensive
    downtime == wasted money

    View Slide

  11. Why me?
    5 yrs++
    Deutsche Bahn, Ferrero, Peugeot
    BMW, Sony, UMG, studiVZ, ...

    View Slide

  12. Image source: http://www.flickr.com/photos/stinajonsson/3932774410 CC BY-NC 2.0

    View Slide

  13. Flight Plan
    1. MAKE A PLAN
    2. MAKE IT SCALE?
    3. MAKE IT FAST!
    4. [ TEST, SIZE ]
    5. WATCH IT!
    6. BONUS: EXAMPLES
    } Architecture

    View Slide

  14. Brace for impact

    View Slide

  15. Brace for impact
    Plan

    View Slide

  16. Knowledge is Power
    Media plans
    TV schedules

    View Slide

  17. View Slide

  18. Planning
    ● just Peaks matter
    ● Media / marketing exposure?
    ● Target group? Click Rate?
    ● Max. daily visits? Top hour?
    ● Pages ^ visit, resources ^ page?
    ● Do not forget storage / traffic requirements.

    View Slide

  19. Planning

    View Slide

  20. Planning

    View Slide

  21. Architecture
    ( & Tool Time )

    View Slide

  22. E l a s t i c i t y
    Scaling
    Fancy Solution

    View Slide

  23. 1 4 5
    7 n
    1 2 3
    6
    "just add more boxes.."

    View Slide

  24. really?

    View Slide

  25. System complexity ++

    View Slide

  26. Database?

    View Slide

  27. Time to spawn?
    .......

    View Slide

  28. TV-Ad
    10 sec. later
    10 min. later

    View Slide

  29. Performance ++
    Traditional Solution

    View Slide

  30. Performance
    SERVER BROWSER USER

    View Slide

  31. Performance
    SERVER BROWSER USER
    FAST!

    View Slide

  32. Performance Rules

    View Slide

  33. Rule #1
    Don't get hit.
    ● landing page on a different server.

    View Slide

  34. Rule #2
    Let others do the work
    ● use a Content Delivery Network
    (CloudFlare is free).

    View Slide

  35. Rule #3
    Serve static content

    View Slide

  36. SERVE
    STATIC
    CONTENT!

    View Slide

  37. Rule #3
    Serve static content
    ● use a caching reverse proxy:
    Varnish
    ● NGINX is fast, too
    ● "static" can even mean only 5 mins.

    View Slide

  38. Rule #4
    Serve static content once
    ● use correct cache headers
    ● leverage browser caches
    ● allow external proxies to cache
    your content.

    View Slide

  39. Rule #5
    Minimize requests
    ● compress HTML
    ● combine / minify JS, CSS
    ● inline images
    ● == get a good SpeedRanking.

    View Slide

  40. Rule #6
    Avoid dynamic requests
    ● load data upfront
    ● stay in browser, validate via JS first
    ● collect data / batch requests
    ● load only on action (captcha, ...).

    View Slide

  41. Rule #7
    small
    is BIG
    ● don't load a framework for an insert()
    ● just write a logfile?
    ● use nodeJS.

    View Slide

  42. Rule #8
    De-couple / postpone
    ● use queuing and finite # of workers
    ● use external services
    (transloadit, youtube, ...).

    View Slide

  43. Rule #9
    Degrade gracefully
    ● skip doing hard work (thumbnails,...)
    ● hide expensive functionality (edit)
    ● ... to keep the site online.

    View Slide

  44. Secret Rule #10
    Cheat
    ● discard requests
    ● stats & voting: sample only 10%
    ● simulate server calls (spinner).

    View Slide

  45. Final Rule #11
    Don't go offline.
    ● put campaign on different server
    ● limit resources, don't kill your server
    ● if all fails, be sure to display a notice.

    View Slide

  46. View Slide

  47. Testing
    ● Goal: Determine app limits/threshold
    ● Testing is HARD
    ● Test the production environment
    ● Monitor performance & resources
    ● httperf, apache bench, siege, JMeter.

    View Slide

  48. Sizing & Tuning

    View Slide

  49. Sizing & Tuning
    ● RAM
    ● CPU cores / CPU speed
    ● IO: Storage Type / Storage Size
    ● Cache memory (Varnish)
    ● MySQL tuning (Caches, ...)
    ● System/Network tuning (max_open_files, ...)
    ● Apache (max. childs, ...)

    View Slide

  50. Rinse, repeat.
    (building, testing, sizing)

    View Slide

  51. Online:
    Monitoring
    Image source: http://www.officialpsds.com/Green-Radar-Screen-PSD61002.html Attribution

    View Slide

  52. Monitoring
    ● Access (Google Analytics)
    ● External Availability (Pingdom, ...)
    ● Speed, Latency &
    Resources (New Relic, ...)
    ● Application (# participants, ... StatHat)
    ● OR homegrown (statsd, etc.).

    View Slide

  53. Examples

    View Slide

  54. Forms

    View Slide

  55. Forms
    1
    2
    3

    View Slide

  56. Gallery detail pages
    http://foo.com/view/?key=3Jsk31KOsk2
    IMAGE

    View Slide

  57. Gallery detail pages
    http://foo.com/view/?key=3Jsk31KOsk2 ==> :-(
    http://foo.com/view/ #3Jsk31KOsk2 ==> :-)
    static!
    3Jsk31KOsk2.JPG

    View Slide

  58. Simplified setup

    View Slide

  59. Summary

    View Slide

  60. SERVE
    STATIC
    CONTENT!

    View Slide

  61. CRITICAL
    LOAD FOLLOWS

    View Slide

  62. Suggestions?
    Questions?

    View Slide

  63. Contact
    Christoph Lühr
    eMail: [email protected], [email protected]
    Twitter: @chluehr
    Slides license
    Attribution-NonCommercial-ShareAlike 3.0
    http://creativecommons.org/licenses/by-nc-sa/3.0/
    Thanks
    ... and always have a safe landing!

    View Slide

  64. Links
    ● Google PageSpeed Insights
    https://developers.google.com/speed/pagespeed/insights
    ● Transloadit: Image / Video uploads / conversion
    https://transloadit.com/
    ● Pingdom Monitoring & Tools
    http://tools.pingdom.com/fpt/
    ● New Relic application & server monitoring
    http://newrelic.com/
    ● CloudFlare CDN
    https://www.cloudflare.com/

    View Slide

  65. Links
    ● Continuous Performance Testing
    http://qafoo.
    com/talks/12_05_ipc_se_continuous_performance_tests.pdf
    ● Varnish
    https://www.varnish-cache.org/
    ● Varnish Speed
    http://kly.
    no/posts/2010_10_23__High_End_Varnish___275_thousand_request
    s_per_second___.html

    View Slide

  66. Links
    ● NGINX
    http://www.slideshare.net/Edorian/nginx-php-fpm-the-
    webserver-you-might-actually-like-php-usergroup-berlin
    ● High Performance Web Sites - Steve Souders
    http://shop.oreilly.com/product/9780596529307.do
    ● Pound Load Balancer, Reverse Proxy & SSL Offloader
    http://www.apsis.ch/pound

    View Slide