Кеширование в Laravel: основы плюс tips&tricks

[@Arik]

Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей. По сути половину статьи можно было опустить Лару и просто рассказать про механизмы/практику кэширования. Если не ошибаюсь в PHP любые экземпляры классов можно кэшировать, проблемы лишь с ресурсами(открытые файл, соединения), что опять же решается через __sleep() and __wakeup().

Допустим, в Yii из коробки более интересные вещи есть, так, я не хочу кэшировать сами экземпляры (состояния моделей), а вот сам запрос к БД хочу закэшировать. Зависимости кэша тоже очень даже вкусная вещь, а тут выходит велосипедировать каждый раз с событиями? Я не противник событий) просто как по мне как-то громоздко выходит

[@Adelf]

Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей.

Так основы же :)

Зависимости — хорошая идея, но часто просто просаживается по перформансу. Какой смысл лезть в базу, проверять когда обновилась сущность, если мы и сделали все кеширование ради того, чтобы как можно меньше трогать базу. А события — совсем не громоздко. Очень удобно и естественным языком описываются действия:

PostSaved::class => [ClearPostCache::class,

[@Arik]

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

Так ведь запросы бывают разные) из пальца: показываем огромную таблицу, которая строится на основе сложного запроса с джойнами, агрегатными функциями и т.д. это все по нескольким миллионам записям… При этом у нас есть простой индекс на поле update_at, почему бы и не следить за max(update_at)?)

[@Adelf]

Вероятно, у меня уже некоторая деформация. Мне в разы проще сбросить этот кеш при обновлении(том, которое этот updated_at поменяет).
Все эти попытки красиво навесить зависимости лично мне говорят о том, что разработчики не контролируют свой код. Где-то как-то кто-то может обновить данные, не озаботившись при этом генерацией нормального события. Причем именно бизнес-события, как PostPublished или UserBanned. Потом пытаются вернуть контроль за изменениями на своем проекте такими вот хитрыми зависимостями на max(updated_at).
А отстутствие контроля за изменениями обычно влечет за собой более серьезные проблемы, чем несбросившийся кеш.

[@Arik]

Может вы и правы… но что-то сильно привязались к теме замены одного запроса на другой, ведь там есть разные механизмы зависимостей в том числе можно построить на своей какой-то логике, просто мне сама идея очень симпатична, что добавляется небольшой слой со своей логикой кэширования, а тут как-то все топорно… я сам за простоту, но как-то ждал более интересные решения)

[@Nemutaisama]

это все по нескольким миллионам записям… При этом у нас есть простой индекс на поле update_at

Подозреваю что идея чисто теоретическая. Столкнулся я как-то с таблицей с подобной архитектурой.
Честно говоря, в этом кейсе нет смысла вообще использовать кеш — у Вас основная просадка по времени будет на пересчете этого индекса. А если данные чаще читаются, чем изменяются — то лучше все же делать инвалидацию при редком изменении, чем проверку при частом чтении.

[@Nemutaisama]

Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей.

Ощущение скудносватости пройдет, если подумать о том что «из коробки более интересные вещи» — это по сути тот же кеш одного или нескольких экземпляров класса. Только в зависимости от враппера меняется класс — либо модель AR, либо кусок/полная вьюха, и т.д.

я не хочу кэшировать сами экземпляры (состояния моделей), а вот сам запрос к БД хочу закэшировать.

Ну в том же мускуле есть гораздо более эффективный встроенный кеш. Еще и про инвалидацию думать не придется.

[@AndreMareg]

Очень хотелось бы следующих статей по кэшированию в Laravel — продолжения так сказать) от новичка до профи

[@Adelf]

Честно говоря, тут нет такой градации «новичок — профи». Бывают разные кейсы, разные бутылочные горлышки. И с ними надо бороться по-разному. Я мог бы написать как мы боролись с некоторыми ботлнэками… но это будет скорее просто почитать по фану, чем реально полезная статья.

[@sait4seo]

напишите, всё равно интересно)

[@budda]

Простите за офтоп, но мне ак неофиту в php & laravel нужен совет, возможно решить мою проблему кешированием или как то по другому.
Есть самодельная Learning Management System очень скудного функционала под 200-300
пользователей.
Но вот проблема, чтобы в топбаре показать уведомления, непрочитанные внутренние сообщения, прогресс обучения и онлайн обучающихся, я загнал все это в ViewComposer и в результате получилось 90!!! запросов к бд при каждом запросе страниц. Вот вывод из debugbar bit.ly/32JR86a.
Как решаются такие вопросы? Ведь вывод всей этой информации — типовая задача для многих проектов, а я велосипед изобретаю с квадратными колесами.

[@Adelf]

Хороший пример и за дебагбар спасибо. Тут целую статью можно написать про то, как организовать тут кеш. Я попробую что-нибудь сообразить в ближайшее время.

[@budda]

Оформил вопросом на stackoverflow, там добавил код класса Composer, в котором все это все вызывается.