EXT: MOC Varnish¶

ESI¶

Or Edge-side includes is a very cool feature of Varnish (and other web accelerators). It basically allows the webserver to tell varnish that the page is built out of several building blocks and have different cache definitions for each of them. An example could be a newspage with a “Latest news” function on all views f articles. The news article itself really does not change very often, and could possible be cached for months (if not forever, when TYPO3 clears its cache, varnish cache for that page is also cleared). But the “latest news” can not be cached for months since new article hopefully is added much more frequently. ESI allow the CMS to tell Varnish that the page in general can be cached for one month, but the specific block should not be cached, or possibly cached for only 1 minute, this allowing varnish to handle extreme high loads, but still allow the website to have dynamic content.

The Edge-side include should really be thought of as old-fashioned server-side-includes, but with full cache management.

For TYPO3 this model is very much in line with TYPO3s own caching scheme. In TYPO3 the concept of USER_INT typoscript objects allow the TYPO3 cache to have elements that are not cached, although the major part of the page is actually cached. This extension provides examples of how to set up Varnish with ESI, so all USER_INT are actually handled by Varnish as ESI. The performance boost are tremendous, but there is some minor catches, like not being able to add dynamic headerdata etc. handling default timeout and users logged into you website.

Varnish and FE users¶

The whole concept of having a cache, is that content should be cached. But when users are logged in, we do not wish to cache content for different user, we might accidentally cache one persons address details and display them to another person.

There are several ways to handle this challenge, and all of them require Varnish to know when a user (and possibly who) is logged in to TYPO3. This extensions hooks into the loginprocedure and adds a cookie to the user that Varnish can use to handle the challenge. Varnish might handle this differently. One approach is to simply disable caching when logged in (except for images, movies, css and possibly JS). This is the most simple and easy to configure way to handle it. We prove VCL for this approach in the CVL Examples folder.Another approach could be tell varnish to include the user uid in the cache hash generation. This way the same page would be cached differently for different users. This approach is quite nice as it allows to cache content for each individual user, and the user will benefit from a faster website. However the cache might fill up fast if many users log in.

In version 1.0, this is actually not included, as it requires a little work to make it stable.

Cache clearing¶

Since cache is already built into TYPO3, but content is now also cached in Varnish, this extension provides TYPO3 with a way to clear the varnish cache for a page when the cache for that page is cleared. This way we can cache content longer in Varnish, as we know the cache is purged when the content is altered. There are a lot of caveats for this, specifically since many sites use RealURL, and there might be many URL's that a specific page can be reached on. Multiple domains, old not-yet-expired URLS etc. We need to clear the cache for all of them, when content is changed.

This extension tries to handle this automatic clearing of Varnish cache when TYPO3 cache is cleared.

Developing extensions for high-performance websites¶

This is a topic that has enough information for a (large) blog-post, but here are the key points, when developing extensions for high- perfomance websites using Varnish.

max_age¶

no_esi¶

[tsref:(cObject).USER_INT]

((generated))¶

Plugin.tx_mocvarnishtest_pi1.max_age=10

plugin.tx_myext_pi1.max_age.field = tx_myext_maxage

Simple test¶

In you vcl_fetch function, add something like this to the top of the function

#Respect force-reload, and clear cache accordingly. This means that a ctrl-reload will acutally purge
# the cache for this URL.
if (req.http.Cache-Control ~ "no-cache") {
  set obj.ttl = 0s;
  #Make sure ESI includes are processed!
  esi;
  return (deliver);
}

if (req.url ~ "\.(png|gif|jpg|swf)$") {
  unset obj.http.set-cookie;
  set obj.http.X-Cacheable = "YES:jpg,gif,jpg ans swf are always cached";
  return (deliver);
}


#Allow 24 hour stale content, before an error 500/404 is thrown.
# When a backend server is not responding
# allow varnish to server stale content for 24 hours afters its expirery.
set obj.grace = 24h;

