Все о тюнинге авто

Кэширование centos 6 gzip nginx. Кэширование с Nginx. Кэширование браузера Nginx

Давно минули те старые добрые времена, когда сайты были сделаны на голом HTML и их страницы весили несколько десятков килобайт. А интернет был на dial-up.

Страницы современных сайтов весят уже несколько сотен килобайт, а частенько и несколько мегабайт. Картинки, скрипты, файлы стилей CSS - всё это непременные атрибуты нормального современного сайта и без них никак. А весит всё это «счастье» совсем не мало, и каждый раз посетители, зашедшие на ваш сайт, загружают всё это на свой компьютер. И пока загрузка не завершится, в браузере страница не откроется.

Рассмотрим метод борьбы с этой проблемой посредством вебсервера Nginx. Суть в том, что мы сделаем 2 вещи - сожмём все статические файлы (скрипты, файлы стилей) посредством gzip, и закэшируем их вместе с картинками в кэше браузера посетителя, чтобы они каждый раз не загружались с сайта, а брались прямо из кэша на компьютере посетителя сайта.

Настройка сжатия данных посредством Nginx.

Открываем файл конфигурации Nginx, расположенный по адресу /etc/nginx/nginx.conf

И в секцию http {…}, которая находится в начале файла добавляем то, чего там нет из примера ниже:

Gzip on; gzip_static on; gzip_comp_level 5; gzip_min_length 1024; gzip_proxied any; gzip_types text/plain application/xml application/x-javascript text/javascript text/css text/json;

Настройка кэширования статических файлов в кэше браузера пользователя, посредством Nginx.

В том же файле /etc/nginx/nginx.conf спускаемся ниже, находим конструкцию server для нужного сайта и дописываем туда:

