Где лучшее место для размещения логики удаления кэша в приложении AppEngine? - PullRequest
Новая
       27

Где лучшее место для размещения логики удаления кэша в приложении AppEngine?

2 голосов
/ 21 августа 2009

Я написал приложение для Google AppEngine и хотел бы использовать API-интерфейс memcache для сокращения процессорного времени по запросу. Я профилировал приложение и обнаружил, что большая часть процессорного времени занимает рендеринг шаблонов и API-вызовы в хранилище данных, и после разговора с коллегой я подскочил (возможно, немного раньше?) К выводу, что кэширование Кусок визуализированного HTML страницы значительно сократит время процессора на запрос. Шаблон кеширования довольно прост, но вопрос , где поместить эту логику кеширования и удаления, для меня немного загадка.

Например, представьте, что на главной странице приложения есть раздел «Объявления». Этот раздел необходимо будет перерисовать после:

  • сначала прочитайте для всех в учетной записи,
  • добавляется новое объявление, и
  • старое объявление удаляется

Некоторые варианты размещения вызова метода evict_announcements_section_from_cache():

  • в методах .delete() модели объявления и .put()
  • в методе RequestHandler .post()
  • где-нибудь еще?

Затем на странице get RequestHandler я мог бы потенциально вызвать get_announcements_section(), который будет следовать стандартному шаблону memcache (проверить кеш, добавить в кеш при промахе, вернуть значение) и передать этот HTML-код в шаблон для этого фрагмента стр.

Это типичный шаблон проектирования для помещения логики высвобождения из кэша в модель, или в Controller / RequestHandler, или где-то еще? В идеале я бы хотел избежать изгнания логики с щупальцами по всему коду.

Ответы [ 2 ]

1 голос
/ 28 августа 2009

Пара альтернатив регулярному выселению:

  1. Очевидный: не выселять, а вместо этого установить таймер. Даже очень короткое - несколько секунд - может значительно сократить нагрузку на популярное приложение, даже если пользователи даже не заметят, что данные могут устареть на несколько секунд.
  2. Вместо исключения создайте ключ кэша на основе критериев, которые меняются при изменении данных. Например, если получение ключа самого последнего объявления дешево, вы можете использовать его как часть ключа кэшированных данных. Когда вы публикуете новое объявление, вы ищете ключ, который не существует, и в результате создаете новый.
1 голос
/ 22 августа 2009

У меня есть такой декоратор в проекте Github с открытым исходным кодом:

http://github.com/jamslevy/gae_memoize/tree/master

Это немного более подробно, учитывая такие вещи, как принудительное выполнение функции (когда вы хотите обновить кэш) или принудительное локальное кэширование ... это были только те вещи, которые мне были нужны в моем приложении, поэтому я выпек их в мой памятный декоратор.

...