Сравниваем PHP FPM, PHP PPM, Nginx Unit, React PHP и RoadRunner

Тестирование производилось с помощью Yandex Tank.
В качестве приложения использовались Symfony 4 и PHP 7.2.
Целью являлось сравнение характеристик сервисов при разных нагрузках и нахождение оптимального варианта.
Для удобства все собрано в docker-контейнеры и поднимается с помощью docker-compose.
Под катом много таблиц и графиков.

Исходный код лежит тут.
Все примеры команд, описанные в статье, должны выполняться из директории проекта.

Приложение

Приложение работает на Symfony 4 и PHP 7.2.

Отвечает только на один роут и возвращает:

• случайное число;
• окружение;
• pid процесса;
• имя сервиса, с помощью которого работает;
• переменные php.ini.

Пример ответа:

curl 'http://127.0.0.1:8000/' | python -m json.tool
{
    "env": "prod",
    "type": "php-fpm",
    "pid": 8,
    "random_num": 37264,
    "php": {
        "version": "7.2.12",
        "date.timezone": "Europe/Paris",
        "display_errors": "",
        "error_log": "/proc/self/fd/2",
        "error_reporting": "32767",
        "log_errors": "1",
        "memory_limit": "256M",
        "opcache.enable": "1",
        "opcache.max_accelerated_files": "20000",
        "opcache.memory_consumption": "256",
        "opcache.validate_timestamps": "0",
        "realpath_cache_size": "4096K",
        "realpath_cache_ttl": "600",
        "short_open_tag": ""
    }
}

В каждом контейнере настроен PHP:

• включен OPcache;
• настроен bootstrap кеш с помощью composer;
• настройки php.ini соответствуют лучшим практикам Symfony.

Логи пишутся в stderr:
/config/packages/prod/monolog.yaml

monolog:
    handlers:
        main:
            type: stream
            path: "php://stderr"
            level: error
        console:
            type: console

Кеш пишется в /dev/shm:
/src/Kernel.php

...
class Kernel extends BaseKernel
{
    public function getCacheDir()
    {
        if ($this->environment === 'prod') {
            return '/dev/shm/symfony-app/cache/' . $this->environment;
        } else {
            return $this->getProjectDir() . '/var/cache/' . $this->environment;
        }
    }
}
...

В каждом docker-compose запускаются три основных контейнера:

• Nginx — реверсивный прокси-сервер;
• App — подготовленный код приложения со всеми зависимостями;
• PHP FPMNginx UnitRoad RunnerReact PHP — сервер приложения.

Обработка запросов ограничивается двумя инстансами приложения (по числу ядер процессора).

Сервисы

PHP FPM

Менеджер PHP процессов. Написан на C.

Плюсы:

• не нужно следить за памятью;
• не нужно ничего менять в приложении.

Минусы:

• на каждый запрос PHP должен инициализировать переменные.

Команда для запуска приложения с docker-compose:

cd docker/php-fpm && docker-compose up -d

PHP PPM

Менеджер PHP процессов. Написан на PHP.

Плюсы:

• инициализирует переменные один раз и затем использует их;
• не нужно ничего менять в приложении (есть готовые модули для Symfony/Laravel, Zend, CakePHP).

Минусы:

• нужно следить за памятью.

Команда для запуска приложения с docker-compose:

cd docker/php-ppm && docker-compose up -d

Nginx Unit

Сервер приложений от команды Nginx. Написан на С.

Плюсы:

• можно менять конфигурацию по HTTP API;
• можно запускать одновременно несколько инстансов одного приложения с разными конфигурациями и версиями языков;
• не нужно следить за памятью;
• не нужно ничего менять в приложении.

Минусы:

• на каждый запрос PHP должен инициализировать переменные.

Чтобы передать переменные окружения из файла конфигурации nginx-unit, необходимо поправить php.ini:

; Nginx Unit
variables_order=E

Команда для запуска приложения с docker-compose:

cd docker/nginx-unit && docker-compose up -d

React PHP

