Продолжая тему, начатую мной в статьях «ORM – зло или Как я пытался кэшировать Propel в Symfony» и «Как я подружил «memcache» и Propel в Symfony» хочу рассказать о том, во что вылились мои попытки кэшировать модель данных.
Кратко о том, что было в предыдущих статьях….
Изначально на проекте, который я виду, использовался кэш представления (view). Но такой подход создавал для меня и коллег ряд неудобств:
Итак, мы решили кэшировать модель. Что для этого надо? Изучив на этот предмет классы генерируемые Propel, было решено использовать пул, находящийся в PEER классах. По замыслу разработчиков ORM этот пул хранит в себе созданные и уже находящиеся в базе (isNew == false) объекты. Propel добавляет объект в пул при их получении через методы doSelect/One/…. При этом проверяет на наличие объекта в том же пуле только при вызове метода retriveByPk. Исходя из этого, связи объектов по уникальным ключам могут тоже использовать кэш, если мы будем использовать методы retriveBy… (подробнее в предыдущих статьях)….
В ходе всех этих умозаключений был написан плагин sfPropelMemcachePlugin, который все это реализует, причем на мой взгляд довольно успешно:
Плагин на данный момент поддерживает кэширование с использованием первичных, уникальных и составных ключей.
Плагин пока еще бэтка, так что не судите строго.
Графики работы плагина на продакшене.
Закэшированны модель юзера, его профайл, страны, районы, города, фотки (+аватарки), папки фоток.
Сам плагин.
P.S. С радостью выслушаю конструктивную критику, предложения.
Кратко о том, что было в предыдущих статьях….
Изначально на проекте, который я виду, использовался кэш представления (view). Но такой подход создавал для меня и коллег ряд неудобств:
- сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.
- избыток данных в кэше: кэшируется html-результат, а не данные из базы. Больше данных, больше нагрузка, дольше грузится. Мелочь конечно. Но все же!
Итак, мы решили кэшировать модель. Что для этого надо? Изучив на этот предмет классы генерируемые Propel, было решено использовать пул, находящийся в PEER классах. По замыслу разработчиков ORM этот пул хранит в себе созданные и уже находящиеся в базе (isNew == false) объекты. Propel добавляет объект в пул при их получении через методы doSelect/One/…. При этом проверяет на наличие объекта в том же пуле только при вызове метода retriveByPk. Исходя из этого, связи объектов по уникальным ключам могут тоже использовать кэш, если мы будем использовать методы retriveBy… (подробнее в предыдущих статьях)….
В ходе всех этих умозаключений был написан плагин sfPropelMemcachePlugin, который все это реализует, причем на мой взгляд довольно успешно:
- Размер кэша уменьшился с 400 Мb(это максимум в настройках кэша) до 100mb.
- Нет путаницы с валидацией. Изменилась модель, изменился кэш. Шаблоны по большей части не закэшированы, легче верстать.
- Используются простые запросы в базу по большей части по первичному(или уникальному) ключу.
Плагин на данный момент поддерживает кэширование с использованием первичных, уникальных и составных ключей.
Плагин пока еще бэтка, так что не судите строго.
Графики работы плагина на продакшене.
Закэшированны модель юзера, его профайл, страны, районы, города, фотки (+аватарки), папки фоток.
Сам плагин.
P.S. С радостью выслушаю конструктивную критику, предложения.
