Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Вообще, вложенные cache инструкции это жесть, ну их в баню. Уже вот целый gem соорудили для их поддержки.
Джем cache_digests — это backport новой функциональности для rails 3, в четвертых рельсах он не нужен.
Тем не менее:) Вообще, немного печалит, что рельсы теряют простоту.
Рельсы — простоту? Да там сплошная магия! Я когда первый раз их увидел, чувствовал себя как летчик с известной картинки. Но именно эта фича, на мой взгляд, как раз все упрощает. Во первых, теперь нету page and action caching, а во вторых вам придется писать меньше кода, чтобы добиться того самого результата. А то, что оно там сложнее внутри — кого это волнует, главное ведь интерфейс а не имплементация.
fragment caching ни разу не заменяет page/action caching.
page/action caching извлекли из рельс, потому что это узкий функционал. К примеру, если у вас есть регистрация на сайте — page caching вам уже не подходит.
Но эти виды кэширования никуда не делись, просто вынесены в отдельный гем.
Но эти виды кэширования никуда не делись, просто вынесены в отдельный гем.
К примеру, если у вас есть регистрация на сайте — page caching вам уже не подходит.
Всё зависит от того насколько сильно меняется страница для авторизованного пользователя. В не слишком навороченных сайтах вполне можно использовать page caching вместе с авторизацией… Вывести в шапку «Привет, %username%» и несколько элементов управления можно и отдельным ajax-запросом.
Вот это как раз и бесило. Получается, что все, что должно поменяться при каком-то действии естественным образом, теперь всенепременно надо подгружать через ajax — причем тысячи их — таких мест.
Ну если тысячи, то нет особой выгоды, чтобы с этим возиться… а если десятки, то почему бы и нет?
Сайты ведь разные бывают. Тем более если упирать на естественный для веб образ появления изменений путём полной перезагрузки страницы, то можно дойти до того, что ajax — неправильный способ работы с веб-сервером, т.к. неестественный. Но Вы ведь так не считаете?
Сайты ведь разные бывают. Тем более если упирать на естественный для веб образ появления изменений путём полной перезагрузки страницы, то можно дойти до того, что ajax — неправильный способ работы с веб-сервером, т.к. неестественный. Но Вы ведь так не считаете?
Действительно, my bad.
Да не, имплементация тоже важна. Рельсы кайф, с удовольствием с ними работаю, но все хорошо до тех пор, пока ты остаешься «на рельсах». Шаг влево/вправо конечно не расстрел, но может вызвать определенные сложности:) Причем чем дальше платформа развивается, тем больше ее затягивает в это болото, хотя это в принципе закономерно.
А вы как-то иначе кешируете в Rails?
Как иначе?
Как вы кешируете в rails кроме caches инструкций?
> Вообще, вложенные cache инструкции это жесть
Я стараюсь избегать вложений cache внутри cache внутри cache
Я стараюсь избегать вложений cache внутри cache внутри cache
Почему?
Какая разница где находится объект, если за кешем depedencies в любом случае приходится следить?
Или используя caches pages вы не использует cahes fragment?
Какая разница где находится объект, если за кешем depedencies в любом случае приходится следить?
Или используя caches pages вы не использует cahes fragment?
Не уверен, что понимаю в чем вопрос.
Вообще, я в основном использую кеширование фрагментов, а вот кеширование страниц/экшенов наоборот использую достаточно редко. Когда кешируется фрагмент внутри которого кешируется фрагмент внутри которого кешируется фрагмент, жить бывает грустно. Приходится следить — да, весь вопрос в том насколько это трудоемко.
Вообще, я в основном использую кеширование фрагментов, а вот кеширование страниц/экшенов наоборот использую достаточно редко. Когда кешируется фрагмент внутри которого кешируется фрагмент внутри которого кешируется фрагмент, жить бывает грустно. Приходится следить — да, весь вопрос в том насколько это трудоемко.
В идеальном случае у фрагмента есть CRUD, observer легко справится с задачей контроля актуальности фрагментов объекта. На моей практике было примерно 146(2 на самом деле) случаев когда приходилось кешировать фрагмент внутри фрагмента, это были системы документооборота, когда информационные блоки по контрагентам каждый раз вычислять было излишне трудоемко.
Я вот чего не понимаю — Ryan говорит, что проблему с изменением view «обычно обходят путем обновления версии ключа кэша». Но разве не проще просто удалить папку с кэшем? У многих даже специальный rake-task есть.
А если кэш в memcached? Удалять каждый ключик?
Разве это нельзя сделать используя expire_fragment с регекспом?
Memcached используется на production и на staging. На dev ставить memcached, как мне кажется не очень эффективно, ибо ошибок с кэшированием в процессе разработки может быть очень много и memcached будет только мешать. Ну а продакшину такие операции не нужны… наверное… хочется верить :)
Не нужны? Т.е. вы поменяли шаблон, но пускай в продакшене отдаётся старый из кэша?
Ну тут все от стратегии зависит.
Во первых, ничего не мешает в :namespace подставлять номер релиза или timestamp. С другой, после каждого деплоя придется пересобирать весь кеш и деплой будет сильно заметен для пользователей. Опять же кэш умрет через 15 минут, если другое не определено. На больших нагрузках к релизу подходят ответственно и 15 минут ожидания подтверждения успешности деплоя не должны нанести вред.
Во второых, в memcached хранят состояния объектов, а не фрагменты отрендеренного html кода. Хранить фрагменты — никакой памяти не хватит :)
Интересный вопрос, я с этой стороны на memcached еще не смотрел.
Во первых, ничего не мешает в :namespace подставлять номер релиза или timestamp. С другой, после каждого деплоя придется пересобирать весь кеш и деплой будет сильно заметен для пользователей. Опять же кэш умрет через 15 минут, если другое не определено. На больших нагрузках к релизу подходят ответственно и 15 минут ожидания подтверждения успешности деплоя не должны нанести вред.
Во второых, в memcached хранят состояния объектов, а не фрагменты отрендеренного html кода. Хранить фрагменты — никакой памяти не хватит :)
Интересный вопрос, я с этой стороны на memcached еще не смотрел.
Как вариант префиксы ключей менять. Ну и чтобы не копить старье, прописывать время жизни для ключей не равное нулю
Dalli умеет сбрасывать кэш целиком.
вот будет на вашем бложике пару млн посетителей в день, тогда подумаете зачем добавлять версию и почему нельзя сбросить кэш
Кэш обычно хранят не на диске, а в памяти. К примеру, memcached сам подчищает кэш, к которому давно не было обращений.
Кэш, обычно, хранят где угодно.
guides.rubyonrails.org/caching_with_rails.html#cache-stores
Я насчитал 6 методов определения cache_store, они все в памяти? Вовсе нет.
Что я читаю не так?
Я насчитал 6 методов определения cache_store, они все в памяти? Вовсе нет.
Page caches are always stored on disk.
Rails provides different stores for the cached data created by action and fragment caches.
Что я читаю не так?
Из тех, что идут в поставке, не в оперативной памяти хранит кеш только file_store, если не считать null_store, который его вообще не хранит. Вы можете написать кастомный cache_store и хранить кеш «где угодно». Но UseRifle совершенно прав, обычно кеш хранят в оперативной памяти, по тривиальной причине — обращение к оперативной памяти в разы быстрее, чем чтение файла.
партиал — интересное слово))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тонкости Rails 4 — Cache Digests