Как известно, 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
-
Хидео Кодзима: 70% Фильма
19 Oct, 24 -
Ябб — Форум Из 20 Века
19 Oct, 24 -
Ima Group Потеряла Исходный Код?
19 Oct, 24