Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
С трудом могу представить где может сильно выйграть мемкеш, за счёт уменьшения объёма данных в несколько раз
а мы и не говорим о сильном выиграше. Просто приятно когда объем кэша уменьшается с 400 мб до 100Мб.
как могут добавить проблем сложные шаблоны — вполне представляю
Согласен. Но в Symfony пока нет шаблонизатора. Все пишется в php. Некоторые партиалы/компоненты конечно приходится кэшировать. Тем не менее сопровождать проект стало легче. Ведь основной причиной перехода на кэширование модели была простота валидации данных.
>> сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.
Не могли бы пояснить пример? Я просто возможно не понимаю проблему. Не проще создать класс-наблюдатель за кешем моделей. При обновлении записи в какой то модели сбрасивать её специфический кеш на view (что успешно реализовано на симфони не раз)?
Не могли бы пояснить пример? Я просто возможно не понимаю проблему. Не проще создать класс-наблюдатель за кешем моделей. При обновлении записи в какой то модели сбрасивать её специфический кеш на view (что успешно реализовано на симфони не раз)?
Написал не туда. Ответ.
> что успешно реализовано на симфони не раз
подскажите какой плагин это делает?
подскажите какой плагин это делает?
Плагина пока нет, я вот хочу взять этот кусок проекта и оформить в плагин. Написан он понятное дело на основе Behavior (Propel)
www.symfony-project.org/cookbook/1_2/en/behaviors
www.symfony-project.org/cookbook/1_2/en/behaviors
Изначально было так и реализовано, только без наблюдателя. В самой модели писался метод cleanCache, который и отвечал за чистку кэша view.
Постараюсь объяснить на примере.
Возьмем к примеру пользователя. У нас есть модель его самого, модель аватарки, картинок, профайла и т.д. и 10 разных блоков с этими данными в разных комбинациях. Пользователь сменил пол и мне надо сбросить во всех 10 блоках кэш, сменил город — в 8, аватарку — 5 и т.д. Добавили еще блок, бежим по всем классам, меняем метод cleanCache. Дизайн поменялся, опять меняем методы чистки кэша. К тому же на сайте не только юзер ;)
Да можно сделать наблюдателя, попытать упростить все это дело. Но зачем?
Понимаете, мы изменили подход. В шаблон приходят данные уже из кэша. Мне не надо думать о связях. О валидации. Модель все сделает за меня.
Постараюсь объяснить на примере.
Возьмем к примеру пользователя. У нас есть модель его самого, модель аватарки, картинок, профайла и т.д. и 10 разных блоков с этими данными в разных комбинациях. Пользователь сменил пол и мне надо сбросить во всех 10 блоках кэш, сменил город — в 8, аватарку — 5 и т.д. Добавили еще блок, бежим по всем классам, меняем метод cleanCache. Дизайн поменялся, опять меняем методы чистки кэша. К тому же на сайте не только юзер ;)
Да можно сделать наблюдателя, попытать упростить все это дело. Но зачем?
Понимаете, мы изменили подход. В шаблон приходят данные уже из кэша. Мне не надо думать о связях. О валидации. Модель все сделает за меня.
>>и 10 разных блоков с этими данными в разных комбинациях. Пользователь сменил пол и мне надо сбросить во всех 10 блоках кэш, сменил город — в 8, аватарку — 5 и т.д. Добавили еще блок, бежим по всем классам, меняем метод cleanCache.
Зачем так жестко. Разбейте просто на паршал кеш ваши вьюшки (или через partial или через cache do). И чистите только при обновлении аватарки паршал аватарки.
Зачем так жестко. Разбейте просто на паршал кеш ваши вьюшки (или через partial или через cache do). И чистите только при обновлении аватарки паршал аватарки.
Судя по вашей статье, вы слабовато разбираетесь в кешировании.
> сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.
Решение элементарно, для каждого кешируемого кусочка данных, зависящего от состояния БД, вводим зависисмость и проверяем, не обновилась ли таблица или что там еще.
> избыток данных в кэше: кэшируется html-результат, а не данные из базы. Больше данных, больше нагрузка, дольше грузится. Мелочь конечно. Но все же!
Время работы шаблонизатора может легко составлять половину работы скрипта, а то и больше. С кешированием моделей — тяжелый шаблонизатор (и еще куча всяких модулей, которые будут загржужаться) будет по прежнему вызываться.
И вообще, кешировать данные. которые выбираются по индексу (например профиль юзера), не всегда эффективно — для хранения больших объемов данных БД подходит лучше.
p.s. Сделайте, чтобы все запросы к БД использвоали индекс (и предпочтительно не использовали limit) — может кеш окажется не так и нужен.
> сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.
Решение элементарно, для каждого кешируемого кусочка данных, зависящего от состояния БД, вводим зависисмость и проверяем, не обновилась ли таблица или что там еще.
> избыток данных в кэше: кэшируется html-результат, а не данные из базы. Больше данных, больше нагрузка, дольше грузится. Мелочь конечно. Но все же!
Время работы шаблонизатора может легко составлять половину работы скрипта, а то и больше. С кешированием моделей — тяжелый шаблонизатор (и еще куча всяких модулей, которые будут загржужаться) будет по прежнему вызываться.
И вообще, кешировать данные. которые выбираются по индексу (например профиль юзера), не всегда эффективно — для хранения больших объемов данных БД подходит лучше.
p.s. Сделайте, чтобы все запросы к БД использвоали индекс (и предпочтительно не использовали limit) — может кеш окажется не так и нужен.
слабовато разбираетесь в кэшировании
Знаете, эта фраза поставила меня в тупик. Объясню почему — цикл моих статей не о том, в чем я слабо разбираюсь или не разбираюсь. Они, если вы посмотрите еще раз повнимательнее — о том, как я разобрался с насущными задачами
Цель была поставлена при решении рабочей задачи, а спортивного вопроса — разбираюсь или нет — не стояло вообще.
Общие фразы вашего комментария отнюдь не свидетельствуют о том, что вы разбираетесь в этом больше…
Странно. Если разбираетесь — напишите как и в чем в отдельном посте. Понимаю, что клеить ярлык проще…
Предложите решение лучше — с удовольствием почитаю и приму на вооружение!
За «ярлык» извиняюсь, погорячился ((
Вот вам тогда например идея по поводу массового удаления записей: допустим, у нас есть кеш с кучей записей для разных юзеров, и допустим, при обновлении таблицы users нам надо его сбросить целиком. Вместо того, чтобы удалять в цикле, или еще как-то кучу ключей, просто создаем в кеше параметр users_table_update_time, при каждом изменении таблицы пишем в него время последнего обновления таблицы, соответсвенно, при чтении можно его проверять, и если время записи какой-то информации меньше этого времени, она устарела :)
В частности, ваш многострадальный кеш view, от которого вы отказались: допустим, профиль пользователя зависит от таблиц users, photos и wall. Проверяя дату модификации закешированного профиля, и сравнивая с временем последнего обновления указанных 3 таблиц, можно легко проверить, актуальна ли закешированная версия, при этом не надо при обновлениях что-то очищать и удалять.
Эту проверку, можно проводить на раннем этапе обработки запроса, и в случае нахождения кешированной версии страницы, не загружать в память тяжелые модели, шаблонизатор, хелперы и еще кучу компонент.
Вот вам тогда например идея по поводу массового удаления записей: допустим, у нас есть кеш с кучей записей для разных юзеров, и допустим, при обновлении таблицы users нам надо его сбросить целиком. Вместо того, чтобы удалять в цикле, или еще как-то кучу ключей, просто создаем в кеше параметр users_table_update_time, при каждом изменении таблицы пишем в него время последнего обновления таблицы, соответсвенно, при чтении можно его проверять, и если время записи какой-то информации меньше этого времени, она устарела :)
В частности, ваш многострадальный кеш view, от которого вы отказались: допустим, профиль пользователя зависит от таблиц users, photos и wall. Проверяя дату модификации закешированного профиля, и сравнивая с временем последнего обновления указанных 3 таблиц, можно легко проверить, актуальна ли закешированная версия, при этом не надо при обновлениях что-то очищать и удалять.
Эту проверку, можно проводить на раннем этапе обработки запроса, и в случае нахождения кешированной версии страницы, не загружать в память тяжелые модели, шаблонизатор, хелперы и еще кучу компонент.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Плагин sfPropelMemcachePlugin