Pull to refresh

Comments 14

UFO just landed and posted this here
С трудом могу представить где может сильно выйграть мемкеш, за счёт уменьшения объёма данных в несколько раз

а мы и не говорим о сильном выиграше. Просто приятно когда объем кэша уменьшается с 400 мб до 100Мб.

как могут добавить проблем сложные шаблоны — вполне представляю

Согласен. Но в Symfony пока нет шаблонизатора. Все пишется в php. Некоторые партиалы/компоненты конечно приходится кэшировать. Тем не менее сопровождать проект стало легче. Ведь основной причиной перехода на кэширование модели была простота валидации данных.
>> сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.

Не могли бы пояснить пример? Я просто возможно не понимаю проблему. Не проще создать класс-наблюдатель за кешем моделей. При обновлении записи в какой то модели сбрасивать её специфический кеш на view (что успешно реализовано на симфони не раз)?
> что успешно реализовано на симфони не раз

подскажите какой плагин это делает?
полезный плагин будет :)
Изначально было так и реализовано, только без наблюдателя. В самой модели писался метод cleanCache, который и отвечал за чистку кэша view.

Постараюсь объяснить на примере.
Возьмем к примеру пользователя. У нас есть модель его самого, модель аватарки, картинок, профайла и т.д. и 10 разных блоков с этими данными в разных комбинациях. Пользователь сменил пол и мне надо сбросить во всех 10 блоках кэш, сменил город — в 8, аватарку — 5 и т.д. Добавили еще блок, бежим по всем классам, меняем метод cleanCache. Дизайн поменялся, опять меняем методы чистки кэша. К тому же на сайте не только юзер ;)

Да можно сделать наблюдателя, попытать упростить все это дело. Но зачем?

Понимаете, мы изменили подход. В шаблон приходят данные уже из кэша. Мне не надо думать о связях. О валидации. Модель все сделает за меня.
>>и 10 разных блоков с этими данными в разных комбинациях. Пользователь сменил пол и мне надо сбросить во всех 10 блоках кэш, сменил город — в 8, аватарку — 5 и т.д. Добавили еще блок, бежим по всем классам, меняем метод cleanCache.

Зачем так жестко. Разбейте просто на паршал кеш ваши вьюшки (или через partial или через cache do). И чистите только при обновлении аватарки паршал аватарки.
Судя по вашей статье, вы слабовато разбираетесь в кешировании.

> сложность валидации данных: при записи в базу, приходилось сбрасывать данные у различных связанных блоков, из-за этой путаницы часто возникали ошибки.

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

> избыток данных в кэше: кэшируется html-результат, а не данные из базы. Больше данных, больше нагрузка, дольше грузится. Мелочь конечно. Но все же!

Время работы шаблонизатора может легко составлять половину работы скрипта, а то и больше. С кешированием моделей — тяжелый шаблонизатор (и еще куча всяких модулей, которые будут загржужаться) будет по прежнему вызываться.

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

p.s. Сделайте, чтобы все запросы к БД использвоали индекс (и предпочтительно не использовали limit) — может кеш окажется не так и нужен.
слабовато разбираетесь в кэшировании

Знаете, эта фраза поставила меня в тупик. Объясню почему — цикл моих статей не о том, в чем я слабо разбираюсь или не разбираюсь. Они, если вы посмотрите еще раз повнимательнее — о том, как я разобрался с насущными задачами

Цель была поставлена при решении рабочей задачи, а спортивного вопроса — разбираюсь или нет — не стояло вообще.

Общие фразы вашего комментария отнюдь не свидетельствуют о том, что вы разбираетесь в этом больше…

Странно. Если разбираетесь — напишите как и в чем в отдельном посте. Понимаю, что клеить ярлык проще…

Предложите решение лучше — с удовольствием почитаю и приму на вооружение!
За «ярлык» извиняюсь, погорячился ((

Вот вам тогда например идея по поводу массового удаления записей: допустим, у нас есть кеш с кучей записей для разных юзеров, и допустим, при обновлении таблицы users нам надо его сбросить целиком. Вместо того, чтобы удалять в цикле, или еще как-то кучу ключей, просто создаем в кеше параметр users_table_update_time, при каждом изменении таблицы пишем в него время последнего обновления таблицы, соответсвенно, при чтении можно его проверять, и если время записи какой-то информации меньше этого времени, она устарела :)

В частности, ваш многострадальный кеш view, от которого вы отказались: допустим, профиль пользователя зависит от таблиц users, photos и wall. Проверяя дату модификации закешированного профиля, и сравнивая с временем последнего обновления указанных 3 таблиц, можно легко проверить, актуальна ли закешированная версия, при этом не надо при обновлениях что-то очищать и удалять.

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

p.s. Вот только не знаю в знак благодарности минусовать вас или плюсовать :)
Ну у меня по моему такой уровень кармы, что ему уже все равно, плюсуют его или минусуют :) Как и мне.
Only those users with full accounts are able to leave comments. Log in, please.

Articles