Настройка кэширования статики с помощью nginx в Debian. Настройка сжатия и кэширования на хостинге с Nginx и Apache Кэширование http заголовков на сервере nginx

HTTP заголовок Expires наряду с несколькими другими заголовками, такими как Cache-Control позволяет управлять кэшем, тем самым сообщая, как долго запрашиваемый контент будет актуален. После того как «время жизни» истекает, кэш перестает быть актуальным, и возникает необходимость запрашивать исходный ресурс, чтобы узнать были ли изменения в контенте. Заголовок Expires является стандартным заголовком, регламентированным в протоколе HTTP, и поддерживается практически любым кэшом. Что касается заголовка Cache-Control, то он был введен в HTTP/1.1 , позволив тем самым предоставить возможность веб-мастерам осуществлять больший контроль над контентом, а так же решить ограничения связанные с Expires. Чтобы использовать Cache-control эффективно, рекомендуется указывать время, по истечении которого кэш перестает быть актуальным.

В данном посту мы рассмотрим примеры настройки параметра expires в Nginx. Для начала попробуем в настройках выставить максимальный возможный срок хранения кэша.
Ставим кэш на максимальный срок

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires max; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires 7d; } ... }

Таким образом, браузер после первого запроса файлов будет запрашивать их повторно лишь через 7 дней. Всё это время они будут находиться в кэше браузера пользователя. Есть возможность так же отсчитывать время жизни кэша от момента последнего изменения файла.
Ставим кэш от момента последнего изменения файла

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires modified 3d; } ... }

Используя такой метод, в результате мы получаем время кэша, которое будет зависеть от времени последней модификации файла. С момента последней модификации, браузер будет запрашивать файл через 3 дня. Для некоторых задач такой способ кэширования может оказаться более удобным.
Можно так же отключить кэширование файлов браузером, для этого выставляем значение параметра в off.
Отключаем кэширование файлов в браузере

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires off; } ... }

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

Кеширование (caching) — это технология или процесс создания копии данных на быстродоступных носителях информации (кеш, cash). Проще говоря и применяя к реалиям сайтостроения, это может быть создание статической html-копии страницы или её части, которая генерируется с помощью PHP-скриптов (или иных других, как-то Perl, ASP.net), смотря на каком языке написан CMS сайта) и сохраняется на диске, в оперативной памяти или даже частично в браузере (рассмотрим подробнее ниже). Когда произойдёт запрос страницы от клиента (браузера), вместо того, чтобы заново собирать её скриптами, браузер получит её готовую копию, что намного экономнее по затратам ресурсов хостинга, и быстрее, так как передать готовую страницу занимает меньше времени (порой значительно меньше), чем её создание заново.

Зачем использовать кеширование на сайте

Для снижения нагрузки на хостинг
Для быстрой отдачи содержимого сайта браузеру

Оба аргумента, думаю, в комментариях не нуждаются.

Недостатки и отрицательный эффект от кеширования сайта

Как ни странно, у кеширования сайта есть и свои минусы. В первую очередь это касается сайтов, содержание которых динамично изменяется при взаимодействии с ним. Зачастую, это сайты, которые выдают содержимое или его часть с помощью AJAX. В общем-то, кеширование AJAX тоже возможно и даже нужно, но это тема для отдельного разговора и не касается традиционно используемых технологий, о которых пойдёт речь далее.
Также, проблемы могут возникнуть у зарегистрированных пользователей, для которых постоянный кеш может стать проблемой при взаимодействии с элементами сайта. Тут, как правило, кеш отключается, либо используется объектное кеширование отдельных элементов сайта: виджетов, меню и тому подобных.

Как настроить кеширование у себя на сайте

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

Кеширование на стороне сервера

Кеширование с помощью NGINX

Кеширование с помощью htaccess (Apache)

Если у вас есть доступ только к.htaccess , и рабочий сервер только Apache, то вы можете использовать такие приёмы, как сжатие gzip и выставление заголовков Expires , чтобы использовать браузерный кеш.

Включаем сжатие gzip для соответствующих MIME-типов файлов

AddOutputFilterByType DEFLATE text/plain text/html AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript AddOutputFilterByType DEFLATE text/xml application/xml application/xhtml+xml application/rss+xml AddOutputFilterByType DEFLATE application/json AddOutputFilterByType DEFLATE application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon

