Как сохранить кэши теплыми с помощью кэширования «Русская кукла»?

Я экспериментировал с кэшированием фрагментов Russian Doll в приложении Rails, а точнее на его главной странице Dashboard. Это первая страница, которую видит пользователь после входа в систему, и она является отличным кандидатом на роль матрешки, так как содержит множество вложенных элементов.

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

Однако бывают ситуации, когда данные изменяются системой. Например, каждую ночь мы обновляем все значения по новому курсу за предыдущий день. Это автоматически истечет срок действия большинства фрагментов на панели инструментов, и на следующее утро пользователь столкнется с холодным кешем при входе в систему.

Можно ли регенерировать эти кэши фрагментов после обновления системы, чтобы они оставались теплыми? Я думаю, я мог бы вручную write фрагменты после любого обновления системы, но мне также пришлось бы вручную управлять ключами и зависимостями. (В настоящее время я использую гем cache_digest, что очень удобно.).

Есть идеи?


ruby-on-rails fragment-caching russian-doll-caching
person Luciano    schedule 30.04.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Если это вариант для вас, вы можете включить все данные, необходимые для расчетов, в атрибуты данных, а затем преобразовать их в текст с помощью Javascript.

Таким образом, ваш необработанный вывод может быть:

<li data-gbp-amount="2.50"></li>

Затем вы приходите вместе с JS и делаете что-то вроде:

$(document).find("[data-gbp-amount]").each(index, el) ->
  $(el).text($(el).data("gbp-amount") * todaysExchangeRate)

Таким образом, все, что выводит Rails, будет кэшироваться и не изменится в зависимости от обменного курса.

person RobHeaton    schedule 30.04.2013
comment
Это, безусловно, работает для более мелких элементов. Я считаю, что DHH делает что-то подобное в своем исходном посте. Однако в нашем случае изменения могут быть связаны с более сложными расчетами (не только обменными курсами) и могут быть включены или удалены целые фрагменты. Я думаю, это все еще можно сделать, но мне придется перенести слишком много логики в JS. - person Luciano; 30.04.2013

arrow_upward
0
arrow_downward

Все зависит от cache_key. cache_key основан на идентификаторе модели, атрибуте updated_at и на md5 из шаблона html. Итак, если вы измените один из этих 3 ключей, срок действия кеша истек.

Я не знаю, насколько сложны ваши данные, но вы можете просто использовать сенсорный метод в своей основной модели AR::, чтобы изменить ключ кеша. Возможно, у вас есть основная модель AR::, в которой другие записи являются зависимыми.

person Rinaldi Fonseca    schedule 03.05.2013
comment
Спасибо Ринальди. Прикосновение к объекту фактически истечет срок действия кеша, поэтому пользователь попадет в холодный кеш при следующем доступе. На самом деле я пытался сделать это, но также оставил новый кеш готовым, чтобы пользователь вместо этого нажал его. - person Luciano; 03.05.2013