Nginx caching for anonymous users on the example of Drupal

As you know, Drupal is an example of an extremely heavy CMS / CMF, and it is not so easy to build loaded sites on it. Since my company mainly uses Drupal in its development, we sometimes have to deal with performance optimization, and I would like to talk about how we cope with the load.

In this article, I will look at one of the most effective methods to improve performance — web caching of nginx content for anonymous users. Thanks to this technique, requests from anonymous users do not call backend (no matter which one - apache or fastcgi). Thus, such caching is more effective than any means of CMS.

Formulation of the problem

Drupal has built-in caching for anonymous users. However, it works extremely inefficient and brings rather more problems with high attendance. Therefore, it is reasonable to apply at least 2 measures:
1. Cache content for anonymous users using nginx
2. Store the cache_form and cache_filter tables in Cacherouter + APC
')

Drupal

In order to separate anonymous users from logged in users, we will issue a cookie when logging in, and during logout - select it. Let's write a small nginxcache module:

nginxcache.info
name = Nginx cache
description = Nginx cache for anonymous users
package = ISFB
version = VERSION
core = 6.x

nginxcache.module
<?php
function nginxcache_user($type, &$edit, &$user) {
switch($type){
case 'login' :
setcookie('logged', TRUE, time()+60*60*24*30, "/");
break;
case 'logout':
setcookie('logged', FALSE);
break;
}
}

We clear the sessions table, the cache and turn on the module.

nginx

I will not give the whole config, I will describe only what is relevant to the article.

In the http section, we need to declare the zone:
proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=hrportal:10m inactive=60m;

You must first take care of creating the / var / nginx / cache directory with the necessary permissions. If the cache data is not accessed for inactive time, it is deleted regardless of freshness.

In the location of the desired virtual host, we write:
proxy_cache hrportal;
proxy_cache_key $host$uri?$args;
proxy_no_cache $cookie_logged;
proxy_cache_bypass $cookie_logged;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_pass_header Set-Cookie;
proxy_ignore_headers "Expires" "Cache-Control";
proxy_cache_valid 200 301 302 304 1h;

proxy_no_cache - the directive sets the conditions under which the response will not be stored in the cache, in our case, if the cookie is logged. If you forget about this directive - the cache will record the answers of authorized users, who will give anonymous and other authorized users.
proxy_cache_bypass - the answer will not be taken from the cache for users who have a logged cookie
proxy_cache_use_stale - allows you to give an outdated cache response, if the backend is not available, it is very useful
proxy_pass_header - users need to receive cookies
proxy_ignore_headers - Drupal always sends these headers, we have to ignore them
proxy_cache_valid - sets the caching time for responses

results

As you know, search engines analyze the performance of the site and do not send more users to it, which it can process. Here is an example of a quality site from the point of view of the PS, which lacked performance to handle traffic from the PS As you can see from the graph , after the installation of this solution, the traffic began to grow.
This site uses CMS Drupal and is located on our technical site on VPS.

PS This approach is naturally applicable to any CMS.

UPD. Already not once heard the question, why not boost.
The answer is quite complicated. I will try to explain.
To begin with, as you rightly noted, my decision is not boxed, and it should be applied when attendance is really high - and any ways to increase productivity are important.

1. nginx-frontend can be located on a separate server from the backend - the cache will be in the same place - and be delivered much faster
2. nginx in any case gives statics faster
3. Drupal can stand on nginx - in this case it is necessary to redo the rewright boost - is it necessary?
4. In the case of boost, the caching task is given to the backend - this can be done right on the front end.