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

Surviving a Prime Time TV Commercial (SFLivePortland2013 2013-05-23)

Surviving a Prime Time TV Commercial (SFLivePortland2013 2013-05-23)

Presentation given at Symfony Live Portland 2013 in Portland, OR, United States.

David Zuelke

May 23, 2013
Tweet

More Decks by David Zuelke

Other Decks in Programming

Transcript

  1. SURVIVING A PRIME TIME
    TV COMMERCIAL

    View Slide

  2. David Zülke

    View Slide

  3. David Zuelke

    View Slide

  4. View Slide

  5. http://en.wikipedia.org/wiki/File:München_Panorama.JPG

    View Slide

  6. Lead Architect

    View Slide

  7. View Slide

  8. @dzuelke

    View Slide

  9. THE CHALLENGE
    (who doesn’t love a challenge?)

    View Slide

  10. View Slide

  11. View Slide

  12. happily running an off-the-shelf e-commerce solution

    View Slide

  13. suddenly: an ad on TV during prime time hours

    View Slide

  14. = up to 10k unique visitors within a minute or two

    View Slide

  15. and before you can count to three...

    View Slide

  16. View Slide

  17. View Slide

  18. 0
    5000
    10000
    15000
    20000
    20:44 20:45 20:46 20:47 20:48 20:49 20:50 20:51 20:52
    Requests per minute

    View Slide

  19. What will happen first?
    Apache eating up all RAM?
    Too many MySQL connections?
    I/O trash/wait halting everything?

    View Slide

  20. OH NO,
    WE ARE
    DOOMED

    View Slide

  21. the good news:

    View Slide

  22. suddenly: an ad on TV during prime time hours
    ... airs at a pre-determined time
    ...

    View Slide

  23. that helps, but you still need to make it web scale

    View Slide

  24. OPTIONS FOR SCALING OUT
    1.Add hardware & caching
    • and deal with “great” code
    • Recurring license costs...
    • ... per server, usually!
    • Rinse and repeat for the
    next shop you launch
    2.Build it yourself
    • Investment up front
    • Needs maintenance
    • Hybrid approach makes
    a lot of sense: keep old
    software for cart,
    checkout, payment, ...

    View Slide

  25. OUR GOALS
    • Home page, product detail, category browser, search: <100 ms
    • Try to degrade, but not to fail, under extreme load
    • Prefer failures for some users over slowness for all users
    • Sacrifice freshness of data and features for performance
    • Replicate any change in product DB to front-end in <60 s

    View Slide

  26. AND DON’T WORRY ABOUT
    CHECKOUT GOING DOWN

    View Slide

  27. FOR THAT, WE NEED:
    • A share-nothing architecture (or at least a “share little” one)
    • Failover configurations where needed (load balancer, cache, ...)
    • An FTS capable database that withstands a lot of parallel reads
    • Ideally, an approach where we don’t even hit an app server

    View Slide

  28. TRADITIONAL HOSTING
    OR THE CLOUD?
    A) Host everything yourself
    B) Only use SaaS and components like S3, CDNs and so forth
    C) Host some parts yourself, and others on AWS or similar
    D) Host everything in the cloud

    View Slide

  29. forget “random” scale-out from hardware to EC2
    (data replication, latency, ...)

    View Slide

  30. We chose option B. Then option C. Then B again :)

    View Slide

  31. SYMFONY
    delivers! :)

    View Slide

  32. it’s great, lots of bundles, community, blah...
    we all know that, right? :)

    View Slide

  33. SPECIAL MENTIONS
    • Bundle Inheritance
    • Base implementations for Search, Product, Category, ...
    • Sites (Kiveda, ...) may override templates, controllers, ...
    • Twig
    • Share templates (at least some) between “Fox” and OXID

    View Slide

  34. ELASTICSEARCH
    (or Solr, if you prefer that)

    View Slide

  35. not just for search

    View Slide

  36. why not store all data (products, categories, ...) in there?

    View Slide

  37. distribution & HA built-in

    View Slide

  38. REPLICATING MYSQL TO ES
    • Triggers on product/category/... tables write to a table with
    commands for replication
    • Script (Symfony CLI) runs periodically, reads replication
    commands and replays them into ElasticSearch
    • supervisord keeps it alive (crons could overtake each other)
    • Sends PURGE commands to Varnish

    View Slide

  39. No Gearman, your operations must be serialized

    View Slide

  40. CACHE
    everything
    as much as you can

    View Slide

  41. Varnish!

    View Slide

  42. use grace and saint modes

    View Slide

  43. done, problem solved?

    View Slide

  44. users have shopping carts

    View Slide

  45. LOGINS & SHOPPING CARTS
    A) ESI:
    Set cookie when adding to cart, detect cookie in VCL
    B) XHR:
    No server-side work, but latency on the client side, and you
    need to deal with CORS even for just HTTP vs HTTPS
    C) Signed cookies

    View Slide

  46. ESI TRICK FOR THE CART
    1. Set marker cookie (with a lifetime) when adding to cart
    2. Page contains
    3. If cookie above exists, hit backend
    4. If not, rewrite location to “/cart_empty.html” in vcl_fetch
    5. Same can be done for logged in users

    View Slide

  47. ESIs are processed sequentially!

    View Slide

  48. AUTOMATE
    everything

    View Slide

  49. CI: Jenkins (or Travis, ...)

    View Slide

  50. Deployment: Capistrano

    View Slide

  51. Provisioning: Puppet (or Chef)

    View Slide

  52. bring new boxes, staging envs (LXC, Xen, ...) up quickly

    View Slide

  53. make sure stage mimics production (logical nodes, LB, ...)

    View Slide

  54. ADDED BENEFIT: DEV ENVS!
    • Build a Veewee base box that mirrors production config
    • Use Vagrant and Puppet manifests from production for dev!
    • Quickly test e.g. a new ElasticSearch node going up or down
    • For the future:
    • Run staging using https://github.com/fgrehm/vagrant-lxc
    • Devs can log in and kill the database, add web nodes, ...

    View Slide

  55. MEASURE, LOG AND TEST
    everything

    View Slide

  56. profile your stuff, with XHProf, not “some” debug toolbar ;)

    View Slide

  57. log errors, performance metrics, user flows

    View Slide

  58. and keep this data (disk, tape, Hadoop HDFS, whatever)

    View Slide

  59. give your developers access to this data (logstash, HDFS, ...)

    View Slide

  60. load test using this data (Siege/JMeter/Tsung)

    View Slide

  61. https://github.com/j2labs/microarmy

    View Slide

  62. https://github.com/newsapps/beeswithmachineguns

    View Slide

  63. OUTSOURCE
    everything
    anything tedious

    View Slide

  64. storage and backups (to S3 and friends)

    View Slide

  65. content delivery (CloudFront, CloudFlare, ...)

    View Slide

  66. transactional email (Mandrill, Postmark, SendGrid, ...)

    View Slide

  67. metrics/logging/monitoring (New Relic, Loggly, Silverline)

    View Slide

  68. !e End

    View Slide

  69. Questions?

    View Slide

  70. kidding, this is a keynote slot and I want breakfast ;)

    View Slide

  71. THANK YOU!
    This was
    http://joind.in/8669
    by @dzuelke.
    Questions: [email protected]

    View Slide