Cache в Ruby on Rails

Добрый день. Оптимизирую сейчас один проект, в связи с увеличенной нагрузкой. В связи с этим, изучаю различные метода кеша в рельсах, и не только. И у меня возникли некоторые вопросы.

В Rails 3 было три вида кеша — page, action и fragment. Page — самый быстрый — генерируем html и отдаем каким-то nginx'ом. Но, наименее гибкий.
В Rails 4 отменили первых два, допилили и оставили только fragment. Я думаю, приняли такое решение умные дядьки, и у них были свои причины.

Вот и хотелось узнать, насколько fragment сache медленней по скорости, в сравнении с page? Что-то я не нашел сравнений.

Ну и самый главный вопрос: допустим у нас остался только fragment cache (а так и есть в Rails 4). Он кеширует view, но, как подсказывает здравый смысл, нужно кешировать запросы в БД (поскольку они сильнее всего грузят сервер), а перегнать из erb в html — относительно быстрая операция. Получается, чтобы закешировать запросы в БД, их нужно перенести в view, внутри cache do end блока?

Было:

<% @articles.each do %>
  тут разметка
<% end %> 

Стало:

<% cache do %>
  <% Article.find_each do %>
  тут разметка
  <% end %>
<% end %>


Заметили, как логика перешла из контроллера в view?

Или я что-то неправильно понял, и здесь задествована магия, которая кеширует запросы в БД тоже, или с этим нужно мирится (ну или переносить методы в хелперы, которые возвращали бы модели из БД).

Подскажите, пожалуйста. Любая информация по кешированию в рельсах будет полезной.
  • Вопрос задан
  • 5077 просмотров
Пригласить эксперта
Ответы на вопрос 5
@Kukunin Автор вопроса
Кстати, как ответ самому себе, нельзя не упомянуть гем rack-mini-profiler, который очень наглядно покажет узкие места в приложении, которые нужно оптимизировать
Ответ написан
@alex_bel
fragment сache в принципе медленней page по той причине, что с page рельсовый сервер даже не дергается. Работает только web server. Это супер быстрый ответ, но и наименее гибкий как Вы правильно сказали.

Рельсы кешируют все запросы к БД.
@articles = Article.where(...)
т.е. тут при повторном обращении результат этого запроса возьмут из кеша.
Ответ написан
Zelgadis
@Zelgadis
Не знаю как у вас, но у меня запрос к базе делается ~2ms, а вьюха рендерится ~20-40ms (haml), c кэшем страничка рендерится за ~2 ms (запрос к базе и сразу же возвращается html).

А alex_bel прав — запросы к базе кэшируются.
Ответ написан
Комментировать
@Kukunin Автор вопроса
Кстати, еще как ответ самому себе, если у нас в action написано что-то типа:

@articles = Article.where("active = ?", true)

а во view

<%= render @articles %>

то запрос выполнится во вьюхе. Т.е. @articles — это scope объект, который выполняется тогда, когда идет обращение к данным. Однако методы count и all выполнят запрос сразу здесь и сейчас.
Ответ написан
Комментировать
@Adil1
http://habrahabr.ru/post/165355/ c этим не ознакамливались? :) по мне очень полезная инфа
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы