Как масштабировать PHP приложения без исчерпания пулов PHP-FPM

PHP обрабатывает огромный процент веб-приложений и API — от кастомных фреймворков до крупных монолитов на Laravel и Symfony. Современный PHP 8.x с JIT и OPcache выполняет код быстро, но производственные серверы всё равно испытывают трудности во время внезапных всплесков траика.

Корневая проблема редко заключается в скорости процессора самого PHP. Настоящим узким местом является архитектура параллелизма PHP-FPM (FastCGI Process Manager).

Ниже подробно описано, почему пулы процессов PHP-FPM насыщаются под нагрузкой, почему кэши Redis на уровне приложения не могут полностью защитить сервер и как размещение граничного обратного прокси перед PHP снижает TTFB до 12 мс, разгружая 95% серверного трафика.

1. Узкое место модели процессов PHP-FPM

В отличие от долго работающих циклов событий Node.js или горутин Go, традиционный PHP использует модель выполнения без разделения состояния (shared-nothing). Каждый HTTP-запрос требует изолированного рабочего процесса.

Когда запрос поступает в Nginx:

1. Nginx передает запрос через FastCGI свободному воркеру PHP-FPM.
2. Воркер загружает файлы бутстрапа фреймворка, автозагрузчики, конфигурации окружения и пулы соединений с базой данных.
3. Воркер выполняет логику приложения, делает запросы к MySQL или PostgreSQL и сериализует ответ.
4. Воркер очищает состояние запроса, освобождает память и ждет следующий запрос.

 HTTP Request ──► Nginx (Reverse Proxy) ──► FastCGI Socket ──► PHP-FPM Worker Pool
                                                                  ├── Worker #1 (Busy: 180ms)
                                                                  ├── Worker #2 (Busy: 240ms)
                                                                  └── Worker #3 (Busy: 160ms)
 

В файле  php-fpm.conf  директива  pm.max_children  определяет максимальное количество одновременных воркеров. На сервере с 8 ГБ ОЗУ, запущенном на современном фреймворке, каждый воркер потребляет от 40 до 70 МБ памяти, что ограничивает  pm.max_children  примерно 60–100 воркерами.

Если на обработку одного эндпоинта в среднем уходит 200 мс, 100 воркеров могут обрабатывать максимум 500 запросов в секунду:

$$\text{Max Throughput} = \frac{\text{Worker Pool Size}}{\text{Average Response Time}} = \frac{100}{0.2\text{s}} = 500\text{ req/sec}$$

Когда объем запросов вырастает до 1500 запр/с, буфер очереди ( listen.backlog ) мгновенно заполняется. Nginx начинает выдавать ошибки  502 Bad Gateway  и  504 Gateway Timeout , а на сервере заканчивается память.

2. Почему внутреннее кэширование в Redis не справляется

Многие команды пытаются решить эту проблему, добавляя кэширование Redis прямо внутри контроллеров PHP:

 <?php
// app/Http/Controllers/ProductController.php

public function show(int $id)
{
    $cacheKey = "product:{$id}";

    // Check local Redis
    $cached = Redis::get($cacheKey);
    if ($cached) {
        return response()->json(json_decode($cached, true));
    }

    $product = Product::with(['variants', 'categories'])->findOrFail($id);
    Redis::setex($cacheKey, 3600, json_encode($product));

    return response()->json($product);
}
 

Хотя это снижает нагрузку на запросы к базе данных, проблема исчерпания воркеров PHP-FPM при этом не решается:

• Рабочий процесс PHP-FPM по-прежнему занят в течение всего времени выполнения запроса.
• Маршрутизация фреймворка, контейнеры внедрения зависимостей, конвейеры middleware и сериализация JSON по-прежнему выполняются при каждом обращении.
• Даже ответ из Redis за 20 мс ограничивает пул из 100 воркеров до 5000 запр/с в идеальных условиях, при этом потребляя значительные ресурсы процессора.

3. Решение: кэширование на граничном прокси с тегированной очисткой

Вместо того чтобы позволять запросам на чтение доходить до PHP-FPM, разместите граничный прокси (например, ApexCache) непосредственно перед вашим приложением.

 Client (Global) ──► ApexCache Edge Gateway
                          ├── GET /api/v1/products/42 (Cache Hit) ──► Edge Memory (<12ms, 0 PHP workers)
                          └── POST /api/v1/orders (Bypass) ─────────► Origin Nginx ──► PHP-FPM Worker
 

