Varnish - Making eZ Publish sites fly

eZ DFS - in a cluster set-up, the DFS holds shared file assets, including cache
and images. It can be the bottleneck when supporting heavy traffic.

Rasmussen Reports: Pageview data: 2.6M page views before election day, less on
election day, and very quiet after. This loading, while quite heavy, was
actually very easily supported and the current platform and configuration is
economical and very robust.

Get Varnish from: https://varnish-cache.org/

Varnish is a reverse proxy. Be default it serves whole pages, listening to your webserver on port 88 (for example)
while serving your actual content to the world on port 80. Be default, it handles all the GET requests, and it's
very fast.

Varnish can also do load balancing, although it's also productive to sit directly on a single webserver.

Grace mode (triggered by saint mode) automatically detects that the backend is down; Varnish will continue to work.

A great use case: static html pages, huge traffic spikes.

At Rasmussen: mix of static pages, plus members, personalized pages. Varnish is simple win for the unpersonalized pages.

Versus expanding the hardware:
- can be an issue with autoscaling, with several issues such as testing
- Varnish relieves the bottle neck of the DFS, the network within the platform, or the database

Versus CDN:
- big lag out to the CDN, support is an issue, eg with Akamai
- however it doesn't have the nice proximity effect of a CDN
- thing to do is to use Varnish on the backend because Akami is itself a big load

Optimize everywhere
- browser caching; images, other assets
- minifying, less data to serve

Varnish with ez publish
- have to set up ez publish to inform Varnish that new content is published, or content is deleted, etc

Mugo extension
- https://github.com/mugoweb
- hooks the custom static cache handler, available in 4.6 or via a patch for earlier versions
- this handles all the related changes - because: A single edit may effect a lot of pages!!
- has a regex purge for manual use, available in the admin interface

Varnish runs a ban list; these are pages that are ready to be updated in the cache

Varnish config file
- determine how long to keep pages
- VCL, a very complex interface
- this is a light look at some VCL

Setup tweaks
- Varnish won't cache pages with cookies, which is a prob with < eZ 4.4, can config it to ignore cookies or process cookies specially, GA cookies
- Varnish will respect headers from the backend,
- and will suport edge control headers;
- only want to cache 200 or 400 responses, other stuff goes through to hit the servers
- edge side includes, can include parts of the page different, these can be cached differently, or not even cached at all
- eg, set sidebar ttl to a much smaller ttl

Tools
- Varnishstat, use to tune your cache confit
- Varnishadm, review ban list, review config itself
- curl is great for view headers, and headers become a great way to view the operation

questions and notes:
- memory, use 1 to 16 G; 1 G seems to work pretty well
- how to test Varnish under load; jmeter for recording real sessions, ab, loadstorm (expensive)
hard to test because the network becomes the bottleneck
- root publisher script, from Gaetano, hammers the publish process
- what's better? on its own server? versus other server?
can do either, network bottleneck; failover considerations;
note that multiple instances fo Varnish doubles the cache misses
- check out the "charles" proxy; http://www.charlesproxy.com/ - local desktop proxy to log headers