Comments 13
Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей. По сути половину статьи можно было опустить Лару и просто рассказать про механизмы/практику кэширования. Если не ошибаюсь в PHP любые экземпляры классов можно кэшировать, проблемы лишь с ресурсами(открытые файл, соединения), что опять же решается через __sleep() and __wakeup().
Допустим, в Yii из коробки более интересные вещи есть, так, я не хочу кэшировать сами экземпляры (состояния моделей), а вот сам запрос к БД хочу закэшировать. Зависимости кэша тоже очень даже вкусная вещь, а тут выходит велосипедировать каждый раз с событиями? Я не противник событий) просто как по мне как-то громоздко выходит
Допустим, в Yii из коробки более интересные вещи есть, так, я не хочу кэшировать сами экземпляры (состояния моделей), а вот сам запрос к БД хочу закэшировать. Зависимости кэша тоже очень даже вкусная вещь, а тут выходит велосипедировать каждый раз с событиями? Я не противник событий) просто как по мне как-то громоздко выходит
Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей.Так основы же :)
Зависимости — хорошая идея, но часто просто просаживается по перформансу. Какой смысл лезть в базу, проверять когда обновилась сущность, если мы и сделали все кеширование ради того, чтобы как можно меньше трогать базу. А события — совсем не громоздко. Очень удобно и естественным языком описываются действия:
PostSaved::class => [ClearPostCache::class,Зависимости — хорошая идея, но часто просто просаживается по перформансу. Какой смысл лезть в базу, проверять когда обновилась сущность, если мы и сделали все кеширование ради того, чтобы как можно меньше трогать базу.
Так ведь запросы бывают разные) из пальца: показываем огромную таблицу, которая строится на основе сложного запроса с джойнами, агрегатными функциями и т.д. это все по нескольким миллионам записям… При этом у нас есть простой индекс на поле update_at, почему бы и не следить за max(update_at)?)
Вероятно, у меня уже некоторая деформация. Мне в разы проще сбросить этот кеш при обновлении(том, которое этот updated_at поменяет).
Все эти попытки красиво навесить зависимости лично мне говорят о том, что разработчики не контролируют свой код. Где-то как-то кто-то может обновить данные, не озаботившись при этом генерацией нормального события. Причем именно бизнес-события, как PostPublished или UserBanned. Потом пытаются вернуть контроль за изменениями на своем проекте такими вот хитрыми зависимостями на max(updated_at).
А отстутствие контроля за изменениями обычно влечет за собой более серьезные проблемы, чем несбросившийся кеш.
Все эти попытки красиво навесить зависимости лично мне говорят о том, что разработчики не контролируют свой код. Где-то как-то кто-то может обновить данные, не озаботившись при этом генерацией нормального события. Причем именно бизнес-события, как PostPublished или UserBanned. Потом пытаются вернуть контроль за изменениями на своем проекте такими вот хитрыми зависимостями на max(updated_at).
А отстутствие контроля за изменениями обычно влечет за собой более серьезные проблемы, чем несбросившийся кеш.
Может вы и правы… но что-то сильно привязались к теме замены одного запроса на другой, ведь там есть разные механизмы зависимостей в том числе можно построить на своей какой-то логике, просто мне сама идея очень симпатична, что добавляется небольшой слой со своей логикой кэширования, а тут как-то все топорно… я сам за простоту, но как-то ждал более интересные решения)
это все по нескольким миллионам записям… При этом у нас есть простой индекс на поле update_at
Подозреваю что идея чисто теоретическая. Столкнулся я как-то с таблицей с подобной архитектурой.
Честно говоря, в этом кейсе нет смысла вообще использовать кеш — у Вас основная просадка по времени будет на пересчете этого индекса. А если данные чаще читаются, чем изменяются — то лучше все же делать инвалидацию при редком изменении, чем проверку при частом чтении.
Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей.
Ощущение скудносватости пройдет, если подумать о том что «из коробки более интересные вещи» — это по сути тот же кеш одного или нескольких экземпляров класса. Только в зависимости от враппера меняется класс — либо модель AR, либо кусок/полная вьюха, и т.д.
я не хочу кэшировать сами экземпляры (состояния моделей), а вот сам запрос к БД хочу закэшировать.Ну в том же мускуле есть гораздо более эффективный встроенный кеш. Еще и про инвалидацию думать не придется.
Очень хотелось бы следующих статей по кэшированию в Laravel — продолжения так сказать) от новичка до профи
Простите за офтоп, но мне ак неофиту в php & laravel нужен совет, возможно решить мою проблему кешированием или как то по другому.
Есть самодельная Learning Management System очень скудного функционала под 200-300
пользователей.
Но вот проблема, чтобы в топбаре показать уведомления, непрочитанные внутренние сообщения, прогресс обучения и онлайн обучающихся, я загнал все это в ViewComposer и в результате получилось 90!!! запросов к бд при каждом запросе страниц. Вот вывод из debugbar bit.ly/32JR86a.
Как решаются такие вопросы? Ведь вывод всей этой информации — типовая задача для многих проектов, а я велосипед изобретаю с квадратными колесами.
Есть самодельная Learning Management System очень скудного функционала под 200-300
пользователей.
Но вот проблема, чтобы в топбаре показать уведомления, непрочитанные внутренние сообщения, прогресс обучения и онлайн обучающихся, я загнал все это в ViewComposer и в результате получилось 90!!! запросов к бд при каждом запросе страниц. Вот вывод из debugbar bit.ly/32JR86a.
Как решаются такие вопросы? Ведь вывод всей этой информации — типовая задача для многих проектов, а я велосипед изобретаю с квадратными колесами.
Хороший пример и за дебагбар спасибо. Тут целую статью можно написать про то, как организовать тут кеш. Я попробую что-нибудь сообразить в ближайшее время.
Оформил вопросом на stackoverflow, там добавил код класса Composer, в котором все это все вызывается.
Sign up to leave a comment.
Кеширование в Laravel: основы плюс tips&tricks