Безопасно ли использовать doctrine кеш в проекте с использованием doctrine, dql и SQL

Question

Я работаю над проектом, в котором doctrine кеш не активен. У нас возникают некоторые проблемы с производительностью, и мне интересно, приведет ли активация doctrine кеша к возможным регрессам.

Вот почему я спрашиваю об этом:

Я визуализирую 3 типа кеша :

• metadata_cache_driver
• result_cache_driver
• query_cache_driver

Самым важным для меня является result_cache_driver. И я не уверен, как это работает. Вот что я представляю:

У нас есть сущность "книга". Если мы создадим запрос dql или воспользуемся методом findBy doctrine, чтобы получить все книги, написанные в 1975 году, он вернет let say 75 книг. Этот результат сохраняется в кеше, и в следующий раз, когда мы его вызовем, он не будет запрашивать БД, а получит результат из кеша.

Теперь мы обновляем объект с помощью DQL или doctrine ($ book-> setYear ( 1976)). Я предполагаю, что кэш для книги сущностей будет сброшен, и в следующий раз, когда мы запросим все книги, написанные в 1976 году, он вернет 74 книги.

Но что если мы обновим БД, используя SQL: UPDATE book set year = 1976, где id = XXX. Будет ли он очищать кэш для этой сущности и запрашивать БД, когда мы запрашиваем все книги, написанные в 1975 году? Или он по-прежнему будет использовать кэшированный результат и вернет нашу обновленную книгу, которой больше нет в 1975 году?

Подводя итог, существует 3 способа обновления нашей БД:

• с использованием doctrine сущности (для одного обновления)
• с использованием запроса dql
• с использованием запроса sql (для массового обновления)

Так же как и результат кеша doctrine на счет тех 3х способов? Или будет какой-то случай, когда нам придется дождаться окончания срока службы кэша, чтобы получить новый правильный результат?

Answer 1

Как вы сказали, существует три вида кэшей, и они очень полезны для производительности вашего приложения.

Кэш запросов: Не имеет смысла выполнять этот анализ несколько раз поскольку это не изменится, если вы не измените запрос DQL. Итак, да, имеет смысл использовать кеш запросов, особенно в производственной среде, в которой кешируется преобразование DQL-запроса в его SQL аналог. Например, кроме поиска, осуществляемого пользователями, я кэширую все свои запросы, чтобы избежать процесса преобразования и повысить производительность.

Кэш метаданных Метаданные вашего класса можно анализировать из нескольких различных источников, таких как YAML, XML, аннотации и др. c. Вместо того, чтобы анализировать эту информацию по каждому запросу, мы должны кешировать ее, используя один из драйверов кеша. В процессе производства метаданные вашего класса не изменятся. Так почему бы не позволить кешу метаданных выполнять свою работу?

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

Если у вас есть данные, которые изменяют Много времени, вы могли бы избежать кеша, но я думаю, что кеш doctrine все еще полезен. Например, что произошло, если вы вызываете своих пользователей три раза в своем коде (один раз для проверки токена доступа, еще один раз для проверки безопасности и последний для установки своей последней активности), doctrine кэш результатов позволит избежать двух sql и две гидратации.

Если у вас есть данные, которые изменяются только при обновлении настроек администратором (описание товара, продаваемого в вашем интернет-магазине), вам следует их кэшировать. Когда администратор обновляет их, вы очищаете кеш.

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