Зависит от многих факторов. Например вероятность найти запись в кэше и где кэш. Если у тебя редис какой то сходить за данными по сети обычно так же долго как и в базу. Потому обычно цепочки делают (array - apcu - redis)

Если ещё и для ключа вероятность кэш хита меньше скажем 90% то возможно кэш будет замедлять (сначала в рэдис по сети, потом в базу).

Конкретно с secondary level cache хз, опять же Профит может быть только там где кэш хит оч вероятен и за горячими данными не надо по сети гулять

Кэшировать результаты простых и дешёвых выборок имеет смысл только если нет под это дело Рид реплик базы и хочется чуть убавить нагрузку. А так в таких случаях лучше весь респонс кэшить или большую его часть

Аналогичный вопрос, что у Сергея выше.

Есть кэширование юзеров (полей 10, без связей), редис.
Вроде всё настроено, как в документации и примерах. Сервис кэша, провайдер, в доктрине выбран нужный в secondary level cache.

Обычный массовый запрос через userRepo->findBy['id' => $ids], поиск всего двух пользователей.

Поставил точки перед-после запроса, в профайлере показывает время выполнения - 5мс (и ноль запросов в бд).
Отключаю кэш - 2-3мс (один запрос в бд) .

Чзх?
Сам запрос в редис обрабатывается за ~0.02мс, всё остальное - компонент кэша.

сериализация слабее чем сишный клиент мускуля

Относительно недавно на симфони, поэтому вопрос, возможно глупый (как и выше мой вопрос), но..

Такие числа нормальные для сериализации?
По ~2.5мс на сериализацию "json из 10 полей" -> "entity"?

Или можно куда-то капнуть, чтобы уменьшить время выполнения?

А то получается, что самый простой запрос на сервер с авторизацией выходит ~50-100мс

1 запрос в базу или 2 запроса в рэдис

Рэдис быстрый, но база при выборке по pk при условии что кэши все в базе настроены не медленнее, дальше вопрос как с сетью работаешь

Откуда 50-100 мс если запрос сам всего 5

Где-то что то лишнее выполняется, профилирование и трейсинг может помочь понять на что уходит время.

Например если рэдис по tls то может доп время уходить на хэндшейки при первом подключении

Окей, но такие цифры для сериализаци  и доктрины (2-4мс на один запрос) - это нормально? Или можно ускорить?

Да это выглядит правдоподобным

2-4мс это очень даже норм.

Ну это много в общем то.

Инициализация доктрины, авторизация - уже 15-20мс.
Мелкие ивенты до контролера - ещё какое-то время. Сам контроллер прилично отжирает (бывает и по ~30-50мс на пустой экшен).
Ивенты после

Но не настолько что быможно было проблемы подозревать

Ну из очевидного

- убедись что кэш всяких метаданных в общей памяти лежит (можно даже Чейн array - apcu сделать)
- отключить все лишнее
- проверить настройки opcache и apcu. Дефолта для симфони не годятся
- проверь время подключения - tls доп расходы накладывает - люди часто рядом с приложением проксю какую ставят дабы оно реюзадюло tcp соединение между запросами и за счёт этого пару миллисекунд экономят. В случае базы есть тоже прокси которые будут пул коннекшенов держать.

Короч главное мерять на что время уходит

apcu лучше чем файл filesystem в ramdrive?

тяжко )