Pull to refresh

Comments 47

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

Сегодня сделал кеширование thumb'ов в галерее (скрипт упорно делает их на лету) через proxy_cache — полет нормальный.
а разве результат в таком случае не должен быть одинаковым с точки зрения приложения?
от перестановки слагаемых сумма не меняется
С точки зрения приложения — одинаково, а вот кеш-модуль может думать иначе ;)
такое информацией не владею, строки-то по сути разные (значит и ключи).
Просветите, если несложно, зачем кеш-модулю так думать с оглядкой на кеширование в вебе.
Просто кеш будет забиваться одинаковой информацией, что не очень хорошо.
Отличная новость.
Ждем появления в стабильной ветке.
Т.е. есть шанс, что Хабрахабр будет отдаваться мне заgzipованным через мою корпаративную проксю? Дома, напрямую, всё отдаётся нормально, а вот на работе, через сквид, Хабр отдаёт мне всё не gzipованное. (Настройки сквида правильные — остальные сайты отдаются нормально)
Сквид не умеет раззгзиповывать файлы из кеша. То есть в кеше лежит либо гзипованный файл — либо нет. Если лежит гзипованый а клиент не умеет принимать сжатых запросов (IE6 за проксей например) — сквид пойдет на сайт за новой версией контента и положит на диск уже несжатую версию.
Так что это не проблема сквида — nginx в подобной ситуации думается будет вести себя точно так же.
UFO just landed and posted this here
При большой нагрузке использование дискового кеша в squid становится пыткой для пользователей, поэтому cache_mem побольше, а cache_dir в null, и всё хорошо.
Ещё бы он статику в memcached автоматически помещал…
Зачем туда статику?
Думаю, ее проще отдать с диска, а если не хватает диска, то смонтировать tmpfs.
tmpfs поможет только если файлы часто удаляются, иначе будет мешать.
Или вы думаете, что отдача с диска это физическое чтение с диска?
Не очень понял как это связано с удалением.
Для отдачи статики все нормальные веб-сервера используют sendfile — а уж откуда возьемет операционка этот файл — с диска ли прочтет или же из кеша в памяти — ее дело.
Я не понимаю, зачем для статики или кеша советуют tmpfs
В продакшн ещё конечно рано. Чисто потестировать. Работы там ещё очень много.
Как сказал Игорь в рассылке:
«Не знаю, кто что ждал, но я устал смотреть на то, что вытворяют
с proxy/fastcgi_store, memcached'ом и mod_accel'ем и выпустил то, что есть.»

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

Огромное ему спасибо от меня, как от руководителя портала, за то, что nginx есть и за то, что nginx есть у нас! До установки я и не думал, что он настолько полезен. Игорь, спасибо! И успехов!
Спасибо на хлеб не намажешь. Donate спасет отца русской технократии!
2 apelsyn — а можете дописать в статью пример реальной ситуации, когда эта вещь спасает положение и как именно она это делает?

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

Самое интересное, что эта штука уже 7 лет как есть в mod_accel, но в nginx ее до сих пор нет.
в репозитории уже добавились? настоящий джедай — yum update :))
Sign up to leave a comment.

Articles