23 марта 2009 в 23:13

NGINX научился кешировать проксированные запросы

Почти год назад на RIT 2008 Игорем Сысоевым была анонсирована поддержка кеширования в будущих версиях nginx. И вот сегодня вышла новая бета nginx 0.7.44, в которой появилось это долгожданное кеширование

Этот функционал оценят в первую очередь разработчики высоконагруженных систем, для которых операция установления сетевого соединения с backend «дороже» обычной дисковой операции (с точки зрения затраты ресурсов)

На RIT 2008 автор отмечал, что большим преимуществом nginx перед демоном squid, который тоже можно использовать как reverse proxy, является отсутствие стартового торможения, когда squid начинает сканировать директорию с кешем, что в народе называется «давать сквида».

Хочется отметить, что некого подобия кеширования можно было добиться с помощью использования директив proxy_store + try_files, но управлять таким кешем было достаточно сложно и затратно.

Очень интересно было бы услышать отзывы от пользовалелей замонтировавших кеш на SSD-диск.
Олег Черний @apelsyn
карма
178,1
рейтинг 0,0
Разработчик
Похожие публикации
Самое читаемое Администрирование

Комментарии (47)

  • +6
    Заранее передаю глубокие соболезнования пользователям, поместившим кеш на SSD-диск.
    • 0
      Есть уже диски и для кеша www.ixbt.com/storage/ssd-intel-x25m.shtml
      • 0
        OCZ Vertex дешевле с той же скоростью ;-)
        Но с 10'000 циклов перезаписи сжечь SSD можно быстро…
    • 0
      Запись там не идёт так уж быстро, что бы заткнуть SSD накопитель. ОК, при старте может быть небольшой затык, но т.к. это в основном read-only и редкая запись нового файла на кеш — скорость отдачи будет очень хорошей.
    • +1
      А какие проблемы могут быть?
      • –1
        Исчерпание количества циклов перезаписи SSD.
  • –7
    я так посмотрю, NGINX — смышленый парень, быстро всему учится в последнее время :)))
    • +8
      nginx – продукт, а смышленый парень – Игорь Сысоев.
      • 0
        а юмор начисто отбило? минусомёты руляд!
  • +1
    давно используем подобную схему, но через proxy_store. стоит ли перейти на новую схему?
    • 0
      Единственный минус текущей реализации — нельзя настраивать ключ кеша, он всегда будет как запрос. Из этого вытекает, что запросы вида site.org/disp?cat=1&page=1 и site.org/disp?page=1&cat=1 и будут разными.

      Сегодня сделал кеширование thumb'ов в галерее (скрипт упорно делает их на лету) через proxy_cache — полет нормальный.
      • 0
        а разве результат в таком случае не должен быть одинаковым с точки зрения приложения?
        от перестановки слагаемых сумма не меняется
        • 0
          С точки зрения приложения — одинаково, а вот кеш-модуль может думать иначе ;)
          • 0
            такое информацией не владею, строки-то по сути разные (значит и ключи).
            Просветите, если несложно, зачем кеш-модулю так думать с оглядкой на кеширование в вебе.
            • 0
              Просто кеш будет забиваться одинаковой информацией, что не очень хорошо.
  • 0
    Отличная новость.
    Ждем появления в стабильной ветке.
  • 0
    Т.е. есть шанс, что Хабрахабр будет отдаваться мне заgzipованным через мою корпаративную проксю? Дома, напрямую, всё отдаётся нормально, а вот на работе, через сквид, Хабр отдаёт мне всё не gzipованное. (Настройки сквида правильные — остальные сайты отдаются нормально)
    • 0
      Сквид не умеет раззгзиповывать файлы из кеша. То есть в кеше лежит либо гзипованный файл — либо нет. Если лежит гзипованый а клиент не умеет принимать сжатых запросов (IE6 за проксей например) — сквид пойдет на сайт за новой версией контента и положит на диск уже несжатую версию.
      Так что это не проблема сквида — nginx в подобной ситуации думается будет вести себя точно так же.
  • +2
    >когда squid начинает сканировать директорию с кешем, что в народе называется «давать сквида».

    но ведь можно использовать cache_mem (т.е. хранить кеш в ОЗУ)

    >Очень интересно было бы услышать отзывы от пользовалелей замонтировавших кеш на SSD-диск.

    можно же ещё хранить его в tmpfs
    • 0
      При большой нагрузке использование дискового кеша в squid становится пыткой для пользователей, поэтому cache_mem побольше, а cache_dir в null, и всё хорошо.
  • 0
    Ещё бы он статику в memcached автоматически помещал…
    • 0
      Зачем туда статику?
      Думаю, ее проще отдать с диска, а если не хватает диска, то смонтировать tmpfs.
      • 0
        tmpfs поможет только если файлы часто удаляются, иначе будет мешать.
        Или вы думаете, что отдача с диска это физическое чтение с диска?
        • 0
          Не очень понял как это связано с удалением.
          Для отдачи статики все нормальные веб-сервера используют sendfile — а уж откуда возьемет операционка этот файл — с диска ли прочтет или же из кеша в памяти — ее дело.
          • +1
            Я не понимаю, зачем для статики или кеша советуют tmpfs
  • +12
    В продакшн ещё конечно рано. Чисто потестировать. Работы там ещё очень много.
    Как сказал Игорь в рассылке:
    «Не знаю, кто что ждал, но я устал смотреть на то, что вытворяют
    с proxy/fastcgi_store, memcached'ом и mod_accel'ем и выпустил то, что есть.»

    Но в любом случае nginx идёт вперёд семимильными шагами. За что Игорю огромное спасибо.
  • 0
    Я почему-то думал, что там есть уже кэш… Разве он и раньше что-то там не кэшировал?
  • +2
    Я, честно говоря, не понял о чем тут идет речь, но уверен в том, что Игорь сделал снова что-то хорошее.

    Огромное ему спасибо от меня, как от руководителя портала, за то, что nginx есть и за то, что nginx есть у нас! До установки я и не думал, что он настолько полезен. Игорь, спасибо! И успехов!
    • 0
      Спасибо на хлеб не намажешь. Donate спасет отца русской технократии!
  • –2
    alexxx.ru/tmp/nginx.gif чего ему мой логотипчик не понравился? :(
  • 0
    будет круче чем mod_accel?
  • 0
    2 apelsyn — а можете дописать в статью пример реальной ситуации, когда эта вещь спасает положение и как именно она это делает?

    Просто не сразу понятно о каком кэшировании речь… мы nginx и так для кэширования (статики) используем уже много лет.
    • 0
      Вы статику не кешируете, вы ее просто не проксируете :) А тут именно кеширование прилетевшего с бекенда контента, в том числе и динамического
      • 0
        Ок, теперь понятно, вещь хорошая.
        Главное что б злые админы не стали кэшить всю подряд динамику, которая кэшиться не должна.
        • 0
          не думаю, что в этом есть что-то плохое
          скорее важно, чтобы время жизни кеша было не 30 дней, например
    • 0
      Спасает когда на бекенде обычный SATA с картинкуами а на frontend кеш замонтирован на более быстрый диск/RAID-масив/tmpfs, в этом случае скорость отдачи возрастает в разы.
  • +1
    функция, описываемая в статье, актуальна только если за фронтендом(nginx) стоит какой-то бекенд (например, апач)?
    в моем случае nginx работает сам, без бекенда, а с пхп общается через fast-cgi
    могу ли я воспользоваться этим кешированием?
    • +1
      В рассылке был патч для добавления cache в fastcgi_module: www.lexa.ru/nginx-ru/msg23203.html
      • +1
        спасибо!
        после того, как написал свой коммент, понял, что задал весьма гуглябельный вопрос и нашел решение
        в любом случае, спасибо за быстрый ответ!
  • +1
    и через сколько времени вылетит ssd-диск?
  • 0
    а когда появится поддержка chunked encoding при неустановленной Content-Length для HTTP/1.1?
  • 0
    А про busy-lock что-нибудь известно?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Возможность блокировки одинаковых запросов.
        Например, у вас некоторая очень популярная, но тяжелая страница. Естественно, вы ее кешируете.
        Что произойдет, когда истечет время кеширования?
        Первый запрос на нее «провалится» в бекенд, но страница готовится долго, поэтому до того, как она будет сформирована, все остальные запросы тоже будут «проваливаться» в бекенд. Иными словами — в этот момент кеш у вас совершенно не работает! Как будто его вовсе нет. Ситуация усугубляется тем, что страница тяжелая, и получается, что у вас одновременно много потоков бекенда заняты генерацией этой самой страницы. Если используются запросы из базы, то получается, что они еще при этом друг другу мешают.
        Busy-lock позволяет недопустить такой ситуации.
        Первый запрос направляется в бекенд, одновременно ставится пометка, что такая-то страница уже генерится, поэтому все последующие запросы на нее задерживаются веб-сервером и ставятся в очередь. Как только страница сгенерирована, она кладется в кеш и отдается всем запросам.
        В итоге: тяжелая страница генерится только одним потоком, база разгружена. Все работает быстро.
        Более подробно мехнизм работы описан здесь: sysoev.ru/mod_accel/readme.html#busylocks

        Самое интересное, что эта штука уже 7 лет как есть в mod_accel, но в nginx ее до сих пор нет.
  • –1
    ждём ебилдов
  • –1
    в репозитории уже добавились? настоящий джедай — yum update :))
    • 0
      Мдя.

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