Кэширование в Nginx

В статье посвящённой обратному проксированию в Nginx мы с вами не коснулись одной важной темы — кэширования отдаваемого upstream-серверами контента. Когда клиент выполняет запрос, например, к PHP-сценарию, его обработкой занимается upstream-сервер. Работа сценария часто связана с вызовом других сценариев, запросам к базам данных, выполнении довольно тяжёлых в плане потребления ресурсов сервера операций. И очень часто вся эта «каша» заваривается для того, чтобы просто отдать клиенту сформированную страницу; т. е. следующий запрос к этому же сценарию с теми же параметрами запустит ещё один процесс обработки с точно такими же условиями и результатами. А что будет с сервером, когда таких запросов будет несколько десятков в секунду? Несколько сотен? На эти вопросы и на то, как с этим жить, имея в распоряжении Nginx, попытаемся ответить в этой статье.

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

Исходные данные

В качестве PHP-сценария для проведения тестов использовался небольшой скрипт, выбирающий все строки из таблицы БД MySQL и выводящий результаты при помощи var_dump ():

$oPDO = new PDO("mysql:server=localhost;dbname=test;", 'user', 'password'); $oQRes = $oPDO->query("SELECT * FROM test1"); var_dump($oQRes->fetchAll());

1 2 3

$oPDO = new PDO("mysql:server=localhost;dbname=test;", 'user', 'password'); $oQRes = $oPDO->query("SELECT * FROM test1"); var_dump($oQRes->fetchAll());

Структура таблицы test1 БД следующая:

+-------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | text | YES | | NULL | | +-------+---------+------+-----+---------+----------------+

1 2 3 4 5 6

+-------+---------+------+-----+---------+----------------+ | Field | Type    | Null | Key | Default | Extra          | +-------+---------+------+-----+---------+----------------+ | id    | int(11) | NO   | PRI | NULL    | auto_increment | | name  | text    | YES  |     | NULL    |                | +-------+---------+------+-----+---------+----------------+

Таблица содержит 10000 записей, где в каждом поле name записан MD5-хеш случайного числа в диапазоне от 0 до time (). URL сценария, работающего под Apache — http://test.ashep:80/test.php. Давайте посмотрим при помощи siege как сервер будет обрабатывать запросы к этому сценарию.

Прямые запросы к Apache

Эмулируем 10 серий по 10 одновременных запросов:

$ siege -c 10 -r 10 http://test.ashep:80/test.php Transactions: 100 hits Availability: 100.00 % Elapsed time: 109.66 secs Data transferred: 32.65 MB Response time: 10.30 secs Transaction rate: 0.91 trans/sec Throughput: 0.30 MB/sec Concurrency: 9.39 Successful transactions: 100 Failed transactions: 0 Longest transaction: 12.76 Shortest transaction: 3.66

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$ siege -c 10 -r 10 http://test.ashep:80/test.php   Transactions:                 100 hits Availability:              100.00 % Elapsed time:              109.66 secs Data transferred:           32.65 MB Response time:               10.30 secs Transaction rate:            0.91 trans/sec Throughput:                0.30 MB/sec Concurrency:                9.39 Successful transactions:         100 Failed transactions:               0 Longest transaction:           12.76 Shortest transaction:            3.66

Сервер успешно обработал все запросы, однако время на обработку каждого составило в среднем 10,3 секунд.

Проксирование через Nginx

Теперь создадим реверс-прокси сервер в Nginx так, как мы это делали в предыдущей статье, в качестве upstream-сервера будем использовать наш Apache по http://test.ashep:80.

