С чем связан вопрос?
Нет понимания какие цифры нормальные. Если время соизмеримо это норма? Выборка по id скажем. Second Level Cache
Зависит от многих факторов. Например вероятность найти запись в кэше и где кэш. Если у тебя редис какой то сходить за данными по сети обычно так же долго как и в базу. Потому обычно цепочки делают (array - apcu - redis) Если ещё и для ключа вероятность кэш хита меньше скажем 90% то возможно кэш будет замедлять (сначала в рэдис по сети, потом в базу). Конкретно с secondary level cache хз, опять же Профит может быть только там где кэш хит оч вероятен и за горячими данными не надо по сети гулять
Аналогичный вопрос, что у Сергея выше. Есть кэширование юзеров (полей 10, без связей), редис. Вроде всё настроено, как в документации и примерах. Сервис кэша, провайдер, в доктрине выбран нужный в secondary level cache. Обычный массовый запрос через userRepo->findBy['id' => $ids], поиск всего двух пользователей. Поставил точки перед-после запроса, в профайлере показывает время выполнения - 5мс (и ноль запросов в бд). Отключаю кэш - 2-3мс (один запрос в бд) . Чзх? Сам запрос в редис обрабатывается за ~0.02мс, всё остальное - компонент кэша.
сериализация слабее чем сишный клиент мускуля
1 запрос в базу или 2 запроса в рэдис
Обсуждают сегодня