Существуют много различных вариантов организации кеширования. Рассмотрим основные. В качестве веб-сервера везде выступает NGINX. В некоторых вариантах это может быть и Apache. Я не останавливаюсь на том, как именно реализовывать тот или иной вариант, эти схемы можно считать небольшой памяткой или шпаргалкой. Важно отметить, что трафик везде от анонимных пользователей.
Все схемы применимы не только к Drupal, но и к другим решениями, например, к Wordpress или к произвольным приложениями PHP.
Вариант «из коробки»
Обычное кеширование Drupal, таблицы с кешем хранятся в SQL базе данных.
Стандартный кеш Друпала
При каждом запросе от пользователя поднимается PHP приложение, в нашем случае Drupal.
Redis или Memcached в качестве кеш-бэкэнда
На сервере стоит Redis или Memchached, стандартный кеш Друпала выносится в одно из этих хранилищ. Модули для интеграции: Memcache Storage или Memcache API and Integration, Redis.
Данные кеша хранятся в памяти. Это быстрее, чем стандартное кеширование в SQL базе. При запросах поднимается Drupal.
NGINX в качестве кеширующего прокси
Назовём связку Drupal + Redis/MC для простоты Application level cache, будем считать, что это кеш на уровне приложения.
Дисковый кеш NGINX и Drupal с вынесенным кешем в память
На входе стоит NGINX, который является веб-сервером и кеширующем прокси-сервером. NGINX кеширует полные страницы, складывает на диск. При запросе пользователя, NGINX отдаёт страницу из своего кеша (если она там есть) без обращения к Друпалу.
Недостатки:
Проблема очистки (инвалидации) кеша в NGINX. Нужен платный Nginx Plus или собственные решения. Возможен вариант с использованием модуля ngx_cache_purge.
NGINX работает напрямую с Redis/Memcachaed
Один из самых привлекательных вариантов — нет лишних звеньев, кеш полностью управляется из Drupal.
NGINX умеет читать данные из кеша PHP-приложения
NGINX настраивается таким образом, что умеет читать данные напрямую из кеша Redis/MC, которым управляет Drupal. Подробнее об этом этом варианте для Drupal 7 можно почитать здесь.
Varnish
Стандартная схема. Varnish клёвый и быстрый.
Схема организации кеша с помощью NGINX и Varnish
К неприятным моментам можно отнести, что теперь у нас ещё одно звено в виде Varnish со своими не самыми простыми конфигами. Но основной минус схемы — Varnish не поддерживает SSL, https работать не будет на этой схеме.
Varnish + Hitch (или NGINX) для SSL
Для поддержки SSL можно поставить Hitch, это разработка Varnish Software, обрабатывает TLS/SSL, и передаёт трафик на бекэнд. Или, можно использовать NGINX перед Varnish в качестве обработчика трафика HTTPS.
Varnish c поддержкой трафика HTTPS
Для простых проектов не хочется иметь много звеньев, да и для сложных тоже. Рассмотрим вариант один NGINX + Varnish с поддержкой трафика HTTPS.
Varnish + один NGINX и поддержка SSL
Общая схема:
Более подробная:
NGINX обрабатывает несколько портов. На 80 порту висит редирект на HTTPS. Запросы к 443 порту расшифровываются и отправляются на Varnish, который должен быть настроен на порт XX (выбранный вами порт). Varnish смотрит — есть ли кеш для данного запроса и, либо отдаёт, либо проксирует обратно на NGINX на 8080 порт, на котором у NGINX должно быть настроено PHP приложение.