Библиотека для событийного программирования. Написана на PHP.

Плюсы:

• c помощью библиотеки можно написать сервер, который будет инициализировать переменные только один раз и дальше работать с ними.

Минусы:

• необходимо написать код для сервера;
• необходимо следить за памятью.

Если использовать для воркера флаг --reboot-kernel-after-request, то Symfony Kernel будет инициализироваться заново на каждый запрос. При таком подходе не нужно следить за памятью.

#!/usr/bin/env php

<?php

use AppKernel;
use SymfonyComponentDebugDebug;
use SymfonyComponentHttpFoundationRequest;

require __DIR__ . '/../config/bootstrap.php';

$env   = $_SERVER['APP_ENV'] ?? $_ENV['APP_ENV'] ?? 'dev';
$debug = (bool)($_SERVER['APP_DEBUG'] ?? $_ENV['APP_DEBUG'] ?? ('prod' !== $env));

if ($debug) {
    umask(0000);

    Debug::enable();
}

if ($trustedProxies = $_SERVER['TRUSTED_PROXIES'] ?? $_ENV['TRUSTED_PROXIES'] ?? false) {
    Request::setTrustedProxies(explode(',', $trustedProxies), Request::HEADER_X_FORWARDED_ALL ^ Request::HEADER_X_FORWARDED_HOST);
}

if ($trustedHosts = $_SERVER['TRUSTED_HOSTS'] ?? $_ENV['TRUSTED_HOSTS'] ?? false) {
    Request::setTrustedHosts(explode(',', $trustedHosts));
}

$loop   = ReactEventLoopFactory::create();
$kernel = new Kernel($env, $debug);
$kernel->boot();
$rebootKernelAfterRequest = in_array('--reboot-kernel-after-request', $argv);

/** @var PsrLogLoggerInterface $logger */
$logger = $kernel->getContainer()->get('logger');
$server = new ReactHttpServer(function (PsrHttpMessageServerRequestInterface $request) use ($kernel, $logger, $rebootKernelAfterRequest) {

    $method  = $request->getMethod();
    $headers = $request->getHeaders();
    $content = $request->getBody();
    $post    = [];
    if (in_array(strtoupper($method), ['POST', 'PUT', 'DELETE', 'PATCH']) &&
        isset($headers['Content-Type']) && (0 === strpos($headers['Content-Type'], 'application/x-www-form-urlencoded'))
    ) {
        parse_str($content, $post);
    }
    $sfRequest = new SymfonyComponentHttpFoundationRequest(
        $request->getQueryParams(),
        $post,
        [],
        $request->getCookieParams(),
        $request->getUploadedFiles(),
        [],
        $content
    );
    $sfRequest->setMethod($method);
    $sfRequest->headers->replace($headers);
    $sfRequest->server->set('REQUEST_URI', $request->getUri());

    if (isset($headers['Host'])) {
        $sfRequest->server->set('SERVER_NAME', current($headers['Host']));
    }

    try {
        $sfResponse = $kernel->handle($sfRequest);
    } catch (Exception $e) {
        $logger->error('Internal server error', ['error' => $e->getMessage(), 'trace' => $e->getTraceAsString()]);
        $sfResponse = new SymfonyComponentHttpFoundationResponse('Internal server error', 500);
    } catch (Throwable $e) {
        $logger->error('Internal server error', ['error' => $e->getMessage(), 'trace' => $e->getTraceAsString()]);
        $sfResponse = new SymfonyComponentHttpFoundationResponse('Internal server error', 500);
    }

    $kernel->terminate($sfRequest, $sfResponse);
    if ($rebootKernelAfterRequest) {
        $kernel->reboot(null);
    }

    return new ReactHttpResponse(
        $sfResponse->getStatusCode(),
        $sfResponse->headers->all(),
        $sfResponse->getContent()
    );
});

$server->on('error', function (Exception $e) use ($logger) {
    $logger->error('Internal server error', ['error' => $e->getMessage(), 'trace' => $e->getTraceAsString()]);
});