server { listen 8080; server_name test.ashep; access_log /var/log/nginx/test.access_log; error_log /var/log/nginx/test.error_log; location / { proxy_pass http://test.ashep:80; } }

1 2 3 4 5 6 7 8 9 10

server {     listen 8080;     server_name test.ashep;     access_log /var/log/nginx/test.access_log;     error_log /var/log/nginx/test.error_log;       location / {         proxy_pass http://test.ashep:80;     } }

Повторим тест, на этот раз уже через Nginx:

$ siege -c 10 -r 10 http://test.ashep:8080/test.php Transactions: 100 hits Availability: 100.00 % Elapsed time: 104.97 secs Data transferred: 32.65 MB Response time: 9.77 secs Transaction rate: 0.95 trans/sec Throughput: 0.31 MB/sec Concurrency: 9.31 Successful transactions: 100 Failed transactions: 0 Longest transaction: 14.54 Shortest transaction: 2.89

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$ siege -c 10 -r 10 http://test.ashep:8080/test.php   Transactions:                 100 hits Availability:              100.00 % Elapsed time:              104.97 secs Data transferred:           32.65 MB Response time:                9.77 secs Transaction rate:            0.95 trans/sec Throughput:                0.31 MB/sec Concurrency:                9.31 Successful transactions:         100 Failed transactions:               0 Longest transaction:           14.54 Shortest transaction:            2.89

Результаты примерно те же. Логично, поскольку Nginx всего лишь транслирует запросы к upstream-серверу, ничего при этом не кэшируя.

Кэширующее проксирование через Nginx

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

Определять кэш можно лишь в контексте секции http, которая, например, в моём Debian описана в /etc/nginx/nginx.conf. Для определения кэша используется опция proxy_cache_path, которая имеет следующий формат:

proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time] [max_size=size];

1	proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time] [max_size=size];

В квадратных скобках приведены необязательные параметры. Теперь обо всём по порядку:

• path определяет место в файловой системе, где будет храниться кэш. Кэш в Nginx хранится в виде обычных файлов, каждый из которых хранит содержимое ответа на какой-то запрос. URL запроса хешируется в MD5 и полученная строка используется в качестве имени файла кэша, а также ключа, по которому Nginx будет отыскивать нужный фрагмент кэша;
• при помощи levels можно определить количество уровней вложенности каталогов с файлами кэша. Формат описания уровней может быть одним из: 'X', 'X:X' или 'X:X:X', что соответственно определяет один, два или три уровня вложенности каталогов. Каждая 'X' является единицей или двойкой и определяет количество символов в имени каталога соответствующего уровня;
• значением параметра keys_zone определяется имя кэша (zone_name), на которое можно ссылаться из других участков конфигурации сервера, а также её размер (zone_size);
• при помощи необязательного параметра inactive определяется время жизни объектов кэша, если к ним не было запросов. Т. е. если в течение указанного периода времени объект кэша ни разу не запрашивался — он подлежит удалению. Значение параметра inactive по умолчанию равно 10 минутам (10m);
• значение необязательного параметра max_size определяет размер кэша, больше которого ему не будет позволено «раздуваться».

В ходе моих экспериментов, рассматриваемых в этой заметке, я использовал следующее значение опции proxy_cache:

proxy_cache_path /var/cache/nginx levels=2:2 keys_zone=default:100m;

1	proxy_cache_path /var/cache/nginx levels=2:2 keys_zone=default:100m;

Приведённой выше строкой создаётся двухуровневый кэш в каталоге /var/cache/nginx с именем 'default' и размером 100 мегабайт. Теперь определённый кэш default можно использовать в конфигурации серверов Nginx. Слегка дополненная конфигурация сервера, приводившаяся выше:

server { listen 8080; server_name test.ashep; access_log /var/log/nginx/test.access_log; error_log /var/log/nginx/test.error_log; location / { proxy_pass http://test.ashep:80; proxy_cache default; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; } }

1 2 3 4 5 6 7 8 9 10 11 12 13

server {     listen 8080;     server_name test.ashep;     access_log /var/log/nginx/test.access_log;     error_log /var/log/nginx/test.error_log;       location / {         proxy_pass http://test.ashep:80;         proxy_cache default;         proxy_cache_valid   200 302 10m;         proxy_cache_valid   404 1m;     } }

Обратите внимание на две новых опции. При помощи параметра proxy_cache мы указываем Nginx какой кэш необходимо использовать при кэшировании данных от upstream-сервера, в данном случае — это 'default', определённый ранее в /etc/nginx/nginx.conf. Опция proxy_cache_valid определяет время в течение которого не устаревшими будут считаться объекты кэша, полученные полученные в результате ответов upstream-сервера. Формат опции следующий:

proxy_cache_valid код_ответа [код_ответа код_ответа ...] время

1	proxy_cache_valid код_ответа [код_ответа код_ответа ...] время

Таким образом ответы upstream-сервера с кодами 200 и 302 будут кэшироваться на 10 минут, а ошибки 404 — в течение одной минуты.
Сохранив конфиг-файлы и перезапустив Nginx, попробуем провести нагрузочное тестирование с включённым кэшированием:

$ siege -c 10 -r 10 http://test.ashep:8080/test.php Transactions: 100 hits Availability: 100.00 % Elapsed time: 15.68 secs Data transferred: 32.65 MB Response time: 0.73 secs Transaction rate: 6.38 trans/sec Throughput: 2.08 MB/sec Concurrency: 4.65 Successful transactions: 100 Failed transactions: 0 Longest transaction: 9.51 Shortest transaction: 0.02

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$ siege -c 10 -r 10 http://test.ashep:8080/test.php   Transactions:                 100 hits Availability:              100.00 % Elapsed time:               15.68 secs Data transferred:           32.65 MB Response time:                0.73 secs Transaction rate:            6.38 trans/sec Throughput:                2.08 MB/sec Concurrency:                4.65 Successful transactions:         100 Failed transactions:               0 Longest transaction:            9.51 Shortest transaction:            0.02

Среднее время ответа от сервера составило 0,73 секунды. Неплохо, правда? ;)

• adc-lj • 5 дней назад

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

  • ответить • поделиться
  • 
    Alexander Shepetko • 5 дней назад

    Добрый день. http://ru.wikibooks.org/wiki/%D0%A0%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%80%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F http://www.pcre.ru/

    • ответить • поделиться
    • 
      adc-lj • 2 дня назад

      вроде кое-что стало понятно. Вы не могли бы разъяснить такое выражение (определение userdir) location ~ ^/~(.+?)(/.*)?$ ~ - начало регулярного выражения ^ - начало строки / - ????? ~ - тильда (.+?) - группа ???? (/.*)? - группа ???? $ - конец регулярного выражения

      • ответить • поделиться
      • 
        adc-lj • 2 дня назад

        понял /~ - обычные символы, которые должны быть (.+?) - группа ???? (/.*)? - группа ????

        • ответить • поделиться
        • 
          Alexander Shepetko • день назад

          Тильда означает "регистрозависимый поиск". Смотрите http://wiki.nginx.org/HttpCoreModule#location

          • ответить • поделиться
        • 
          adc-lj • 2 дня назад

          и ещё несколько сбивает, что в директиве rewrite ~ использовать не нужно.

          • ответить • поделиться
          • 
            Alexander Shepetko • день назад

            А вы документацию поглядите, и тогда вас сбивать ничего не будет ;) http://wiki.nginx.org/HttpCoreModule#location http://wiki.nginx.org/HttpRewriteModule#rewrite

            • ответить • поделиться
          • 
            adc-lj • 2 дня назад

            (.+?) - группа: любой символ хотя бы один раз? p.s. извините, что столько комментов, но у вас их нельзя ни редактировать, ни удалять :(

            • ответить • поделиться
            • 
              Alexander Shepetko • день назад

              Вопросительный знак играет разную роль в зависимости от того, где он используется. Если он стоит после обычного символа или группы, то да -- это означает "предыдущий элемент повторяется ноль или один раз". Например, под шаблон 'linu?x' подойдут как 'linux' так и 'linx'. Или, скажем, под 'lin(ux)?' подойдут как 'linux', так и 'lin'. А вот если '?' стоит после квантификатора '+' или '*', то здесь он играет роль "ограничителя жадности". Например, возьмите выражение '(.+)blabla'. Это выражение "захавает" не только то, что до 'blabla', но и 'blabla', и всё до конца строки, потому что выражение в скобках обозначает "ЛЮБОЙ символ один или более раз". Чтоб ограничить "жадность" регулярки, используется вопросительный знак после квантификатора, т. е.: '(.+?)blabla', которая говорит: 'любой символ один или более раз, НО не трогать то, что стоит после!'.

              • ответить • поделиться
    • 
      adc-lj • 4 дня назад

      спасибо большое! пошел учиться

      • ответить • поделиться
• 
  Роман Жуков • 3 месяца назад

  Все сделал по мануалу- но не работает.. пишет при рестарте "proxy_cache" zone "default" is unknown in /etc/nginx/nginx.conf:825 configuration file /etc/nginx/nginx.conf test failed Куда копать?.. Кстати, можно к Вам обратиться за настройкой VPS сервера? оптимизация очень нужна.. Естественно, не бесплатно =).. а то толкового специалиста- очень тяжело найти...

  • ответить • поделиться
  • 
    Alexander Shepetko • 3 месяца назад

    Прежде чем помочь вам определяться с направлением копания, хотелось бы увидеть конфиг полностью. Исходя из текста ошибки очевидно, что у вас не определена зона 'default' параметром proxy_cache_path. Лучше всего выложите конфиг на какой-нибудь pastebin и дайте ссылку, так легче будет диагностировать. Насчёт помощи в оптимизации VPS: увы, пока помочь не смогу.

    • ответить • поделиться
    • 
      Роман Жуков • 3 месяца назад

      Прописал в nginx.conf вот так: http { ## # Basic Settings ## #кеш #proxy_cache_path /var/cache/nginx levels=2:2 keys_zone=default:1000m; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; и в секцию домена прописал вот так: location / { proxy_pass http://1.1.1.1:8080; proxy_redirect http://site.ru:8080/ /; proxy_cache_path /var/cache/nginx levels=2:2 keys_zone=default:100m; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr;

      • ответить • поделиться
      • 
        Alexander Shepetko • 3 месяца назад

        Так у вас же proxy_cache_path закомментирован ;)

        • ответить • поделиться
• 
  BuxarNET • 7 месяцев назад

  А как быть если нужно кеш отдавать только просто посетителям, но если пользователь залогинировался, что бы динамику отдавать?

  • ответить • поделиться
• 
  Kor-Elf • 12 месяцев назад

  Наконец-то разобрался, как кэшировать в nginx, спасибо за статьи!

  • ответить • поделиться
• 
  Константин • год назад

  Подскажите как записать конструкцию location / { proxy_pass http://test.ashep:80; } если на сервере есть два сайта и по ip ничего не выдается, а nginx должен работать как кэширующий прокси на другом сервере. Вариант с указанием ip не работает. location / { proxy_pass http://xxx.xxx.xxx.xxx:80; } Планируется что DNS, настраиваемого домена, должен указывать на кэширующий сервер, т.е. прописать имя сайта я в proxy_pass не могу. Вариант с поддоменами выглядит некрасиво. Правильно ли я понимаю что единственный вариант правильно перенаправить запрос на нужный ip - это прописать в hosts кэширующего сервера домен и ip основного сервера, а в конфигурации написать proxy_pass http://domen.ru/?

  • ответить • поделиться
• 
  /bin/user • год назад

  > А раз права не защищены — пользуйтесь все на здоровье ;) К сожалению, законы о авторских правах немного другого мнения: по умолчанию все права - у автора. А если кто без лицензии взял - он, стало быть, пират. Ну вот такие вот законы протолкали господа демократы, увы.

  • ответить • поделиться
• 
  Qaz • год назад

  Статья не плохая, но почему не освещены нюансы работы с cookies при такой схеме?

  • ответить • поделиться
  • 
    ashep • год назад

    Qaz, потому что автор ещё ничего об этом не знает ;)

    • ответить • поделиться
• 
  /bin/user • год назад

  > Даже без лицензий ;) Нынче если брать без лицензий - к сожалению можно нарваться на проблемы. Ну вот вы - добрый. А вот кто-то еще - менее добрый и вот возьмешь у него статью, а потом по судам затаскают. Поэтому хорошо бы явно и прозрачно указывать правила игры. Ну, чтобы можно было понимать - что льзя, что нельзя.

  • ответить • поделиться
  • 
    ashep • год назад

    /bin/user, у меня нигде на сайте не написано о том, что права защищены. А раз права не защищены - пользуйтесь все на здоровье ;)

    • ответить • поделиться
• 
  Dmitry Paskal • год назад

  Александр, посмотрите в сторону creative commons. Публиковали бы статьи с соответствующей лицензией - wikidadmin мог бы их взять и доработать. http://creativecommons.org/ - там информация, для wordpress есть плагин с таким же названием, в пару кликов добавляет информацию о лицензии для поисковиков и людей.

  • ответить • поделиться
  • 
    ashep • год назад

    Дмитрий, да я ж не возражаю, пусть берут кому нужно, дорабатывают, переписывают. Не жалко совершенно. Даже без лицензий ;)

    • ответить • поделиться
• 
  Aleksdem • год назад

  Конечно статьи, людей перестали продавать уже давно :D

  • ответить • поделиться
• 
  Сергей. • год назад

  Отлично. Доступно и "понимабельно". Спасибо.

  • ответить • поделиться
• 
  ashep • год назад

  Меня или статьи? :)

  • ответить • поделиться
• 
  Aleksdem • год назад

  Классная серия статей у вас. Были бы деньги - выкупил бы. :)

  • ответить • поделиться