Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
Заранее передаю глубокие соболезнования пользователям, поместившим кеш на SSD-диск.
Есть уже диски и для кеша www.ixbt.com/storage/ssd-intel-x25m.shtml
Запись там не идёт так уж быстро, что бы заткнуть SSD накопитель. ОК, при старте может быть небольшой затык, но т.к. это в основном read-only и редкая запись нового файла на кеш — скорость отдачи будет очень хорошей.
А какие проблемы могут быть?
я так посмотрю, NGINX — смышленый парень, быстро всему учится в последнее время :)))
давно используем подобную схему, но через proxy_store. стоит ли перейти на новую схему?
Единственный минус текущей реализации — нельзя настраивать ключ кеша, он всегда будет как запрос. Из этого вытекает, что запросы вида site.org/disp?cat=1&page=1 и site.org/disp?page=1&cat=1 и будут разными.
Сегодня сделал кеширование thumb'ов в галерее (скрипт упорно делает их на лету) через proxy_cache — полет нормальный.
Сегодня сделал кеширование thumb'ов в галерее (скрипт упорно делает их на лету) через proxy_cache — полет нормальный.
Отличная новость.
Ждем появления в стабильной ветке.
Ждем появления в стабильной ветке.
Т.е. есть шанс, что Хабрахабр будет отдаваться мне заgzipованным через мою корпаративную проксю? Дома, напрямую, всё отдаётся нормально, а вот на работе, через сквид, Хабр отдаёт мне всё не gzipованное. (Настройки сквида правильные — остальные сайты отдаются нормально)
Сквид не умеет раззгзиповывать файлы из кеша. То есть в кеше лежит либо гзипованный файл — либо нет. Если лежит гзипованый а клиент не умеет принимать сжатых запросов (IE6 за проксей например) — сквид пойдет на сайт за новой версией контента и положит на диск уже несжатую версию.
Так что это не проблема сквида — nginx в подобной ситуации думается будет вести себя точно так же.
Так что это не проблема сквида — nginx в подобной ситуации думается будет вести себя точно так же.
Ещё бы он статику в memcached автоматически помещал…
В продакшн ещё конечно рано. Чисто потестировать. Работы там ещё очень много.
Как сказал Игорь в рассылке:
«Не знаю, кто что ждал, но я устал смотреть на то, что вытворяют
с proxy/fastcgi_store, memcached'ом и mod_accel'ем и выпустил то, что есть.»
Но в любом случае nginx идёт вперёд семимильными шагами. За что Игорю огромное спасибо.
Как сказал Игорь в рассылке:
«Не знаю, кто что ждал, но я устал смотреть на то, что вытворяют
с proxy/fastcgi_store, memcached'ом и mod_accel'ем и выпустил то, что есть.»
Но в любом случае nginx идёт вперёд семимильными шагами. За что Игорю огромное спасибо.
Я почему-то думал, что там есть уже кэш… Разве он и раньше что-то там не кэшировал?
Я, честно говоря, не понял о чем тут идет речь, но уверен в том, что Игорь сделал снова что-то хорошее.
Огромное ему спасибо от меня, как от руководителя портала, за то, что nginx есть и за то, что nginx есть у нас! До установки я и не думал, что он настолько полезен. Игорь, спасибо! И успехов!
Огромное ему спасибо от меня, как от руководителя портала, за то, что nginx есть и за то, что nginx есть у нас! До установки я и не думал, что он настолько полезен. Игорь, спасибо! И успехов!
alexxx.ru/tmp/nginx.gif чего ему мой логотипчик не понравился? :(
будет круче чем mod_accel?
2 apelsyn — а можете дописать в статью пример реальной ситуации, когда эта вещь спасает положение и как именно она это делает?
Просто не сразу понятно о каком кэшировании речь… мы nginx и так для кэширования (статики) используем уже много лет.
Просто не сразу понятно о каком кэшировании речь… мы nginx и так для кэширования (статики) используем уже много лет.
Вы статику не кешируете, вы ее просто не проксируете :) А тут именно кеширование прилетевшего с бекенда контента, в том числе и динамического
Спасает когда на бекенде обычный SATA с картинкуами а на frontend кеш замонтирован на более быстрый диск/RAID-масив/tmpfs, в этом случае скорость отдачи возрастает в разы.
функция, описываемая в статье, актуальна только если за фронтендом(nginx) стоит какой-то бекенд (например, апач)?
в моем случае nginx работает сам, без бекенда, а с пхп общается через fast-cgi
могу ли я воспользоваться этим кешированием?
в моем случае nginx работает сам, без бекенда, а с пхп общается через fast-cgi
могу ли я воспользоваться этим кешированием?
В рассылке был патч для добавления cache в fastcgi_module: www.lexa.ru/nginx-ru/msg23203.html
и через сколько времени вылетит ssd-диск?
а когда появится поддержка chunked encoding при неустановленной Content-Length для HTTP/1.1?
А про busy-lock что-нибудь известно?
Возможность блокировки одинаковых запросов.
Например, у вас некоторая очень популярная, но тяжелая страница. Естественно, вы ее кешируете.
Что произойдет, когда истечет время кеширования?
Первый запрос на нее «провалится» в бекенд, но страница готовится долго, поэтому до того, как она будет сформирована, все остальные запросы тоже будут «проваливаться» в бекенд. Иными словами — в этот момент кеш у вас совершенно не работает! Как будто его вовсе нет. Ситуация усугубляется тем, что страница тяжелая, и получается, что у вас одновременно много потоков бекенда заняты генерацией этой самой страницы. Если используются запросы из базы, то получается, что они еще при этом друг другу мешают.
Busy-lock позволяет недопустить такой ситуации.
Первый запрос направляется в бекенд, одновременно ставится пометка, что такая-то страница уже генерится, поэтому все последующие запросы на нее задерживаются веб-сервером и ставятся в очередь. Как только страница сгенерирована, она кладется в кеш и отдается всем запросам.
В итоге: тяжелая страница генерится только одним потоком, база разгружена. Все работает быстро.
Более подробно мехнизм работы описан здесь: sysoev.ru/mod_accel/readme.html#busylocks
Самое интересное, что эта штука уже 7 лет как есть в mod_accel, но в nginx ее до сих пор нет.
Например, у вас некоторая очень популярная, но тяжелая страница. Естественно, вы ее кешируете.
Что произойдет, когда истечет время кеширования?
Первый запрос на нее «провалится» в бекенд, но страница готовится долго, поэтому до того, как она будет сформирована, все остальные запросы тоже будут «проваливаться» в бекенд. Иными словами — в этот момент кеш у вас совершенно не работает! Как будто его вовсе нет. Ситуация усугубляется тем, что страница тяжелая, и получается, что у вас одновременно много потоков бекенда заняты генерацией этой самой страницы. Если используются запросы из базы, то получается, что они еще при этом друг другу мешают.
Busy-lock позволяет недопустить такой ситуации.
Первый запрос направляется в бекенд, одновременно ставится пометка, что такая-то страница уже генерится, поэтому все последующие запросы на нее задерживаются веб-сервером и ставятся в очередь. Как только страница сгенерирована, она кладется в кеш и отдается всем запросам.
В итоге: тяжелая страница генерится только одним потоком, база разгружена. Все работает быстро.
Более подробно мехнизм работы описан здесь: sysoev.ru/mod_accel/readme.html#busylocks
Самое интересное, что эта штука уже 7 лет как есть в mod_accel, но в nginx ее до сих пор нет.
ждём ебилдов
в репозитории уже добавились? настоящий джедай — yum update :))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NGINX научился кешировать проксированные запросы