$socket = new ReactSocketServer('tcp://0.0.0.0:9000', $loop);
$server->listen($socket);

$logger->info('Server running', ['addr' => 'tcp://0.0.0.0:9000']);

$loop->run();

Команда для запуска приложения с docker-compose:

cd docker/react-php && docker-compose up -d --scale php=2

Road Runner

Web-сервер и менеджер PHP-процессов. Написан на Golang.

Плюсы:

• можно написать воркер, который будет инициализировать переменные только один раз и дальше работать с ними.

Минусы:

• необходимо написать код для воркера;
• необходимо следить за памятью.

Если использовать для воркера флаг --reboot-kernel-after-request, то Symfony Kernel будет инициализироваться заново на каждый запрос. При таком подходе не нужно следить за памятью.

#!/usr/bin/env php

<?php

use AppKernel;
use SpiralGoridgeSocketRelay;
use SpiralRoadRunnerPSR7Client;
use SpiralRoadRunnerWorker;
use SymfonyBridgePsrHttpMessageFactoryDiactorosFactory;
use SymfonyBridgePsrHttpMessageFactoryHttpFoundationFactory;
use SymfonyComponentDebugDebug;
use SymfonyComponentHttpFoundationRequest;

require __DIR__ . '/../config/bootstrap.php';

$env   = $_SERVER['APP_ENV'] ?? $_ENV['APP_ENV'] ?? 'dev';
$debug = (bool)($_SERVER['APP_DEBUG'] ?? $_ENV['APP_DEBUG'] ?? ('prod' !== $env));

if ($debug) {
    umask(0000);

    Debug::enable();
}

if ($trustedProxies = $_SERVER['TRUSTED_PROXIES'] ?? $_ENV['TRUSTED_PROXIES'] ?? false) {
    Request::setTrustedProxies(explode(',', $trustedProxies), Request::HEADER_X_FORWARDED_ALL ^ Request::HEADER_X_FORWARDED_HOST);
}

if ($trustedHosts = $_SERVER['TRUSTED_HOSTS'] ?? $_ENV['TRUSTED_HOSTS'] ?? false) {
    Request::setTrustedHosts(explode(',', $trustedHosts));
}

$kernel = new Kernel($env, $debug);
$kernel->boot();
$rebootKernelAfterRequest = in_array('--reboot-kernel-after-request', $argv);
$relay                    = new SocketRelay('/tmp/road-runner.sock', null, SocketRelay::SOCK_UNIX);
$psr7                     = new PSR7Client(new Worker($relay));
$httpFoundationFactory    = new HttpFoundationFactory();
$diactorosFactory         = new DiactorosFactory();

while ($req = $psr7->acceptRequest()) {
    try {
        $request  = $httpFoundationFactory->createRequest($req);
        $response = $kernel->handle($request);
        $psr7->respond($diactorosFactory->createResponse($response));
        $kernel->terminate($request, $response);
        if($rebootKernelAfterRequest) {
            $kernel->reboot(null);
        }
    } catch (Throwable $e) {
        $psr7->getWorker()->error((string)$e);
    }
}

Команда для запуска приложения с docker-compose:

cd docker/road-runner && docker-compose up -d

Тестирование

Тестирование производилось с помощью Yandex Tank.
Приложение и Yandex Tank были на разных виртуальных серверах.

Характеристики виртуального сервера с приложением:
Virtualization: KVM
CPU: 2 cores
RAM: 4096 МБ
HDD: 50 GB SSD
Connection: 100MBit
OS: CentOS 7 (64x)

Тестируемые сервисы:

• php-fpm
• php-ppm
• nginx-unit
• road-runner
• road-runner-reboot (c флагом --reboot-kernel-after-request)
• react-php
• react-php-reboot (c флагом --reboot-kernel-after-request)

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

Для каждого сервиса и конфигурации Yandex Tank проводился всего один тест. Из-за этого цифры могут быть неточными. Важно было оценить характеристики сервисов относительно друг друга.

100 rps

Конфигурация phantom Yandex Tank