Включаем заголовки Expires для статичных файлов сроком на 1 год (365 дней)

ExpiresActive on ExpiresDefault "access plus 365 days"

Кеширование с помощью Memcached

Кеширование с помощью акселератора php

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

Windows Cache Extension for PHP
XCache
Zend OPcache

В PHP версии 5.5 и выше уже встроен акселератор Zend OPcache , поэтому чтобы включить акселератор, вам достаточно просто обновить версию PHP

Кеширование на стороне сайта

Как правило, тут подразумевается возможность CMS сайта создавать статические html-копии страниц. Такой возможностью обладают большинство популярных движков и фреймворков. Лично я работал со Smarty, WordPress, поэтому могу заверить, что они отлично справляются со своей работой. В оригинальном WordPress из коробки нет кеширующих возможностей, которые необходимы любому малость нагруженному проекту, зато есть множество популярных плагинов для кеширования:

, который как раз и занимается генерацией статических страниц сайта;
Hyper Cache, который по сути работает так же, как и предыдущий плагин;
DB Cache. Суть работы — кеширование запросов к базе данных. Тоже очень полезная функция. Можно использовать в связке с двумя предыдущими плагинами;
W3 Total Cache. Оставил его на десерт, это мой любимый плагин в WordPress. С ним сайт преображается, превращаясь из неповоротливого автобуса в гоночный болид. Его огромным преимуществом является огромный набор возможностей, как то несколько вариантов кеширования (статика, акселераторы, Memcached, запросы к базе данных, объектное и страничное кеширование), конкатенация и минификация кода (объединение и сжатие файлов CSS, Javascript, сжатие HTML за счёт удаления пробелов), использование CDN и многое другое.

Что тут скажешь — используйте правильные CMS, и качественное кеширование будет доступно практически из коробки.

Кеширование на стороне браузера (клиента), заголовки кеширования

Кеширование в браузере возможно потому, что любой уважающий себя браузер это позволяет и поощряет. Возможно это благодаря HTTP заголовкам , которые сервер отдаёт клиенту, а именно:

Expires;
Cache-Control: max-age;
Last-Modified;
ETag.

Благодаря им пользователи, которые неоднократно заходят на сайт, тратят крайне мало времени на загрузку страниц. Заголовки кеширования должны применяться ко всем кешируемым статическим ресурсам: файлы шаблона, картинок, файлы javascript и css, если есть, PDF, аудио и видео, и так далее.
Рекомендуется выставлять заголовки так, чтобы статика хранилась не менее недели и не более года, лучше всего год.

Expires

Заголовок Expires отвечает за то, как долго кеш является актуальным, и браузер может использовать кешированные ресурсы, не запрашивая у сервера их новую версию. Является сильным и крайне желательным к использованию, так как действует в обязательном порядке. В заголовке рекомендуется указывать срок от недели до года. Больше года лучше не указывать, это является нарушением правил RFC.

Например, чтобы настроить Expires в NGINX для всех статических файлов на год (365 дней), в конфигурационном файле NGINX должен присутствовать код
Location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { expires 365d; }

Cache-Control: max-age;

Cache-Control: max-age отвечает за то же самое.
Более предпочтительно использование Expires, нежели Cache-Control ввиду большей распространённости. Однако, если Expires и Cache-Control будут присутствовать в заголовках одновременно, то приоритет будет отдан Cache-Control.

В NGINX Cache-Control включается так же, как и Expires , директивой expires: 365d;

Last-Modified и ETag

Эти заголовки работают по принципу цифровых отпечатков. Это означает, что для каждого адреса URL в кеше будет устанавливаться свой уникальный id. Last-Modified создаёт его на основе даты последнего изменения. Заголовок ETag использует любой уникальный идентификатор ресурса (чаще всего это версия файла или хеш контента). Last-Modified – «слабый» заголовок, так как браузер применяет эвристические алгоритмы, чтобы определить, запрашивать ли элемент из кеша.

В NGINX для статичных файлов ETag и Last-Modified включены по умолчанию. Для динамических страниц их либо лучше не указывать, либо это должен делать скрипт, генерирующий страницу, либо, что лучше всего, использовать правильно настроенный кеш, тогда NGINX сам позаботится о заголовках. Например, для WordPress, вы можете воспользоваться .

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

Одновременное использование Expires и Cache-Control: max-age избыточно, так же, как избыточно одновременное использование Last-Modified и ETag. Используйте в связке Expires + ETag либо Expires + Last-Modified.

