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

Итак, не без проблем, но мы раскатили редис на дев. Вроде работает корректно. В целом думается в этой задаче больше делать нечего.

Думается, что содержание собственного образа редис, для поднятия проекта, глобально решение верное, но такие образы должны готовить девопсы. Поэтому вместо созданий докерфайла редиса, надо передавать ему в volume его настройки, как делается с mysql

Еще подумал о подключении этих новых кешей к симфоневому cacge:clear/warmup, но суда по интерйесам сервисов, котоые жто должны делать, кажется эта система для cache.system и кешей которые кладутся в файлы и не меняются, вроди сгенерированных контейнеров, прокси и подобного. Т.е. для нас пока максимум что имеет смысл тут сбрасывать и восстанавливать, это cache.permissions.adapter

Попытались сделать себе удобную команду сбрасывания указанных кешей. Но не вышло. Если же сбрасывать через make back_bash и там уже писать команду, то там она срабатывает и лшние кеши не убивает.

Поигрались с result cache. Кэш работает, но сам по апдейтам не сбрасывается, его надо сбрасывать вручную. При этом в методах репозитория работающих по спецификациям и есть возможность установить время кеша, возможности установить его теги нет. Видимо надо дорабатывать vendor/happyr/doctrine-specification/src/Result/Cache.php. Так что пожалуй и это отложим.

Подклчили query и result кеш доктрины

Сессии в редисе. Кеш доктрины, думаю тоже положить в него, благо что имено туда попадет мы сами контролируем из QueryBuilder. Тут надо подумать над тегами и согласно им кешировать проекты. Если пойдет хорошо, от ProjectRegistry можно отказаться.

Кажется в рамках этой задачи больше делать нечего. Остальное будет сделано в тех ,что ждали эту задачу.

Итак к бекенду redis подключили. Он так и не захотел получаться из контейнера через $container->get(), но вполне себе инъектируется черз autowiring, только надо в yml явно описывать какой инстанс какому сервису давать.

Итак апостериорное чтение инфы о разных клиентах к редису выявило такую диспозицию:

• phpRedis (https://github.com/phpredis/phpredis)[https://github.com/phpredis/phpredis] - pecl-расширение на С.
  • Наиболее быстрое
  • требует установки в php-fpm, что в случае с контейнерами не проблема
• predis (https://github.com/predis/predis)[https://github.com/predis/predis] - composer-пакет на php соответственно.
  • вроде бы более функциональный
  • так как на php, его классы проще засунуть в контейнер

Сейчас мы подключили phpRedis и вроде бы он подключился корректно. Но пока не очень понятно как в контейнере описать несколько разных коннектов к разным БД. Точнее примерное решение я сделал, но получить такой сервис из контейнера не удалось. Думаетсяэто все же верный путь, и надо добивтаь его. В крайнем случае можно уйти на predis, скорость нам не столь критична, хотя и желательна

А вот подключение к контейнеру вызывает вопросы. Сходу не заработало

и не сказать, что совсем без проблем, но redis как сервис подключен.

Ну что, надо начинать чтоли. Образы есть, у редис есть компактный и понятный конфиг, в нем на первый взгляд есть все необходимое. Единственное что документацию выцеплять будет сложно, она закрыта для россиян, ну поставим второй ноут рядом, или добавим papervpn сюда. Вобще для работы все необходимое етсь в https://github.com/akandratovich/the-little-redis-book/blob/master/ru/redis.md, а для настройки можно один раз и таким путем.

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