#Allow edgeside includes
esi;
if (req.url == "/date.php") {
  set obj.ttl = 0s;
} else  {
  set obj.ttl = 24s;
}
return (deliver);

The last 6 lines will tell varnish to process esi tags, and will not cache that. All other content is cached for 24 hours. An example of a vcl for this is given in vcl-exampeles/esi-test.vcl in the extension root.

Just to test that it works, add two files to you website. Test.php and date.php

<html>
  <body>
  The cached time is <?php echo date("d/m-Y H:i:s")?><br />
  The real time is: <esi:include src="date.php"/>
  </body>
</html>

<?php
echo date("d/m-Y H:i:s");
?>

TYPO3 Test¶

Now for the much more fun part. The same example but with TYPO3!

Take the above VCL as a base, alter the vcl_fetch_method to something like this

#Respect force-reload, and clear cache accordingly. This means that a ctrl-reload will actually purge
# the cache for this URL.
if (req.http.Cache-Control ~ "no-cache") {
  set obj.ttl = 0s;
  #Make sure ESI includes are processed!
  esi;
  return (deliver);
}

if (req.url ~ "\.(png|gif|jpg|swf)$") {
  unset obj.http.set-cookie;
  set obj.http.X-Cacheable = "YES:jpg,gif,jpg ans swf are always cached";
  return (deliver);
}


#Allow 24 hour stale content, before an error 500/404 is thrown.
# When a backend server is not responding
# allow varnish to server stale content for 24 hours afters its expirery.
set obj.grace = 24h;

#Allow edgeside includes
esi;
if (obj.http.X-ESI-RESPONSE) {
  set obj.ttl = 0s;
  return (pass);
} else  {
  set obj.ttl = 24h;
}

return (deliver);

The only change compared to the first configuration is that we now test for the HTTP Header X-ESI-REPOSNSE instead of testing for date.php specifically. This way, when we render the ESI include we can simple add a header X-ESI-RESPONSE, and this little piece will be fethed each time. MOC Varnish makes sure that this header is set.

There is a esi-test.vcl file in vcl-examples that can be used for this part of the tutorial.

Notice that we only have ESI processing if content is not png, gif, jpg swf etc. This could also be expanded to css and js files, but for now only media files are not processed for esi tags.

Now install the moc_varnish extension and clear cache. Make sure the “Convert USER_INT to ESI for Varnish” is enabled in the Extension manager. Also make sure that you have the Static TypoScript configuration for MOC Varnish loaded.

Install the moc_varnish_test extension which provides a simple plugin that show the current time on the server (for testing).

On a page of you own choice, insert the plugin “Varnish test” which is found in the moc_varnish_test extension.

Make sure that you do not have the config.xhtml_clening set, this will not work with Varnish (at least not in version 2.1).

Now view the page you inserted the plugin on. Refresh the page a couple of times (wait at least a second), you should see the timer show the correct time. If the timer is stuck, and does not change when you upate, somehting is wrong with your caching-setup.

While refreshing you site, take a look at your apache logfiles, and you will see that only a page with typeNum=978 is called instead of the whole page. This is because Varnish caches the whole page for 24h, but the USER_INT is fetched once for each request.

To test this more thoroughly, we use the shell command seige. Siege is used to stress test servers, and is basically the same as Apache benchmark (ab) but just a little better (however ab will do fine for the tests below). We run it in benchmark mode, so siege will try to make as many requests as possible to the server. That allows us to benchmark different configuration.

The command we use is

siege -b -c 10 -t10s  "http://edntest.local/test-10/"

Adjust the URL to your server configuration. The command will make 10 simultaneous connections for 10 seconds, and try to make as many requests as possible. First we run it without caching anything in varnish, and without the moc_vanish extension installed.

On my labtop, this gives 315hits in ten seconds.

Now we enable Varnish with the above configuration, and watch the apache log while we benchmark the site.

What we should see in the log files is something like this:

