Размышления о кластеризации: Часть 3 - Varnish кэш

Собрался в конце концов с мыслями для того что бы продолжить демагогию о том, как же еще усложнить себе жизнь и уменьшить нагрузку на сервер.

Предыдущие статьи:
Размышления о кластеризации: Часть 1
Размышления о кластеризации: Часть 2

В этой статье я хочу поговорить про кэш. Varnish - замечательный инструмент для кэширования Вашего сайта. Естественно при правильном подходе. Многие наивно полагают, что нужно кешировать все, что только можно. Они очень сильно ошибаются. Как правило Varnish хранит кэш в огроменном файле на диске, либо в оперативной памяти. Оперативная память - ресурс ограниченный, поэтому довольно глупо в нем хранить статический данные. Ну а на поиск хэша объекта в огромном файле уйдет времени больше, чем на то что бы выдать его с app/web сервера. Именно поэтому очень часто я вижу криво настроенные Varnishы, которые только создают дополнительную нагрузку на сервера, без ризонного прироста производительности.

К чему я эту демагогию развел? Потому что дальше речь пойдет о добавлении в уже существующий кластер еще одного сервера, который будет не только рулить трафик, но и кэшировать динамический контент.

Общая идея такая:
Varnish вертится на отдельном сервере. IP адресом этого сервера резолвится доменное имя сайта. Если страница найдена в кэше - она выдается посетителю, если не найдена - отправляется запрос на web сервер, с дальнейшим созданием кешированой версии страницы. Статический контент отдается с app сервера.

Схема (№1) кластера выглядит следующим образом:

Можно рассматривать и вот такую (схема №2):

Отдельный сервер для Varnish нужен поскольку кэш предлагается хранить в оперативной памяти. Это ускорит скорость ответа в 5-10 раз, что не может не сказаться положительно на общем SEO рейтинге Вашего web-ресурса. Поскольку я рассматриваю гипотетическую ситуацию, когда web сервер перестал выдерживать наплыв посетителей, то не имеет смысла обратно нагружать этот же web сервер еще и Varnish’ом.

Как правило нету смысла нагружать Varnish сервер еще и обработкой трафика для app сервера, все же статический контент имеет на много большие объемы и соответственно требует больше процессорного времени. Поэтому первую схему стоит рассматривать только если у Вас по каким-то причинам не работает трюк с Rewrite, который я описывал в предыдущей части

Для того, что бы настроить Varnish можно воспользоваться соответствующей статьей.

В принципе статью с обзором конфигурации Varnish можно использовать как опорную и ее будет достаточно для корректной работы. Рекомендую провести анализ страниц вашего сайта и определиться какие из них все же стоит исключить из кеширования, а для каких установить меньшее время хранения кэша.

Если у Вас блог, который обновляется раз в день, то можно не заморачиваться. Время хранения кэша определяется директивой beresp.ttl в vcl_fetch. В статье для примера он приведен со значением 86400 секунд = 24 часа. Теоретически кэш будет очищен перед тем, как Вы опубликуете новые материалы.

Если же некоторые страницы Вашего ресурса обновляются в произвольный момент времени несколько раз в день, тогда есть смысл исключить их из кеширования с помощью следующей конструкции в vcl_recv:

if (req.url == "^/(uri_1|uri_3|uri_3)") {
        return (pass);
    }

Также рекомендую создать страницу, которая позволит Вам очищать кэш Varnish. Можно воспользоваться соответствующей заметкой

Эту страницу нужно разместить на web сервере, отключить для нее кеширование, а в acl purge добавить ip адрес с которым Varnish видит web сервер.

Взяв эту статью за основу можно изменить код Вашего сайта и добавить в него вызов очистки кєша Varnish при добавлении, скажем, комментария к статье. Имеется ввиду удаление из кэша объекта статьи, к которой был добавлен комментарий.

До сих пор я не добавил web серверов в кластер. В следующих статьях речь пойдет о них.