Когда использовать Doctrine или Symfony Cache?

Я много читал о различных вариантах кэширования Doctrine, а также о механизмах кэширования Symfony:

Официальный Symfony: https://symfony.com/doc/4.0/components/cache.html

Официальная доктрина: https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html

КнП университет (как всегда очень полезно): https://knpuniversity.com/screencast/symfony-fundamentals/caching

Другие полезные ресурсы: https://blog.kaliop.com/blog/2014/10/06/doctrine-symfony2-2/

Тем не менее, несмотря на объяснение, КАК использовать систему кеширования, я не могу понять, КОГДА использовать кеш. При каких обстоятельствах кеш очень полезен, а когда не стоит его использовать.

Например, в моем проекте у меня есть большой объем данных, которые нужно извлечь из моей базы данных, которые я хотел бы кэшировать (извлечение сущностей с множеством левых объединений). Эти оставленные соединения для некоторых обновляются каждый час, каждый день или каждую минуту на регулярной основе, хотя бот вызывается с помощью задания cron (команда symfony).

Я не знаю, как обеспечить правильное обновление всех моих данных, когда я показываю их пользователю с включенным механизмом кеширования? Если БД обновляется, нужно ли мне вручную удалять данные из кеша, вызывая, например, $cacheDriver->delete('my_data’); во время обновления и проверяя, существуют ли данные, а затем сохранять их заново при извлечении данных? Будет ли это правильным способом сделать это?

Кроме того, следует ли использовать Doctrine Cache или Symfony 4 cache? Какой выбрать? У меня есть пример одного из запросов, который я хотел бы кэшировать в другом потоке SO здесь: https://stackoverflow.com/a/51800728/1083453

Суть в том, как сделать этот запрос максимально эффективным?

Я склоняюсь к следующему: - Удалять кеш при обновлении любых данных, включенных в мой запрос. - Кешировать при первом вызове запроса - Получить его всякий раз, когда вызывается один и тот же запрос между двумя обновленными

Я на правильном пути?

Любая помощь или совет очень приветствуются.

Спасибо

Почему голос против? Не могли бы вы прокомментировать и помочь мне улучшить его, пожалуйста? Спасибо

Miles M. 11.08.2018 20:27

Голосование не мое, но я понимаю, почему он был отклонен. Вопрос расплывчатый и слишком общий. Нет четкой постановки проблемы, и на самом деле невозможно дать четкий ответ. Я бы порекомендовал перефразировать вопрос, чтобы сосредоточиться на одной постановке проблемы, и попытаться изменить форму сообщения, чтобы оно соответствовало масштабу этой особой проблемы.

lxg 13.08.2018 21:43

Спасибо ценю приятель

Miles M. 13.08.2018 22:34
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
1
3
779
2

Ответы 2

Официальных правил нет. Иногда вы можете подумать, что выполняете оптимизацию, когда в лучшем случае вы теряете время, а в худшем - теряете производительность, потому что процесс проверки того, есть ли у вас кеш и действителен ли он, длиннее, чем сам запрос.

Предполагая, что вы проделали достаточно хорошую работу по архитектуре своего приложения (это означает, что нет лишних операций, что ваши запросы хорошо выполнены и не загружают бесполезные данные и т. д.), Это действительно конкретный случай.

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

Мне было интересно то же самое, и я наткнулся на ваш вопрос.

Полное раскрытие: я никогда не использовал кеш результатов доктрины :) Я ожидаю, что с кешем результатов Doctrine вам не нужно беспокоиться о сериализации / десериализации ваших кэшированных данных. Это может быть очень удобно, когда вы пытаетесь кэшировать, а затем получить сложный объект.

Другие вопросы по теме