127.0.0.1 - - [17/Oct/2010:13:49:56 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.a1c1197e2fea1585dcef88c2f1365ecc&from_varnish=1 HTTP/1.1" 200 604 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"

Mainly request for type=978&key=INT_SC... but no requests for the test-10 file alone. This indidcates that varnish cached the main file, but is now requesting the content of the USER_INT from TYPO3 for each user. Now lets see what this did to performance. We run siege command again, and find that we are now able to make only 284hits in ten seconds.This is actually worse than without varnish! But thinking about, it makes sense. For each user, varnish will have to request the content of the user_int script from the TYPO3 server. The TYPO3 server will have to initialize the whole front-end rendering in order to just render this single USER_INT object. Even worse, if there are more than one USER_INT on a page, varnish will contact TYPO3 once for each USER_INT, thus making the result even worse!

Not impressed? Hold on, it gets better.

#Allow edgeside includes
esi;
if (obj.http.X-ESI-RESPONSE) {
  set obj.ttl = 5s;
} else  {
  set obj.ttl = 24h;
}

return (deliver);

127.0.0.1 - - [17/Oct/2010:13:59:36 +0200] "GET /test-10/ HTTP/1.1" 200 3306 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"
127.0.0.1 - - [17/Oct/2010:13:59:36 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.a1c1197e2fea1585dcef88c2f1365ecc&from_varnish=1 HTTP/1.1" 200 604 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"
127.0.0.1 - - [17/Oct/2010:13:59:41 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.a1c1197e2fea1585dcef88c2f1365ecc&from_varnish=1 HTTP/1.1" 200 604 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"

config.sendCacheHeaders = 1

plugin.tx_mocvarnshtest_pi1.max_age = 2

sub vcl_fetch {

  #Respect force-reload, and clear cache accordingly. This means that a ctrl-reload will actually purge
  # the cache for this URL.
  if (req.http.Cache-Control ~ "no-cache") {
    set obj.ttl = 0s;
    #Make sure ESI includes are processed!
    esi;
    return (deliver);
  }

  if (req.url ~ "\.(png|gif|jpg|swf)$") {
    unset obj.http.set-cookie;
    set obj.http.X-Cacheable = "YES:jpg,gif,jpg ans swf are always cached";
    return (deliver);
  }

  #Allow 24 hour stale content, before an error 500/404 is thrown. When a backend server is not responding
  # allow varnish to server stale content for 24 hours afters its expirery.
  set obj.grace = 24h;

  #Allow edgeside includes
  esi;

  #Make sure that We remove all cache headers, so the Browser does not cache it for us!
  remove obj.http.Cache-Control;
  remove obj.http.Expires;
  remove obj.http.Last-Modified;
  remove obj.http.ETag;
  remove obj.http.Pragma;

  #We rely on the Cache-control: max-age header to set ttl in cache. Typo3 sends these headers.
  return (deliver);
}

127.0.0.1 - - [17/Oct/2010:21:55:50 +0200] "GET /test-10/ HTTP/1.1" 200 3306 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"
127.0.0.1 - - [17/Oct/2010:21:55:50 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.13e8f885e27c06a6ff9ba2c2eaebe432&from_varnish=1 HTTP/1.1" 200 776 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"
127.0.0.1 - - [17/Oct/2010:21:55:52 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.13e8f885e27c06a6ff9ba2c2eaebe432&from_varnish=1 HTTP/1.1" 200 776 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"
127.0.0.1 - - [17/Oct/2010:21:55:55 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.13e8f885e27c06a6ff9ba2c2eaebe432&from_varnish=1 HTTP/1.1" 200 776 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"
127.0.0.1 - - [17/Oct/2010:21:55:57 +0200] "GET /test-10/?id=10&type=978&key=INT_SCRIPT.13e8f885e27c06a6ff9ba2c2eaebe432&from_varnish=1 HTTP/1.1" 200 776 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.67)"

#Make sure that We remove all cache headers, so the Browser does not cache it for us!
remove obj.http.Cache-Control;
remove obj.http.Expires;
remove obj.http.Last-Modified;
remove obj.http.ETag;
remove obj.http.Pragma;