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

Scaling Craft CMS Sites for Large Launches

Matt Weinberg
September 28, 2018

Scaling Craft CMS Sites for Large Launches

My presentation at the 2018 Craft CMS conference, Dot All.

This talk provides a clear set of steps, guides, and testing/analysis methods for launching Craft sites that will be highly visible, need to have close to perfect uptime, have legal requirements about being available in multiple geographic regions, and/or just get a whole lot of traffic. It will address Craft setup and caching choices, infrastructure choices, performance optimization, load testing, and more. It will also focus on some of the great performance changes in Craft 3.

Matt Weinberg

September 28, 2018
Tweet

More Decks by Matt Weinberg

Other Decks in Technology

Transcript

  1. Goals for the talk • Address “things to think about”

    when launching mission-critical Craft sites • Explain various approaches to scaling, high uptime, and redundancy • Provide a pre-launch checklist • Help everyone launch faster Craft sites with more uptime
  2. Who am I? • Co-founder and President of Development at

    Vector Media Group • 50 people, based in NYC • Craft service partners • Significant amount of Craft work, including very large sites
  3. 1. Performant: quickly answer real-world traffic 2. Redundant + Horizontally

    scalable: handle traffic surges and survive partial service degradations 3. Visible: easily predict and monitor performance under various scenarios 4. Secure: follows best practices What should “scaling” mean to you?
  4. Performance • Many factors involved in a user’s total load

    speed. Asset loading, CSS structure, etc. ◦ Andrew Welch’s “Making a Craft CMS Website That FLIES” presentation yesterday • Next few slides concentrate only on TTFB - time to first byte. ◦ Other factors are very important for users but a little different from the scaling questions here • Reducing web server load makes everything else easier
  5. TTFB (Time To First Byte) • Time between initial request

    and getting any response back • Craft/PHP compiles, parses, and renders the templates • Lower TTFB means: ◦ Faster site for users ◦ Server freeing up resources more quickly • Measure in Chrome or webpagetest.org
  6. • Static assets (CSS, JS, images, etc…) will have much

    faster load than Craft templates • Template Target: ◦ Good: <200ms ◦ Better: <100ms ◦ Best: <75ms • Fixing low hanging fruit is good but don’t obsess about a 10ms difference TTFB (Time To First Byte)
  7. • Cache aggressively. Anything that can be cached, should be.

    • Cache globally where possible. • Use custom cache keys for geo and other differences • Add config constants if needed Lowering TTFB in Craft
  8. Lowering TTFB in Craft • Make sure OPCache (PHP’s built-in

    bytecode cache) is turned on in php.ini. • Offload as much as you can from the frontend servers ◦ Use CDNs such as Cloudflare, CloudFront, Google Cloud CDN, Akamai, etc to serve static content (JS/CSS/images) ◦ Use hosted cloud services for DB/cache/queue. Trust the experts. ▪ A managed host like Arcustech or a cloud DB service from Amazon (RDS/Aurora) or Google (Cloud SQL) is best for most sites without ops engineers.
  9. Assume multiple tiers • From day 1: assume different server

    tiers, and Craft living on multiple front-end servers • Load balancer means the failure of one frontend server doesn’t bring the site down • Staging site (and local!) should implement this • Multiple FE servers has a few implications for build process
  10. • Earlier: “Offload as much as you can from the

    frontend servers” • Architecting this from the beginning will make it a lot easier later • Everyone: use cloud or NAS object storage for assets ◦ Recommend: Amazon S3, Google Cloud Storage ▪ Name your bucket as a domain (e.g. assets.domain.com) ◦ These are slow; front them with a CDN • Using good managed hosting? Much of the rest will be handled Assume multiple tiers
  11. Assume multiple tiers • Using unmanaged hosting? ◦ Load Balancer

    ▪ Recommend: Amazon ALB, Google CLB, HAProxy ◦ DB ▪ Recommend: Amazon RDS, Google Cloud SQL ▪ Consider PostgreSQL • DataGrip by JetBrains ▪ Consider Aurora/Aurora Serverless ▪ Consider MariaDB or Percona Server ◦ Memory cache ▪ Recommend: Redis
  12. Assume multiple frontends If you’re using the same in-memory cache

    for more than one of caching, sessions, and queuing, you can make the config less repetitive using Yii components.
  13. Assume multiple frontends • NAS/shared file storage is another option

    • We’ve used this successfully with Craft before • Amazon EFS, Google Filestore, or any NAS/NFS mount • Carefully check performance. Can be extremely slow if not configured correctly. ◦ Consider provisioned or premium throughput options
  14. Reverse proxy caching Load Balancer Craft Craft Craft DB Memory

    Cache DB Memory Cache Reverse proxy cache
  15. Reverse proxy caching • At some point you’ll want to

    start thinking about this • Helps take as much load as possible off your application servers • Cloudflare is very popular with Craft sites and has built-in caching ◦ Using Arcustech? You’ll get a faster connection even on the free plan because of Railgun • Varnish is very popular as well, but complex. ◦ Fastly is a much easier to use hosted Varnish provider
  16. Down the road... • Integrate more dedicated services like Elasticsearch

    or Algolia • Create an off-thread background caching and cache-breaking system ◦ Including stale serving
  17. Launch checklist • Launch checklist with responsible people identified •

    Each item should be assigned to 1 person, not a team • Capture everything: Analytics tags, backups, SSL certificates, domain redirects, debugging turned off, load testing complete, etc...
  18. Load testing • Open Source: we like Siege and Bees

    With Machine Guns • Commercial: we like Load Impact ◦ Can subscribe for just a month ◦ Chrome extension to record typical user paths and all requests
  19. Load testing • Load test before all launches • More

    than just hitting a single URL a few times • Simulate hitting all a page’s assets concurrently • Test from different geo regions • Increase traffic until it “breaks” ◦ Knowing your site’s limit helps guide business decisions ◦ First fix by optimizing low-hanging fruit (performance), then fix by adding hardware (horizontal scalability)
  20. Identifying bottlenecks • Craft debugging toolbar is a big help

    • Slow query logging on your database is important ◦ Tip: use debugging profiler to see template generating a query. Add unique limits to your entries queries (“.entries().limit(23)”) to help identify them in the debugger and DB logs • New Relic is very helpful here • Stackdriver/CloudWatch • Create a Craft plugin as a performance dashboard
  21. Security • Craft has great protections built-in ◦ Twig escaping

    ◦ One-click updates ◦ Proper password hashing ◦ Sane minimum server requirements ◦ DB query parameterization ◦ etc...
  22. • If you can, IP lock the control panel ◦

    Cloudflare calls this “Zone Lockdown” ◦ Can also be done in .htaccess/nginx config, or a plugin • If you can’t IP lock the control panel: ◦ Consider turning ‘preventUserEnumeration’ to true ▪ Possibly more confusing for some users but more secure ◦ Change cpTrigger from “admin”, which is often scanned • Consider tying Craft login to SSO - Google, Okta, etc… ◦ Via plugin, Cloudflare Access, or similar • Weak user passwords are your biggest threat Security
  23. Thank You + Q&A • Contact me any time with

    any questions • [email protected] • @mrw • https://www.VectorMediaGroup.com