Можно ли в symfony вместо файлового кэша использовать любой другой?

Question

[tigra]

Есть большой проект на symfony + docker + macOs. Естественно на mac+docker все операции связанные с обращением к файлам очень долгие. Вопрос: можно ли переключить файловый кэш например на redis или memcache?
Внимание! о странице https://symfony.com/doc/current/components/cache.html я в курсе, но речь идет не просто кэше для каких то конкретных расширений по типу doctrine или twig, а именно о системном кэше симфони, который он создает в целях оптимизации, собирает для всех контейнеров и что хранит в /var/cache

Comments

[BoShurik]

Все равно будет тормозить, юзайте docker-sync

[tigra]

BoShurik, там проблема именно с инвалидацией. Подождать пока контейнеры соберутся в кэше я подожду, но после этого при вызове любой страницы отрабатывает код проверки актуальности кэша, который обращается к файлу и проверяет его время создания
Symfony\Component\Config\Resource\FileResource:61
а с виртуализацией на маке это очень затратно, особенно когда он срабатывает 20к раз. Собственно из за этого все еле работает...

[BoShurik]

tigra, $this->resource в указанном месте - это не файл кеша, а файл или директория в src (в общем случае), куда бы вы не положили свой кеш, запрос все равно будет идти в примонтированный volume для проверки актуальности и будет тормозить.
BTW, вы можете хранить кеш отдельно в контейнере, не монтируя его на вашу файловую систему, но прирост будет незначительным.
К примеру, приложение у вас в /app (куда примонтирован код), кеш, соответственно в /app/var/cache
Передав переменную окружения APP_CACHE_DIR=/var/app/cache кеш не будет синкаться, но, как я сказал выше, прирост будет минимальным, используйте docker-sync

[tukreb]

tigra, для Мак только одно решение - поднятие виртуалки, и по SSH работать с проектом.

[BoShurik]

tukreb, docker-sync не пробовали?

[tukreb]

BoShurik, нет, хм, интересно, почитаю.

[tukreb]

BoShurik, похоже подружить docker-sync с Windows ещё та головоломка. Вроде всё сделано по инструкции, но всё равно пересборка кэша даже из wsl на примонтированную папку идёт так же долго как и напрямую в докере.

[BoShurik]

tukreb, вот тут да, коллеги тоже жалуются. Ну в данном случае есть вариант на windows его не использовать (e.g. через docker-compose.override.yml) . Я так понимаю, проблема с синхронизацией там стоит не так остро?

[tukreb]

BoShurik, на виндовс да, всё не так плохо, как на маке.
Там в самом симфни с 5 версии провели оптимизации и в докере ещё подкрутили, тоже как раз к 5 версии симфон, там вроде было 2 кратное ускорение.
Конечно, когда проект разрастается на сотни сущностей, то полный перезапуск докера с очисткой кэша и загрузкой фикстур занимает 1-2 минуты:), просто очистка кэша около 20 секунд.
Да там ещё можно как решение поместить папку vendor внутрь докера, очень сильно ускоряет, но вроде какие-то подводные камни были, уже не помню почему отказался от этого решения.

Answer 1

[Александр]

Из коробки нет
Но, думаю, можно попробовать перемокать всю работу с файловым хранилищем и переписать на работу с 3 системой, хотя, конечно, перекапать многое.

Не понятно почему они долгие, у меня та же сборка работает нормально. Вам капать нужно в другую сторону.

Comments

[tigra]

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

[Александр]

tigra, так диск тут при чем? У вас время занимает сборка контейнера, а не чтение с диска. Поместив эти данные в оперативку вы получится прирост в доли секунды.

[tigra]

Как раз при этом. Прогрев кэша то я подожду, но потом, при любом вызове происходит проверка кэша на актуальность
Я чекнул профайлером и вижу, что за 1 вызов страницы, функция filemtime() (Symfony\Component\Config\Resource\FileResource:61), которая как раз проверяет время создания файла кэша при прогреве, вызывается около 25к раз и занимает около 7 секунд.
Т.е. проверка на актуальность происходит уже после прогрева

[Александр]

tigra, И вы считаете, что 25к непараллельных запросов к редису будет сильно быстрее?

[tigra]

думаю что явно быстрее в случае с маковской виртуализацией
да и проверка в фс тоже не многопоточная как бы

[Александр]

tigra, я бы не был так уверен. Если попробуете, расскажите успехи

[BoShurik]

tigra, я ж вам сказал, для инвалидации кеша нужен сам файл, который находится на хостовой файловой системе. Куда бы вы не положили файлы кеша, вы все равно должны будете сходить за файлом в примонтированный volume. Если не верите, разместите кеш в контейнере и проверте

[tigra]

BoShurik, вообще то речь шла про возможное ускорение, если бы можно было вынести прогретый кэш из файлов куда нибудь в память или другое хранилище. т.е. это ПРЕДПОЛАГАЕМОЕ поведение. По поводу того что кэш хранится в файлах и файлы нужны для инвалидации никто тут и не оспаривает, все все поняли что иного варианта хранения без своих костылей не предусмотрено

[BoShurik]

tigra, фишка в том, что даже если бы было можно использовать не файловый кеш, а любой другой - значимого прироста вы бы не получили. Страница открывалась бы не 7 секунда, а скажем 5.

Я чекнул профайлером и вижу, что за 1 вызов страницы, функция filemtime() (Symfony\Component\Config\Resource\FileResource:61), которая как раз проверяет время создания файла кэша при прогреве

Вот это никуда не денется
Она проверяет не время создания файла кэша, а время последнего редактирования файла (который как раз на хостовой машине и любое к нему обращение - медленное) и сравнивается со временем создания кеша для этого файла

[BoShurik]

tigra, легко можно вынести в память, используется какой-нибудь ramfs
mount -t ramfs -o size=4 ramfs /mnt/cache