phantom:
    load_profile:
        load_type: rps
        schedule: line(1, 100, 60s) const(100, 540s)

Ссылки с детальным отчетом

• php-fpm https://overload.yandex.net/150666
• php-ppm https://overload.yandex.net/150670
• nginx-unit https://overload.yandex.net/150675
• road-runner https://overload.yandex.net/150681
• road-runner-reboot https://overload.yandex.net/151961
• react-php https://overload.yandex.net/150697
• react-php-reboot https://overload.yandex.net/152063

Перцентили времени ответа

Мониторинг

Графики

График 1.1 Среднее время ответа в секунду

График 1.2 Средняя нагрузка процессора в секунду

График 1.3 Среднее потребление памяти в секунду

500 rps

Конфигурация phantom Yandex Tank

phantom:
    load_profile:
        load_type: rps
        schedule: line(1, 500, 60s) const(500, 540s)

Ссылки с детальным отчетом

• php-fpm https://overload.yandex.net/150705
• php-ppm https://overload.yandex.net/150710
• nginx-unit https://overload.yandex.net/150711
• road-runner https://overload.yandex.net/150715
• road-runner-reboot https://overload.yandex.net/152011
• react-php https://overload.yandex.net/150717
• react-php-reboot https://overload.yandex.net/152064

Перцентили времени ответа

Мониторинг

Графики

График 2.1 Среднее время ответа в секунду

График 2.2 Средняя нагрузка процессора в секунду

График 2.3 Среднее потребление памяти в секунду

1000 rps

Конфигурация phantom Yandex Tank

phantom:
    load_profile:
        load_type: rps
        schedule: line(1, 1000, 60s) const(1000, 60s)

Ссылки с детальным отчетом

• php-fpm https://overload.yandex.net/150841
• php-ppm https://overload.yandex.net/150842
• nginx-unit https://overload.yandex.net/150843
• road-runner https://overload.yandex.net/150844
• road-runner-reboot https://overload.yandex.net/152068
• react-php https://overload.yandex.net/150846
• react-php-reboot https://overload.yandex.net/152065

Перцентили времени ответа

Мониторинг

Графики

График 3.1 Среднее время ответа в секунду

График 3.2 Среднее время ответа в секунду (без php-fpm, php-ppm, road-runner-reboot)

График 3.3 Средняя нагрузка процессора в секунду

График 3.4 Среднее потребление памяти в секунду

10000 rps

Конфигурация phantom Yandex Tank

phantom:
    load_profile:
        load_type: rps
        schedule: line(1, 10000, 30s) const(10000, 30s)

Ссылки с детальным отчетом

• php-fpm https://overload.yandex.net/150849
• php-ppm https://overload.yandex.net/150874
• nginx-unit https://overload.yandex.net/150876
• road-runner https://overload.yandex.net/150881
• road-runner-reboot https://overload.yandex.net/152069
• react-php https://overload.yandex.net/150885
• react-php-reboot https://overload.yandex.net/152066

Перцентили времени ответа

Мониторинг

График 4.1 Среднее время ответа в секунду

График 4.2 Среднее время ответа в секунду (без php-fpm, php-ppm)

График 4.3 Средняя нагрузка процессора в секунду

График 4.4 Среднее потребление памяти в секунду

Итоги

Здесь собраны графики, отображающие изменение характеристик сервисов в зависимости от нагрузки. При просмотре графиков стоит учитывать, что не все сервисы ответили на 100% запросов.

График 5.1 95% перцентиль времени ответа

График 5.2 95% перцентиль времени ответа (без php-fpm)

График 5.3 Максимальная нагрузка процессора

График 5.4 Максимальное потребление памяти

Оптимальным решением (без изменения кода), на мой взгляд, является менеджер процессов Nginx Unit. Он показывает хорошие результаты в скорости ответа и имеет поддержку компании.

В любом случае подход к разработке и инструменты нужно выбирать индивидуально в зависимости от ваших нагрузок, ресурсов сервера и возможностей разработчиков.

Автор: mrsuh

Источник