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

SymfonyWorld 2021 Summer Edition: Feedback on o...

SymfonyWorld 2021 Summer Edition: Feedback on our use of Varnish

On a large French e-commerce site, we use Varnish as HTTP cache.

We use it for the API as well as for the HTML front ends.

We use ESI, with user-context-hashes allowing us to do
authenticated caching. We mix invalidation by tags but also by ttl.

This is a feedback to explain the choices we had to make, how we use it, what it brings us.

We'll also answer a lot of questions that people have about HTTP caching in practice.

Bastien Jaillot

June 17, 2021
Tweet

More Decks by Bastien Jaillot

Other Decks in Programming

Transcript

  1. Feedback on our use of Varnish SymfonyWorld Online 2021 –

    Bastien Jaillot – @bastnic Architect @JoliCode
  2. Monitore All. The. Thing - never have to guess: test

    and monitor - graphs - logs - business metrics - load benchmark - profiling
  3. 01. Typical Web architecture - same request : same impact

    on infrastructure - to scale, increase everything (Web server, php-fpm, db) - at the end it will be resources like database which will be the bottleneck
  4. 01. Typical Web architecture Concurrency rq/s 90% ms Load webserver

    1 40 25ms 20% (1) 10 150 90ms 95% (2) 100 135 850ms 100% (12) 300 100 3s 100% (20) already dead
  5. 02. Add some servers # servers Concurrency rq/s 90% ms

    Load webserver 1 10 150 90ms 95% (2) 4 10 372 30ms 50% (1) 1 100 135 850ms 100% (12) 4 100 550 440ms 100% (12) 1 300 100 3s 100% (20) 4 300 550 910ms 100% (20) Way better still dead
  6. 03. With app cache - use redis or memcached -

    compute less - reduce pressure
  7. Paginator is not serializable with an iterator and closures. Not

    a good candidate for caching. (no thanks to the silent fail)
  8. Next attempt, cache the response. Performance is now better. But

    do you see the new issue? Same cache whether we have a tag or not.
  9. 03. With app cache Concurrency rq/s 90% ms Load webserver

    1 130 7ms 15% (0.1) 10 500 34ms 40% (3) 100 500 254ms 100% (12) 300 350 1,5s 100% (25) 100 (4 servers) 1700 85 ms 31% (2) 300 (4 servers) 1900 309ms 35% (2) still dead, but nicer nice, but not fast enough
  10. 04. HTTP cache with Symfony built-in reverse proxy Concurrency rq/s

    90% ms Load webserver 1 300 3ms 15% (0.4) 10 1350 11ms 40% (2) 100 1400 80ms 100% (12) 300 1100 150ms 100% (25) dead Nice!
  11. 05. HTTP cache with a dedicated reverse proxy: Varnish Concurrency

    rq/s 90% ms Load webserver Load varnish 1 2550 1ms 0 (0) 0 10 6700 3ms 0 (0) 0 100 6800 30ms 0 (0) 0 300 6900 64ms 0 (0) 0 1000 6900 154ms 0 (0) 0,15 Woooooooooooottt! (not dead / very much alive and bored)
  12. Varnish is very very very fast … but it’s as

    tricky as it’s powerful… (have you met VCL?)
  13. 05. HTTP cache with a dedicated reverse proxy: Varnish -

    Varnish = memory, volatile - Programmable via VCL (not nice) - Grace mode 💚 - ESI = separate request to backend
  14. User context hash User Session id rôle user context hash

    Alice anonymous 1 Bob authenticated 1 Bastien a paid subscriber 2 Xavier b paid subscriber 2 Nicolas c moderator 3 Fabien d the boss 3
  15. 08. Complicate everything: api first - api first - own

    varnish layer - complex cascade of sync and async invalidation
  16. 09. Varnish multi zone - no way to communicate with

    all varnish in sync mode - the api stays in one zone - let the ttl do its stuff - invalidate via an async message that notifies all stacks to ban everything
  17. Crash redis - redis is very robust, but can still

    crash - key always appending, size increase non stop - monitor! BEFORE AFTER
  18. Ban tags with regex rq/s * ban/s * size of

    the cache tags header * complexity of the regexp not much I can do, all real load, let’s check the regexp
  19. Cookies sent to API, preventing cache - cookies on .symfony.com

    - api.symfony.com called from a backoffice - no http cache (no user context hash on our api) - strip all cookies
  20. Varnish Cache Plus - by the maintainers of Varnish -

    share cache between varnish - better cookies management - better invalidation across cluster - VCL review by experts - … - and a lot more
  21. Fastly >_Fastly's cache servers run an evolution of Varnish which

    diverged from the community project at version 2.1. Varnish Configuration Language (VCL) remains the primary way to configure our cache behaviors, and our VCL syntax derives from Varnish 2.1.5, but has been significantly upgraded and extended for Fastly-specific features. > While it's possible that VCL written for the open source Varnish will work on Fastly, our VCL variant should be seen as a separate language. See using VCL for detailed information about the architecture of VCL configurations.
  22. Funny story: Symfony 5.2 vs 5.3 - bug on translations

    - json parsed at each requests - slows everything down
  23. Typical Web architecture… on 5.3 Concurrency rq/s 90% ms Load

    webserver 1 40 60 25ms 17ms 20% (1) 10 150 165 90ms 75ms 95% (2) 100 135 158 850ms 600ms 100% (6) 300 100 172 3s 1.5s 100% (12) dying
  24. Performance is addictive • monitore! • Varnish protect you and

    can hide a lot of issues • once you are in <80ms, you want to stay there