Ключевые преимущества:

1.  Отсутствие выполнения PHP при попадании в кэш: Запросы на чтение возвращаются из граничной памяти без выделения воркера PHP-FPM и без обращения к MySQL.
2.  Объединение запросов SingleFlight: Если 500 одновременных запросов обращаются к истекшему ключу кэша в ту же миллисекунду, ApexCache пересылает PHP-FPM только 1 запрос. Остальные 499 запросов ожидают и получают свежий ответ напрямую с границы.
3.  Глобальная близость: Ответы обслуживаются с POP-серверов, расположенных близко к пользователю, что исключает задержки кругового пути до источника.

4. Реализация на PHP

Шаг 1: Возврат заголовков кэша и тегов из PHP

Настройте ваше PHP-приложение на возврат стандартных заголовков  Cache-Control  вместе с пользовательскими тегами кэша:

 <?php
// Standard PHP or Framework Response

namespace App\Http\Controllers;

use App\Models\Product;
use Illuminate\Http\JsonResponse;

class ProductController
{
    public function show(int $id): JsonResponse
    {
        $product = Product::with(['variants', 'pricing'])->findOrFail($id);

        return response()->json($product)
            ->header('Cache-Control', 'public, max-age=86400, stale-while-revalidate=300')
            ->header('X-ApexCache-Tags', "product:{$id}, catalog, brand:{$product->brand_id}");
    }
}
 

Шаг 2: Мгновенная инвалидация кэша при обновлении данных

Когда администратор обновляет продукт или цену, инвалидируйте конкретный тег на всех глобальных граничных узлах:

 <?php
// app/Services/CachePurgeService.php

namespace App\Services;

class CachePurgeService
{
    private string $apiKey;
    private string $endpoint = 'https://api.getapexcache.com/api/v1/cache/invalidate';

    public function __construct(string $apiKey)
    {
        $this->apiKey = $apiKey;
    }

    /**
     * Purge edge cache by tag in under 10ms.
     */
    public function purgeTags(array $tags): bool
    {
        $ch = curl_init($this->endpoint);

        $payload = json_encode(['tags' => $tags]);

        curl_setopt_array($ch, [
            CURLOPT_POST           => true,
            CURLOPT_POSTFIELDS     => $payload,
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT        => 2,
            CURLOPT_HTTPHEADER     => [
                'Authorization: Bearer ' . $this->apiKey,
                'Content-Type: application/json',
            ],
        ]);

        $response = curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        curl_close($ch);

        return $httpCode === 200;
    }
}
 

Запускайте этот сервис из хуков моделей Eloquent, подписчиков событий Symfony или слушателей жизненного цикла Doctrine:

 // In a Laravel Model Event or Observer:
public function updated(Product $product): void
{
    $purger = new CachePurgeService(config('services.apexcache.key'));
    $purger->purgeTags(["product:{$product->id}", "catalog"]);
}
 

5. Автоматическая инвалидация с помощью CDC базы данных

Если вы запускаете фоновые скрипты, выполняете прямой импорт SQL или используете микросервисы, которые изменяют базу данных напрямую без вызова событий моделей PHP, вы можете подключить ApexCache напрямую к бинлогу MySQL (binlog) или WAL PostgreSQL.

ApexCache обнаруживает зафиксированное изменение строки в реальном времени и автоматически очищает соответствующие теги кэша менее чем за 10 мс. Никакой логики очистки на уровне приложения при этом не требуется.

6. Бенчмарк в продакшене: PHP-FPM под нагрузкой

Мы провели нагрузочное тестирование стандартного API на PHP 8.3 + Laravel, развернутого на сервере с 8 ГБ ОЗУ и 4 виртуальными ядрами процессора за Nginx. Мы протестировали прямое выполнение PHP-FPM в сравнении с PHP-FPM под управлением прокси ApexCache:

Итог

Масштабирование PHP не требует переписывания бэкенда на Go или миграции на сложные микросервисы.

За счет завершения поисков в кэше на граничном прокси и инвалидации тегов при фиксации транзакций в базе данных, воркеры PHP-FPM запускаются только при обработке реальных мутаций данных. Ваше PHP-приложение остается стабильным, отзывчивым и быстрым независимо от всплесков трафика.

•  Документация и настройка: getapexcache.com/docs
•  SDK и интеграции: getapexcache.com/docs/sdks