Производительность и кэширование

OPcache хранит скомпилированные опкоды ваших PHP-файлов, чтобы скрипт не парсился и не компилировался заново на каждом запросе; данные приложения он не хранит. Redis или Memcached — кэш приложения: он хранит вычисленные вашим кодом результаты, например результат запроса, и общий для всех воркеров.

Картинки, CSS и JS всё равно занимают соединения и полосу на вашем origin. CDN отдаёт их с ближайшего к пользователю edge-узла, поэтому задержка падает, а origin обрабатывает только динамику. Имена файлов версионируют, чтобы новый деплой не отдавался из устаревшего edge-кэша.

Cache-Control: max-age разрешает клиенту переиспользовать ответ, не спрашивая, поэтому до PHP запрос не доходит, пока срок не истёк. ETag — отпечаток содержимого; клиент шлёт его в If-None-Match, и при совпадении вы отвечаете 304 Not Modified без тела, экономя рендер и передачу.

Синхронно вы держите FPM-воркер весь вызов: пользователь ждёт, слот никому не доступен, а сбой стороннего сервиса роняет и сам запрос. Постановка задачи в очередь сразу отдаёт ответ, а работу делает отдельный долгоживущий воркер, повторяя её при сбое.

Вертикальное масштабирование — более мощная машина: больше ядер и RAM позволяют поднять pm.max_children. Горизонтальное — добавить серверы за балансировщиком. Shared-nothing модель PHP делает это естественным, если сессии, загрузки и кэш лежат в общем хранилище вроде Redis, а не на локальном диске.

xdebug.mode=debug даёт пошаговую отладку — точки останова, шаги и просмотр переменных из IDE. xdebug.mode=profile записывает, куда уходит время, и пишет cachegrind-файл, который вы открываете в KCachegrind. Оба режима сильно замедляют запрос, поэтому на проде им не место.

Laravel отправляет сериализованный Job-объект в connection (Redis, база, SQS), а queue:work его обрабатывает; повторы, backoff и таблица failed_jobs встроены. Messenger отправляет обычное сообщение в шину, middleware маршрутизирует его в transport, а обрабатывает отдельный handler — поэтому то же сообщение можно обработать и синхронно.

Ключ стройте из всего, что меняет результат — фильтры, страница, сортировка, локаль — и дайте ему TTL как страховку. Главная работа — инвалидация: запись товара должна удалить или переписать затронутые ключи, обычно через тег или version-префикс, поднимаемый при записи, ведь перебрать ключи дёшево нельзя. Пустой кэш прикройте блокировкой, иначе всплеск запросов положит базу.

Профилируйте реальный запрос — Xdebug локально или Blackfire на боевом трафике — и читайте граф вызовов по inclusive wall time, а не по числу вызовов. Почти всегда это одно из трёх: запрос, повторённый сотни раз, один медленный запрос или блокирующий вызов стороннего сервиса. Чините то, что показал профиль: кэш вокруг функции на 2 мс не даст ничего.

Разбейте рассылку на мелкие задачи — по получателю или по чанку — и отправьте их батчем, а не одной гигантской задачей. Храните состояние по каждому получателю, чтобы повтор был идемпотентным: воркер занимает строку и пропускает уже помеченную как отправленную. Ограничьте воркеров лимитом провайдера, задайте предел повторов с backoff и показывайте прогресс и сбои, чтобы прогон можно было приостановить и возобновить.

Пул насыщен, а не медленный: 20 из 20 воркеров заняты и 312 запросов стоят в listen-очереди, поэтому большая часть из 8 с — ожидание воркера. Slow log называет виновника: блокирующий curl_exec() к сервису склада держит воркер секундами. Поднять pm.max_children — лишь передвинуть очередь; нужен таймаут и вынос этого вызова из запроса.

Мерьте, а не угадывайте. Возьмите среднюю резидентную память воркера на реальном трафике и поделите на неё RAM, которую можете отдать, — это потолок. Затем нагрузите машину, похожую на боевую, через k6 с растущей конкурентностью, следя за p95, listen-очередью FPM и памятью. Верное значение — наибольшее, при котором задержка ещё не растёт, а машина не уходит в swap.

Стройте ярусами: HTTP-валидаторы на edge для публичных GET, общий ярус Redis для вычисленных ответов, база позади обоих. Запись инвалидирует явно — удаляет или версионирует затронутые ключи, а не ждёт TTL. Redis должен остаться кэшем, а не зависимостью: при сбое проваливайтесь в базу за circuit breaker. Холодные ключи прикройте блокировкой или stale-while-revalidate и никогда не кладите персональные и авторизованные данные в общий ярус.