Включить GZIP сжатие для статичных файлов

Конечно, сжатие GZIP не относится к кешированию как таковому напрямую, однако, весьма экономит трафик и увеличивает скорость загрузки страниц.
Как включить GZIP для статики в server { .... gzip on; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; } Как включить GZIP для статики в Чтобы включить сжатие gzip в.htaccess, нужно в начало файла вставить следующий код: AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript

На не слишком загруженных сайтах благодаря браузерному кэшированию и предварительному сжатию данных можно и вовсе обойтись без плагинов кэширования. Однако в этом посте даны директивы, которые актуальны только для хостинга, на котором работает HTTP-сервер Apache. Некоторые хостеры ради экономии серверных ресурсов отключают Apache или вовсе не устанавливают его, предпочитая настраивать только менее прожорливый веб-сервер Nginx. Давайте посмотрим, как можно настроить предварительное сжатие и браузерное кэширование, если на вашем хостинге работает только Nginx.

1. Предварительное сжатие
Перед тем, как отдать содержимое страниц в браузер посетителя, можно его сжать. Сжатие уменьшает размер передаваемых файлов (иногда в несколько раз), что приводит к увеличению скорости загрузки страниц и уменьшению исходящего трафика. Сжимать нужно только файлы, содержащие текстовую часть - текст, HTML, PHP, JS, XML, и прочие подобные. Текст хорошо сжимается даже при низком уровне компрессии, объем передаваемых фалов уменьшается на 50-80%. Конечно, файлы небольшие, всего десятки килобайт, но если учесть, что таких фалов тысячи, и загружаются они тысячами посетителей каждый день, то, как говорят, с миру по нитке - нищему на воротник, экономия получается существенная.

1-1. Предварительное сжатие / Apache
Для тех, у кого установлен Apache, нужно узнать у хостера, какие специальные модули, реализующие его, установлены - mod_pagespeed или mod_deflate? Обычно в Apache 2x устанавливают mod_deflate. Есть еще mod_gzip, но его устанавливали в предыдущих версиях, так что его встретить маловероятно.

Если установлен модуль mod_pagespeed, то в файл.htaccess, находящийся в корне вашего сайта, нужно вставить:

ModPagespeed on
# using commands,filters etc

Если установлен модуль mod_deflate, то то в файл.htaccess, находящийся в корне вашего сайта, нужно вставить:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript

В данном случае сжатию подвергаются все текстовые файлы - txt, html, xml, xhtml, css, js.

Или в httpd.conf находящийся в /usr/local/ets/Apache22/:

AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/css

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0 no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

После чего обязательно нужно перезапустить апач

/usr/local/etc/rc.d/apache22 restart

1-2. Предварительное сжатие / Nginx
Если хостинг работает под управлением Nginx, то директивы будут выглядеть иначе. В файл.htaccess, находящийся в корне вашего сайта, нужно вставить:

server {
gzip on;
gzip_types text/html text/css application/x-javascript text/plain text/xml image/x-icon;
}

1-3. Предварительное сжатие / Скрипт
Бывает так, что сервер, обеспечивающий работу вашего блога, не поддерживает mod_deflate или mod_gzip. В этом случае можно прибегнуть к универсальному скрипту, который работает и на Apache, и на Nginx.

В основном файле используемого вами движка, в самое его начало, первой строкой нужно вставить:

function isClientSupportGzip() {
if (headers_sent() || connection_aborted()) return false;
if (stripos(getenv("HTTP_ACCEPT_ENCODING"), "gzip") === false) return false;
if (stripos(getenv("HTTP_USER_AGENT"), "konqueror") !== false) return false;
return true;
}

If (isClientSupportGzip()) {
ob_start("ob_gzhandler");
}
else {
ob_start();
}

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

2. Браузерное кэширование
Наряду со сжатием можно давать браузеру команду использовать кэшированную копию. Зачем каждый раз качать файлы с сайта, если они не с момента последнего посещения не изменились? Лучше отслеживать изменения файлов, и скачивать только те, которые им подверглись, а те, что остались с последнего захода на сайт не измененными, брать их кэша. Этот способ позволяет существенно сократить трафик между браузером посетителя и хостингом сайта, что приводит к сокращению времени загрузки страниц. Особенно заметен прирост в скорости на страницах с картинками. Действительно, картинки меняются на сайте очень редко, и зачем их каждый раз закачивать, есди они уже есть в кэше браузера?

