handling 10k requests per second with symfony and varnish - symfonycon berlin 2016

Handling 10k Requests/second With Symfony and VarnishAlexander Lisachenko

About me:

lisachenkolisachenko

https://twitter.com/lisachenko

https://github.com/lisachenko

‣ Head of Software Architecture at Alpari (RU) Forex Broker

About me:





‣ Have worked with computers since 7 years old

About me:





‣ Have worked with computers since 7 years old

‣ Clean code advocate, guru in enterprise architecture

About me:




Author of the Go! AOP Framework‣ http://go.aopphp.com

http://go.aopphp.com

Agenda

Agenda‣ We review briefly the process of typical

Symfony site growing


Symfony site growing‣ What is Varnish and why it’s so popular


Symfony site growing‣ What is Varnish and why it’s so popular‣ How to prepare your Symfony site for

Varnish?


Symfony site growing‣ What is Varnish and why it’s so popular‣ How to prepare your Symfony site for

Varnish?‣ VCL tricks to easily handle 10K

requests/second with Symfony

Site Growing

First deploy to the production

First deploy to the production

1-30 RPS

First marketing campaign

First marketing campaign

30-50 RPS

Configuring cacheing layer


OpCache


OpCache MemCache

60-250 RPS

Preparing several backends

OpCache MemCache

Preparing several backends

OpCache MemCache

250-1k RPS

Reverse proxy caching

OpCache MemCache

Reverse proxy caching

OpCache MemCache

Varnish

1k-20k RPS

Varnish is an HTTP accelerator designed for content-heavy dynamic web sites as well as heavily consumed APIs.

Websites using Varnish

Source: https://trends.builtwith.com

https://trends.builtwith.com

Simple workflow:

Simple workflow:GET /some-web-page


X-Cache: MISS


X-Cache: MISS

GET /some-web-page


X-Cache: MISS

GET /some-web-page

First request to the page - Time To Load 200ms

Simple workflow:


X-Cache: HIT


X-Cache: HIT

Subsequent request to the page - Time To Load 10ms

Idea: do not ask your backend as much as possible.

How to speed up your site with Varnish?

Read the RFC 7232-7234Your friends:

https://tools.ietf.org/html/rfc7234 - Caching https://tools.ietf.org/html/rfc7232 - Conditional requests

https://tools.ietf.org/html/rfc7234


Read the RFC 7232-7234

‣ Cache-Control

Your friends:





‣ Cache-Control‣ Expires

Your friends:





‣ Cache-Control‣ Expires‣ ETag

Your friends:





‣ Cache-Control‣ Expires‣ ETag‣ Last-Modified

Your friends:




Install Varnish

https://www.varnish-cache.org/releases/index.html - Releases and installation guides

For Debian

For FreeBSD

Also available for Amazon Web Services

https://www.varnish-cache.org/releases/index.html

Configure the backend

Time for experiments!

Test page with 3 widgets, emulating slow query

…our simple slow action implementation

+0.2s +0.5s+1s

Sequential page loads: ~1 second!

+0.2s +0.5s+1s

Slow PHP? Slow Symfony? Slow backend?

Make your responses HTTP Cacheable with Varnish

Looks good…

…until the cache expires

Pros and cons of simple cacheing+ Page can be cached by Varnish, allowing for

faster responses. + Very simple to configure and use.- Delays in the response time after cache expiration. - We can not update information in the blocks

without a full page refresh. - We need to render all 3 blocks at once.

How can we avoid delays on cache expiration?

Make your backend requests asynchronous!

Serving stale content while invalidating

Pros and cons of async cacheing+ Page can be cached by Varnish, allowing for

faster responses. + Very simple to configure and use. + No delays after cache expiration.- We can not update information in the blocks

without full page refresh. - We need to render all 3 blocks at once.

How can we update each widget separately on the page?

Enable Edge-Side Includes (ESI)

Common mistake - missed cache header for an ESI block!

Common mistake - missed cache header for a ESI block!

Page with ESI-blocks

Pros and cons of async ESI cacheing+ Page can be cached by Varnish, allowing for faster

responses. + No delays after cache expiration. + We can update information in the blocks without

full page refresh. + We render and cache each block separately. This

will result in less memory usage and better hit rate.

- Can be dangerous if used without control.

VCL tricks for better performance

Those cookies…

Tips:‣ Always cache top-level GET-responses;

remove any cookies for them.


remove any cookies for them.‣ Only ESI blocks can receive the session

cookie.


remove any cookies for them.‣ Only ESI blocks can receive the session

cookie.‣ Stateless ESI-blocks will not receive any

cookies at all.

Remove all cookies except session one

Restore cookie for ESI requests

Preparing cookies

Cacheing with cookies

What you will receive?

Some live results

There are only two hard things in Computer Science:

cache invalidation and naming things.

-- Phil Karlton

Defining the ACL for Varnish

Preparing friendly headers

Performing PURGE requests

Single page refresh

Use FOSHttpCache

http://foshttpcache.readthedocs.io/en/stable/index.html - FOSHttpCache Documentation https://github.com/FriendsOfSymfony/FOSHttpCache - Source code

http://foshttpcache.readthedocs.io/en/stable/index.html

https://github.com/FriendsOfSymfony/FOSHttpCache

Thank you for your attention!

https://github.com/lisachenko https://twitter.com/lisachenko



handling 10k requests per second with symfony and varnish - symfonycon berlin 2016

Technology