Location ~* ^.+.(jpg|jpeg|gif|png|ico|css|pdf|ppt|txt|bmp|rtf|js)$ { root /var/www/user/data/www/site.ru; expires 7d;

где expires 7d - это количество дней, сколько кэш статических файлов должен храниться на компьютере пользователя. Если вы не вносите правки в css, js, файлы своего сайта и не меняете картинки, то имеет смысл этот параметр увеличить, вплоть до нескольких месяцев или даже до года.

Для наглядности приводим участок секции server из сервера, в котором Nginx был установлен стандартными средствами панели ISPmanager:

Server { server_name site.ru www.site.ru; listen 111.121.152.21; disable_symlinks if_not_owner from=$root_path; set $root_path /var/www/user/data/www/site.ru; location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root $root_path; access_log /var/www/nginx-logs/user isp; access_log /var/www/httpd-logs/site.ru.access.log ; error_page 404 = @fallback; }

А теперь мы добавим сюда expires 7d , теперь это будет выглядеть вот так:

Server { server_name site.ru www.site.ru; listen 111.121.152.21; disable_symlinks if_not_owner from=$root_path; set $root_path /var/www/user/data/www/site.ru; location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root $root_path; expires 7d; access_log /var/www/nginx-logs/user isp; access_log /var/www/httpd-logs/site.ru.access.log ; error_page 404 = @fallback; }

Перезагружаем Nginx командой:

Service nginx restart

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

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

Не всегда бывает достаточно внесения правок в.htaccess файл для включения жизненно-необходимых для быстрой работы сайта функций, как сжатие и кеширование браузером. Особенно если у вас сервер на NGINX.

Приведу пример для включения этого функционала.

Сразу сделаем оговорку. Вы должны иметь доступ к файл nginx.conf из каталога /usr/local/nginx/conf , или /etc/nginx , или /usr/local/etc/nginx , в зависимости от ОС. Это подразумевает что у Вас выделенный или виртуальный сервер. На обычных хостингах может помочь только обращение в техническую поддержку.

Сжатие GZIP для сайта на NGINX

Выглядит это следующим образом

Http { #buffer_size, разные include и прочие общие настройки gzip on; gzip_min_length 1000; gzip_proxied any; gzip_disable "MSIE \.(?!.*SV1)"; gzip_types text/plain text/xml application/xml application/x-javascript text/javascript text/css text/json; gzip_comp_level 1; server { #настройки каждого из сайтов на сервере } }

Таким образом для всех сайтов на сервере включается сжатие.

Кеширование браузером

Для кеширования необходимы следующие изменения:

Location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { expires 30d; #Остальные директивы }

Таким образом решается эта простая проблема, которая становится порой серьезной головной болью вебмастеров, плохо знакомых с работой системного администратора Linux.

В 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. Кажется, это беспроигрышное решение, поэтому я его и советую.

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

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

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

  1. Мы заставляем скрипт честно выдавать элементы главной странице в случайном порядке, выполняя необходимые запросы в базу данных (пусть это и медленно).
  2. Затем мы сохраняем в кэше не одну, а, скажем, 10 вариантов страницы.
  3. Когда пользователь заходит на сайт, мы показываем ему один из этих вариантов. При этом, если кэш пуст, то запускается скрипт, а если нет, то результат возвращается из кэша.
  4. Устанавливаем время устаревания кэша малым (например, 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, отданного клиенту. Одной из них мы и пользуемся.

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

  1. Давайте представим, что PHP выдал заголовок «Last-Modified: некоторая_дата».
  2. Данный заголовок будет записан в кэш-файл nginx (можете проверить: в нашем примере файлы хранятся в /var/cache/nginx), а потом отдан в браузер клиенту.
  3. Браузер запомнит страницу и дату ее модификации...
  4. … поэтому при следующем заходе пользователя на сайт в HTTP-запросе будет заголовок-вопрос «If-Modified-Since: некоторая_дата».
  5. Что же сделает 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.

Лично мной настройка кэширования статики с помощью nginx в Debian задумывалась ради ускорения выдачи статического контента сайта на wordpress. Проблема возникла в том, что при использовании многосайтовой версии wordpress файлы хранятся в директории с длинным путём, при этом используется сокращение адреса за счет правил mod_rewrite. Для того, чтобы nginx выдавал статику, использовалась директива location с указанием расширений статических файлов и путь до директории со статикой:

Location ~* \.(html|jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ { root /path/to/site/; }

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

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

Использовались ОС Debian 7.0, nginx 1.2.1. Предварительно следует обновить Debian .

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

Так как в основном конфиге /etc/nginx/nginx.conf имеем строку include /etc/nginx/conf.d/*.conf , то создаём отдельный файл /etc/nginx/conf.d/cache.conf с базовыми настройками кэша:

Proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:100m inactive=120m max_size=500M; proxy_cache_min_uses 1;

Разберём поэлементно первую строку, начинающуюся с proxy_cache_path . Таких строк может быть несколько, следовательно может быть несколько кэшей со своими параметрами и именами. Итак:

/var/cache/nginx - путь до директории с кэшем.

levels=1:2 - уровни директорий с кэшем. Уровни вложенности задаются через двоеточие, цифрами задаётся длинна имени директории. 1:2 говорит о том, что в директории с кэшем будут созданы директории длинной в одну шестнадцатеричную цифру (от 0 до f) в каждой из которых будут созданы директории с именами состоящими из двух шестнадцатеричных цифр.

keys_zone=static_cache:100m - задаётся имя кэша (static_cache ) и его базовый размер в мегабайтах.

inactive=120m - время отсутствия запросов к элементу кэша, после которого он удаляется из кэша. В минутах. После этого, при запросе к тому же файлу, произойдёт запрос к бэкенду и файл снова попадёт в кэш.

max_size=500M - максимальный размер кэша в мегабайтах.

Вторая строка, как было выяснено экспериментально, также необходима для работы кэша nginx:

proxy_cache_min_uses 1; - указывает после какого количества запросов к файлу он попадёт в кэш.

Не забудьте создать директорию для кэша и задать для нее владельца от имени которого работает nginx в Debian:

Mkdir /var/cache/nginx chown www-data:www-data /var/cache/nginx

Затем в файле описания сайта в директории /etc/nginx/sites-available прописываем примерно следующее:

Location ~* ^.+.(html|jpg|jpeg|gif|css|png|js|ico|gz)$ { expires 60d; proxy_pass http://backend; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_cache static_cache; proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; proxy_cache_valid 1d; }

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

proxy_cache static_cache; - указываем какой кэш использовать.

proxy_cache_valid 1d; - позволяет задать время кэширования для разных кодов ответа. По умолчанию кэшируются только ответы с кодами 200, 301 и 302.

proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; - эта строка самая интересная. Она позволяет настроить по каким признакам считать, что следует кэшировать запросы отдельно. К примеру, значение в файле кэша nginx может выглядеть следующим образом:

GET|||droid.gesu.su|/wp-content/plugins/addthis/css/output.css?ver=3.5.1

Видно, что в данном случае

$request_method = GET
$host = droid.gesu.su
$request_uri = /wp-content/plugins/addthis/css/output.css?ver=3.5.1

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

$http_if_modified_since и $http_if_none_match - позволяют не выдавать страницы с ответом “304 Not Modified” или пустые страницы. В нашем случае, это, скорее всего, не актуально, так как мы выдаём статический контент, который редко изменяется.

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

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