Surviving a Prime Time TV Commercial (DPC2013 2013-06-07)

Surviving a Prime Time TV Commercial (DPC2013 2013-06-07)

Presentation given at Dutch PHP Conference 2013 in Amsterdam, The Netherlands.


David Zuelke

June 07, 2013


  1. 4.
  2. 7.
  3. 10.
  4. 11.
  5. 16.
  6. 17.
  7. 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
  8. 19.

    What will happen first? Apache eating up all RAM? Too

    many MySQL connections? I/O trash/wait halting everything?
  9. 22.

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

    airs at a pre-determined time ...
  10. 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, ...
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 41.
  17. 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
  18. 46.

    ESI TRICK FOR THE CART 1. Set marker cookie (with

    a lifetime) when adding to cart 2. Page contains <esi:include  href=”/cart”  /> 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
  19. 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 • Devs can log in and kill the database, add web nodes, ...
  20. 68.