2-1. Браузерное кэширование / установки заголовков / Apache
Apache обеспечивает браузерное кэширование с помощью модулей mod_expires и mod_headers: mod_expires определяет время актуальности кэшированных данных, а mod_headers - их публичную доступность. Совместная работа приводит к гибкой проверке данных перед скачиванием: браузер получает специальные заголовки, по ним определяет, устарели ли данные, которые находятся у него в кэше с момента последнего посещения страницы, и если они устарели, то обновляет их, закачивания новые версии файлов, а если не устарели, то отображает файлы из своего кэша, не скачивая с сервера.

Если у вас работает Apache, для установки заголовков Expires добавьте в файл.htaccess:

ExpiresActive On
ExpiresDefault "access plus 5 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"

В данном случае актуальность кэша для разных фалов указана в секундах.

Если у вас работает Apache, для установки для установки заголовка Cache-control добавьте в файл.htaccess:

Header set Cache-Control "public"

Header set Cache-Control "private"

Header set Cache-Control "private, must-revalidate"

В данном случае проверяется актуальность в кэше файлов ico, jpg, jpeg, png, gif, swf, css, js, html, xhtml, php.

2-2. Браузерное кэширование / Nginx
Если у вас нет Apache, но есть Nginx, то для того, чтобы указать браузеру брать закэшированные данные, нужно вставить в конфиг nginx следующие строки:

location ~* \.(jpg|png|gif|jpeg|css|js)$ {
expires 24h;
}

В данном случае актуальность кэша 24 часа, а типы проверяемых файлов указаны перечислением - jpg, png, gif, jpeg, css, js.

Вот собственно и все основы, удачного ускорения ваших сайтов! ;)

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Например, закэшировать главную страницу можно так:

