What wil happen first? Apache eating up al RAM? Too many MySQL connections? I/O trash/wait halting everything?
OH NO, WE ARE DOOMED
the good news:
suddenly: an ad on TV during prime time hours ... ... airs at a pre-determined time
that helps, but you still need to make it web scale
OPTIONS FOR SCALING OUT 1.Add hardware & caching 2.Build it yourself • and deal with “great” code • Investment up front • Recurring license costs.. • Needs maintenance • . . per server, usually! • Hybrid approach makes a lot of sense: keep old • Rinse and repeat for the software for cart, next shop you launch checkout, payment, . .
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
AND DON’T WORRY ABOUT CHECKOUT GOING DOWN
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
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
forget “random” scale-out from hardware to EC2 (data replication, latency, . .)
We chose option B. Then option C. Then B again :)
SYMFONY delivers! :)
it’s great, lots of bundles, community, blah. . we all know that, right? :)
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
ELASTICSEARCH (or Solr, if you prefer that)
not just for search
why not store all data (products, categories, . .) in there?
distribution & HA built-in
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
No Gearman, your operations must be serialized
CACHE everything as much as you can
use grace and saint modes
done, problem solved?
users have shopping carts
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
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
ESIs are processed sequential y!
CI: Jenkins (or Travis, . .)
Provisioning: Puppet (or Chef)
bring new boxes, staging envs (LXC, Xen, . .) up quickly
make sure stage mimics production (logical nodes, LB, . .)
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, . .
MEASURE, LOG AND TEST everything
profile your stuff, with XHProf, not “some” debug toolbar ;)
log errors, performance metrics, user flows
and keep this data (disk, tape, Hadoop HDFS, whatever)
give your developers access to this data (logstash, HDFS, . .)