Кэширование Nginx Для Анонимных Пользователей На Примере Drupal

Как известно, Drupal — это пример крайне тяжелой CMS/CMF, и на нем не так-то просто создавать нагруженные сайты.

Поскольку моя компания в своей разработке использует в основном Drupal, нам иногда приходится заниматься оптимизацией производительности, и мне хотелось бы рассказать о том, как мы справляемся с нагрузкой.

В этой статье я рассмотрю один из самых эффективных методов повышения производительности — кэширование контента для анонимных пользователей веб-сервером Nginx. Благодаря этой методике запросы от анонимных пользователей не вызывают бэкенд (неважно какой — apache или fastcgi).

Таким образом, такое кэширование эффективнее любого инструмента CMS.



Постановка задачи

Drupal имеет встроенное кэширование для анонимных пользователей.

Однако он работает крайне неэффективно и имеет тенденцию вызывать больше проблем при большом трафике.

Поэтому разумно применить как минимум 2 меры: 1. Кэшируйте контент для анонимных пользователей с помощью nginx. 2. Храните таблицы кэш_форм и кэш_фильтр в Cacherouter + APC.

Друпал

Чтобы отделить анонимных пользователей от вошедших в систему, мы создадим файл cookie при входе в систему и удалим его при выходе из системы.

Напишем небольшой модуль nginxcache: 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; } }

Очищаем таблицу сессий, кэшируем и включаем модуль.



nginx

Весь конфиг приводить не буду, опишу только то, что актуально для статьи.

В разделе http нам нужно объявить зону:

proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=hrportal:10m inactive=60m;

Для начала вам необходимо позаботиться о создании каталога /var/nginx/cache с необходимыми правами.

Если к данным кэша не осуществляется доступ в течение неактивного времени, они удаляются независимо от их актуальности.

В местоположении нужного виртуального хоста пишем:

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 — директива определяет условия, при которых ответ не будет сохранен в кеше, в нашем случае, если есть логируемый cookie. Если вы забудете об этой директиве, ответы авторизованных пользователей будут записываться в кеш и передаваться анонимным и другим авторизованным пользователям.

proxy_cache_bypass — ответ не будет взят из кеша для пользователей, у которых есть зарегистрированный файл cookie proxy_cache_use_stale — позволяет вернуть устаревший ответ из кеша, если бэкенд недоступен, очень полезно proxy_pass_header — пользователям необходимо получать файлы cookie proxy_ignore_headers — Drupal всегда отправляет эти заголовки, мы вынуждены их игнорировать proxy_cache_valid — устанавливает время кэширования ответа

Результаты

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

Здесь пример сайт, который был качественным с точки зрения PS, но ему не хватало производительности для обработки трафика с PS. Как видно из графика , после установки этого решения трафик стал расти.

Этот сайт использует CMS Drupal и расположен на нашем техническом сайте на VPS. P.S. Этот подход, конечно, применим к любой CMS. УПД.

Я не раз слышал вопрос, а почему бы не повысить.

Ответ довольно сложен.

Я попробую объяснить.

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

1. Фронтенд nginx может располагаться на отдельном от бэкенда сервере - кеш будет располагаться там - и обслуживаться гораздо быстрее 2. nginx в любом случае доставляет статические данные быстрее 3. Друпал может работать на nginx - в этом случае надо перезаписывать буст - нужно ли? 4. В случае с бустом задача кэширования возлагается на бэкенд - это можно сделать прямо на фронтенде Теги: #drupal #highload #Nginx #drupal

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.