Fastcgi_cache_path /var/cache/nginx levels= keys_zone=wholepage:50m; ... server { ... location / { ... fastcgi_pass 127.0.0.1:9000; ... # Включаем кэширование и тщательно выбираем ключ кэша. fastcgi_cache wholepage; fastcgi_cache_valid 200 301 302 304 5m; fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; # Гарантируем, что разные пользователи не получат одну и ту же сессионную Cookie. fastcgi_hide_header "Set-Cookie"; # Заставляем nginx кэшировать страницу в любом случае, независимо от # заголовков кэширования, выставляемых в PHP. fastcgi_ignore_headers "Cache-Control" "Expires"; } }

Я не сильно преувеличу, если скажу, что каждая строчка в этом конфиге написана кровью. Здесь много подводных камней, давайте их все рассмотрим.

fastcgi_cache_path: простота отладки тоже важна

fastcgi_cache_path /var/cache/nginx levels= keys_zone=wholepage:50m;

В директиве fastcgi_cache_path я выставляю «пустое» значение для levels. Хотя это немного снижает производительность (файлы будут напрямую создаваться в /var/cache/nginx, без разбиения по директориям), но зато на порядок облегчает отладку и диагностику проблем с кэшем. Поверьте, вам еще не раз придется руками залезать в /var/cache/nginx и смотреть, что там хранится.

fastcgi_cache_valid: кэшируем код ответа 304 тоже

fastcgi_cache_valid 200 301 302 304 5m;

В директиве fastcgi_cache_valid мы заставляем кэшировать не только стандартные коды 200 ОК, 301 Moved Permanently и 302 Found, но также и 304 Not Modified. Почему? Давайте вспомним, что означает 304. Он выдается с пустым телом ответа в двух случаях:

Если браузер послал заголовок «If-Modified-Since: date», в котором date больше либо равна значению заголовка ответа «Last-Modified: date». Т.е. клиент спрашивает: «Есть ли новая версия с момента date? Если нет, верни мне 304 и сэкономь трафик. Если есть, отдай мне тело страницы».
Если браузер послал заголовок «If-None-Match: hash», где hash совапдает со значением заголовка ответа «ETag: hash». Т.е. клиент спрашивает: «Отличается ли текущая версия страницы от той, что я запросил в прошлый раз? Если нет, верни мне 304 и сэкономь трафик. Если да, отдай тело страницы».

В обоих случаях Last-Modified или ETag будут взяты, скорее всего, из кэша nginx, и проверка пройдет очень быстро. Нам незачем «дергать» PHP только для того, чтобы скрипт выдал эти заголовки, особенно в свете того, что клиентам, которым уйдет ответ 200, он будет отдан из кэша.

fastcgi_cache_key: внимательно работаем с зависимостями

fastcgi_cache_key «$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri»;

Особого внимания заслуживает значение в директиве fastcgi_cache_key. Я привел минимальное рабочее значение этой директивы. Шаг вправо, шаг влево, и вы начнете в ряде случаев получать «неправильные» данные из кэша. Итак:

Зависимость от $request_method нам нужна, т.к. HEAD-запросы в Интернете довольно часты. Ответ на HEAD-запрос никогда не содержит тела. Если убрать зависимость от $request_method, то может так совпасть, что кто-то до вас запросил главную страницу HEAD-методом, а вам потом по GET отдастся пустой контент.
Зависимость от $http_if_modified_since нужна для того, чтобы кэш с ответом 304 Not Modified не был случайно отдан клиенту, делающему обычный GET-запрос. Иначе клиент может получить пустой ответ из кэша.
То же самое и с $http_if_none_match. Мы должны быть застрахованы от выдачи пустых страниц клиентам!
Наконец, зависимость от $host и $request_uri не требует комментариев.

fastcgi_hide_header: решаем проблемы с безопасностью

fastcgi_hide_header «Set-Cookie»;

Директива fastcgi_hide_header очень важна. Без нее вы серьезно рискуете безопасностью: пользователи могут получить чужие сессии через сессионную Cookie в кэше. (Правда, в последних версиях nginx что-то было сделано в сторону автоматического учета данного фактора.) Понимаете, как это происходит? На сайт зашел Вася Пупкин, ему выдалась сессия и сессионная Cookie. Пусть кэш на тот момент оказался пустым, и в него записалась Васина Cookie. Затем пришел другой пользователь, получил ответ из кэша, а в нем - и Cookie Васи. А значит, и его сессию тоже.

Можно, конечно, сказать: давайте не будем вызывать session_start () на главной странице, тогда и с Cookies проблем не будет. В теории это так, но на практике данный способ очень неустойчив. Сессии часто стартуют «отложено», и достаточно какой-либо части кода «случайно» вызвать функцию, требующую доступа к сессии, как мы получим дыру в безопасности. А безопасность - такая штука, что если в той или иной методике может возникнуть дыра по неосторожности, то эта методика считается «дырявой» по определению. К тому же есть и другие Cookies, кроме сессионной; их тоже не надо записывать в кэш.

fastcgi_ignore_headers: не даем сайту «лечь» от нагрузки при опечатке

fastcgi_ignore_headers «Cache-Control» «Expires»;

Сервер nginx обращает внимание на заголовки Cache-Control, Expires и Pragma, которые выдает PHP. Если в них сказано, что страницу не нужно кэшировать (либо что она уже устарела), то nginx не записывает ее в кэш-файл. Это поведение, хотя и кажется логичным, на практике порождает массу сложностей. Поэтому мы его блокируем: благодаря fastcgi_ignore_headers в кэш-файлы попадет содержимое любой страницы, независимо от ее заголовков.

Что же это за сложности? Они опять связаны с сессиями и функцией session_start (), которая в PHP по умолчанию выставляет заголовки «Cache-Control: no-cache» и «Pragma: no-cache». Здесь существует три решения проблемы:

Не пользоваться session_start () на странице, где предполагается кэширование. Один из минусов этого способа мы уже рассмотрели выше: достаточно одного неосторожного движения, и ваш сайт, принимающий тысячи запросов в секунду на закэшированную главную страницу, моментально «ляжет», когда кэш отключится. Второй минус - нам придется управлять логикой кэширования в двух местах: в конфиге nginx и в PHP-коде. Т.е. эта логика окажется «размазанной» по совершенно разным частям системы.
Выставить ini_set ("session.cache_limiter", ""). Это заставит PHP запретить вывод каких-либо заголовков, ограничивающих кэширование при работе с сессиями. Проблема здесь та же: «размазанность» логики кэширования, ведь в идеале мы бы хотели, чтобы все кэширование управлялось из единого места.
Игнорировать заголовки запрета кэширования при записи в кэш-файлы при помощи fastcgi_ignore_headers. Кажется, это беспроигрышное решение, поэтому я его и советую.

Кэширование с ротацией

Статическая главная страница - это не так уж и интересно. Что делать, если на сайте много материалов, а Главная выступает в роли своеобразной «витрины» для них? На такой «витрине» удобно отображать «случайные» материалы, чтобы разные пользователи видели разное (и даже один пользователь получал новый контент, перезагрузив страницу в браузере).

Решение задачи - кэширование с ротацией:

Мы заставляем скрипт честно выдавать элементы главной странице в случайном порядке, выполняя необходимые запросы в базу данных (пусть это и медленно).
Затем мы сохраняем в кэше не одну, а, скажем, 10 вариантов страницы.
Когда пользователь заходит на сайт, мы показываем ему один из этих вариантов. При этом, если кэш пуст, то запускается скрипт, а если нет, то результат возвращается из кэша.
Устанавливаем время устаревания кэша малым (например, 1 минута), чтобы за день разные пользователи «отсмотрели» все материалы сайта.

В итоге первые 10 запросов к скрипту-генератору выполнятся «честно» и «нагрузят» сервер. Зато потом они «осядут» в кэше и в течение минуты будут выдаваться уже быстро. Прирост производительности тем больше, чем больше посетителей на сайте.

Вот кусочек конфига nginx, реализующий кэширование с ротацией:

Fastcgi_cache_path /var/cache/nginx levels= keys_zone=wholepage:50m; perl_set $rand "sub { return int rand 10 }"; ... server { ... location / { ... fastcgi_pass 127.0.0.1:9000; ... # Включаем кэширование и тщательно выбираем ключ кэша. fastcgi_cache wholepage; fastcgi_cache_valid 200 301 302 304 1m; fastcgi_cache_key "$rand|$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; # Гарантируем, что разные пользователи не получат одну и ту же сессионную Cookie. fastcgi_hide_header "Set-Cookie"; # Заставляем nginx кэшировать страницу в любом случае, независимо от # заголовков кэширования, выставляемых в PHP. fastcgi_ignore_headers "Cache-Control" "Expires"; # Заставляем браузер каждый раз перезагружать страницу (для ротации). fastcgi_hide_header "Cache-Control"; add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"; fastcgi_hide_header "Pragma"; add_header Pragma "no-cache"; # Выдаем всегда свежий Last-Modified. expires -1; # Внимание!!! Эта строка expires необходима! add_header Last-Modified $sent_http_Expires; } }

Вы можете заметить, что по сравнению с предыдущим примером мне пришлось добавить еще 6 директив в location. Они все очень важные! Но не будем забегать вперед, рассмотрим все по порядку.

perl_set: зависимость-рандомизатор

perl_set $rand "sub { return int rand 10 }";

С директивой perl_set все просто. Мы создаем переменную, при использовании которой nginx будет вызывать функцию встроенного в него Perl-интерпретатора. По словам автора nginx, это достаточно быстрая операция, так что мы не будем «экономить на спичках». Переменная принимает случайное значение от 0 до 9 в каждом из HTTP-запросов.

fastcgi_cache_key: зависимость от рандомизатора

fastcgi_cache_key «$rand|$request_method|...»;

Теперь мы замешиваем переменную-рандомизатор в ключ кэша. В итоге получается 10 разных кэшей на один и тот же URL, что нам и требовалось. Благодаря тому, что скрипт, вызываемый при кэш-промахе, выдает элементы главной страницы в случайном порядке, мы получаем 10 разновидностей главной страницы, каждая из которой «живет» 1 минуту (см. fastcgi_cache_valid).

add_header: принудительно выключаем браузерный кэш

fastcgi_hide_header "Cache-Control"; add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"; fastcgi_hide_header "Pragma"; add_header Pragma "no-cache";

Выше мы говорили, что nginx чувствителен к кэш-заголовкам, выдаваемым PHP-скриптом. Если PHP-скрипт возвращает заголовки «Pragma: no-cache» или «Cache-Control: no-store» (а также еще некоторые, например, «Cache-Control: не-сохранять, не-выдавать, меня-тут-не-было, я-этого-не-говорил, чья-это-шляпа»), то nginx не будет сохранять результат в кэш-файлах. Специально чтобы подавить такое его поведение, мы используем fastcgi_ignore_headers (см. выше).

Чем отличается «Pragma: no-cache» от «Cache-Control: no-cache»? Только тем, что Pragma - наследие HTTP/1.0 и сейчас поддерживается для совместимости со старыми браузерами. В HTTP/1.1 используется Cache-Control.

Однако есть еще кэш в браузере. И в некоторых случаях браузер может даже не пытаться делать запрос на сервер, чтобы отобразить страницу; вместо этого он достанет ее из собственного кэша. Т.к. у нас ротация, нам такое поведение неудобно: ведь каждый раз, заходя на страницу, пользователь должен видеть новые данные. (На самом деле, если вы все же хотите закэшировать какой-нибудь один вариант, то можно поэкспериментировать с заголовком Cache-Control.)

Директива add_header как раз и передает в браузер заголовок запрета кэширования. Ну а чтобы этот заголовок случайно не размножился, мы вначале убираем из HTTP-ответа то, что записал туда PHP-скрипт (и то, что записалось в nginx-кэш): директива fastcgi_hide_header. Ведь вы, когда пишете конфиг nginx-а, не знаете, что там надумает выводить PHP (а если используется session_start (), то он точно надумает). Вдруг он выставит свой собственный заголовок Cache-Control? Тогда их будет два: PHP-шный и добавленный нами через add_header.

expires и Last-Modified: гарантируем перезагрузку страницы

expires -1; # Внимание!!! Эта строка expires необходима! add_header Last-Modified $sent_http_Expires;

Еще один трюк: мы должны выставить Last-Modified равным текущему времени. К сожалению, в nginx нет переменной, хранящей текущее время, однако она магическим образом появляется, если указать директиву expires -1.

Хотя это сейчас (октябрь 2009 г.) не задокументировано, nginx создает переменные вида $sent_http_XXX для каждого заголовка ответа XXX, отданного клиенту. Одной из них мы и пользуемся.

Почему же так важно выставлять текущим временем этот заголовок? Все довольно просто.

Давайте представим, что PHP выдал заголовок «Last-Modified: некоторая_дата».
Данный заголовок будет записан в кэш-файл nginx (можете проверить: в нашем примере файлы хранятся в /var/cache/nginx), а потом отдан в браузер клиенту.
Браузер запомнит страницу и дату ее модификации...
… поэтому при следующем заходе пользователя на сайт в HTTP-запросе будет заголовок-вопрос «If-Modified-Since: некоторая_дата».
Что же сделает nginx? Он достанет страницу из своего кэша, разберет ее заголовки и сравнит Last-Modified с If-Modified-Since. Если значения совпадут (или первое окажется меньше второго), то nginx вернет ответ «304 Not Modified» с пустым телом. И пользователь не увидит никакой ротации: он получит то, что уже видел раньше.

На самом деле, большой вопрос, как поведет себя браузер при наличии одновременно Last-Modified и Cache-Control no-cache. Будет ли он делать запрос If-Modified-Since? Кажется, что разные браузеры ведут тут себя по-разному. Экспериментируйте.

Есть и еще один повод выставлять Last-Modified вручную. Дело в том, что PHP-функция session_start () принудительно выдает заголовок Last-Modified, но указывает в нем… время изменения PHP-файла, который первый получил управление. Следовательно, если у вас на сайте все запросы идут на один и тот же скрипт (Front Controller), то ваша Last-Modified будет почти всегда равна времени изменения этого единственного скрипта, что совершенно не верно.

Динамическое «окно» в закэшированной странице

Ну и напоследок упомяну одну технику, которая может быть полезна в свете кэширования. Если вам хочется закэшировать главную (или любую другую) страницу сайта, однако мешает один маленький блок, который обязательно должен быть динамическим, воспользуйтесь модулем для работы с SSI.

В ту часть страницы, которая должна быть динамической, вставьте вот такой «HTML-комментарий»:

С точки зрения кэша nginx данный комментарий - обычный текст. Он будет сохранен в кэш-файле именно в виде комментария. Однако позже, при прочтения кэша, сработает модуль SSI nginx, который обратится к динамическому URL. Конечно, по адресу /get_user_info/ должен быть PHP-обработчик, который выдает содержимое данного блока.

Ну и, естественно, не забудьте включить SSI для этой страницы или даже для всего сервера:

Директива SSI include имеет еще одно, крайне важное свойство. Когда на странице встречаются несколько таких директив, то все они начинают обрабатываться одновременно, в параллельном режиме. Так что, если у вас на странице 4 блока, каждый из которых загружается 200мс, в сумме страница будет получена пользователем через 200мс, а не через 800.