Выбор бэкенд-стека сегодня — это не просто выбор синтаксиса, а выбор модели исполнения в памяти (Runtime). Современный PHP уникален тем, что позволяет менять архитектуру среды исполнения под конкретную задачу: от классического изоляционного процесса до асинхронного Event-Loop и бинарных Go-серверов.

---

Часть 1. Среды исполнения PHP: От изоляции к Event-Loop

PHP не привязан к Nginx. В зависимости от требований к нагрузке и архитектуре используются четыре ключевых runtime-модели:

1. SAPI / Process-per-Request (PHP-FPM)
   [ Web Server ] ──(FastCGI)──> [ PHP-FPM Master ] ──> [ Worker ] (die-after-request)

2. Long-Running Application Server (FrankenPHP / Caddy)
   [ FrankenPHP (Go) ] ──(In-Memory / Go-routines)──> [ Worker Threads ] (keep-alive)

3. Async Event-Loop Engine (Swoole / OpenSwoole)
   [ Single/Multi-Thread Process ] ──(Event Loop)──> [ Coroutines ] (non-blocking I/O)

4. Hybrid Application Manager (RoadRunner)
   [ RoadRunner (Go) ] ──(Goroutines / RPC)──> [ Persistent PHP Workers ]

1. PHP-FPM (FastCGI Process Manager)

  • Как работает: Входной веб-сервер (Nginx, Apache, Caddy) передаёт запрос мастер-процессу FPM, который выделяет изолированный воркер. По завершении запроса состояние очищается.
  • Плюсы: Абсолютная изоляция (утечки памяти физически невозможны), максимальная стабильность.
  • Минусы: Оверхед на инициализацию фреймворка (BOOT) при каждом HTTP-запросе.

2. FrankenPHP (Caddy Embed + Go)

  • Как работает: PHP-интерпретатор встраивается непосредственно в веб-сервер Caddy на базе Go (через cgo).
  • Плюсы: Поддерживает режим Worker Mode (приложение загружается в память один раз и обрабатывает тысячи запросов), из коробки дает HTTP/3, Early Hints и автоматические TLS-сертификаты.

3. RoadRunner (Go-powered Application Server)

  • Как работает: Сервер на Go берет на себя сетевой стек, балансировку, HTTP/gRPC, WebSockets и очереди (Queue). Он общается с постоянно запущенными PHP-процессами через бинарный протокол (Goridge / IPC).
  • Плюсы: Нулевой оверхед на старт фреймворка, низкий Latency, штатная интеграция с gRPC и временными задачами (Temporal).

4. Swoole / OpenSwoole (C++ Extension)

  • Как работает: Компилируемый C++ модуль, превращающий PHP в событийно-ориентированный движок с асинхронным I/O и корутинами (аналог Node.js / Go).
  • Плюсы: Высочайший RPS, поддержка миллиона параллельных WebSocket-соединений, встроенный HTTP/gRPC/TCP/UDP сервер без внешних обёрток.

---

Часть 2. Сравнительный анализ с конкурентами

Смена runtime-модели меняет позиции PHP в общей таблице конкурентов:

| Стек / Runtime | Модель выполнения | Основные преимущества | Слабые стороны / Ограничения |
| --- | --- | --- | --- |
| PHP 8.x <br>

<br>*(FrankenPHP / RoadRunner)* | Persistent Worker / In-Memory | Нулевой оверхед BOOT, строгий Composer, зрелый OOП, высокая скорость разработки (Time-to-Market). | Требует контроля за утечками памяти в синглтонах при работе в Long-Running режиме. |
| PHP 8.x <br>

<br>*(Swoole)* | Event Loop / Coroutines (C++) | Асинхронный I/O, низкая задержка, минимальный RAM-footprint под WebSockets. | Специфичный отладчик, сложнее использовать с традиционными синхронными C-экстеншенами. |
| Node.js / TypeScript <br>

<br>*(NestJS, Fastify)* | Event Loop (libuv) | Единый язык (TS) на Front/Back, нативная асинхронность из коробки. | CPU-bound задачи блокируют основной поток; риски с зависимостями в npm. |
| Go (Golang) <br>

<br>*(Gin, Fiber)* | Compiled / Goroutines (CSP) | Минимальное потребление памяти, компиляция в единый бинарник, родная параллельность. | Много шаблонизированного кода (boilerplate), отсутствие ORM/фреймворков уровня Doctrine/Eloquent. |
| Python <br>

<br>*(FastAPI, Uvicorn)* | ASGI / Event Loop (uvloop) | Нативный доступ к экосистеме AI/ML, Data Science, простой синтаксис. | Ограничения GIL, производительность ниже при высокой асинхронной нагрузке. |
| Java / Kotlin <br>

<br>*(Spring Boot)* | JVM Thread-per-request / Virtual Threads | Стандарт Enterprise, высокая скорость на CPU-bound задачах, масштабная экосистема. | Высокое потребление RAM при старте, долгое время «разогрева» (JIT Warm-up). |

---

Часть 3. Матрица выбора архитектуры

В зависимости от требований к рантайму, стек формируется следующим образом:

1. Классический CRUD / E-Commerce / CMS (Стабильность и изоляция)

  • Стек: PHP-FPM + Любой Reverse Proxy (Nginx / Caddy / Traefik).
  • Причина: Гарантированная очистка памяти, простота горизонтального автомасштабирования в K8s.

2. Highload API / Микросервисы (Минимальный Latency)

  • Стек: PHP 8 + RoadRunner или FrankenPHP (Worker Mode).
  • Причина: Фреймворк (Laravel/Symfony) висит в RAM, обработка запроса занимает единицы миллисекунд без повторного парсинга кода.

3. Real-time / WebSockets / Push-сервисы

  • Стек: PHP + Swoole *ИЛИ* Node.js (TypeScript).
  • Причина: Неблокирующий асинхронный I/O удерживает десятки тысяч открытых соединений на одном узле.

4. Системы с глубоким AI/ML компонентом

  • Стек: Python (FastAPI).
  • Причина: Прямой вызов C-библиотек (PyTorch, NumPy) без накладных расходов на IPC.