Бенчмарки

Реальные числа. Та же машина, та же сборка PHP, тот же обработчик — три эндпоинта на фреймворк, по которым выпущено ~100 000 запросов каждому через wrk.

PHP 8.3.6 · OPcache + tracing JIT · буфер JIT 64 МБ · php -S (один процесс) · wrk -t4 -c64 -d30s · записано 2026-05-15

`GET /ping`

#	Фреймворк	соответствие	зап./с	относительно	сред. мс	p90 мс	p99 мс
1	raw-php	базовая линия	9,009	1.00x	8.07	8.26	13.15
2	flight	без PSR-7	3,923	0.44x	16.29	18.11	21.87
3	lift	PSR-7 · PSR-11 · PSR-15	3,437	0.38x	18.63	20.71	24.38
4	slim	PSR-7	1,727	0.19x	37.09	39.84	48.21

`GET /json`

#	Фреймворк	соответствие	зап./с	относительно	сред. мс	p90 мс	p99 мс
1	raw-php	базовая линия	9,030	1.00x	8.12	8.23	10.16
2	flight	без PSR-7	3,833	0.42x	16.74	18.59	22.13
3	lift	PSR-7 · PSR-11 · PSR-15	3,552	0.39x	18.02	20.18	23.91
4	slim	PSR-7	1,759	0.19x	36.38	39.12	47.64

`GET /users/{id}`

#	Фреймворк	соответствие	зап./с	относительно	сред. мс	p90 мс	p99 мс
1	raw-php	базовая линия	8,947	1.00x	7.01	8.31	10.10
2	flight	без PSR-7	3,679	0.41x	17.43	19.47	23.04
3	lift	PSR-7 · PSR-11 · PSR-15	3,375	0.38x	18.99	21.14	25.62
4	slim	PSR-7	1,767	0.20x	36.23	38.84	44.51

~1,6 млн

всего выпущено запросов

+97 %

Lift быстрее Slim 4
(оба совместимы с PSR-7)

24 мс

задержка p99 при 64 одновременных
маршрутизация + DI + PSR-7

Как читать результаты

raw-php — это базовая линия: простой маршрутизатор на if/elseif без зависимостей. Flight быстр, потому что полностью обходит PSR-7 (собственные объекты запроса/ответа, без интерфейсов). Lift и Slim оба полностью совместимы с PSR-7 · PSR-11 · PSR-15; Lift ~на 97 % быстрее Slim 4 в этой категории.

Разрыв ~9 % между Flight и Lift — это измеримая стоимость неизменяемости PSR-7 + DI-контейнера — оправданный компромисс ради конвейеров middleware, тестируемости и совместимости с экосистемой PSR.

Методология

Все фреймворки работают как один процесс php -S — идентичные, изолированные, однопроцессные условия.
OPcache включён с tracing JIT и буфером 64 МБ (-d opcache.enable_cli=1 -d opcache.jit=tracing -d opcache.jit_buffer_size=64M).
Три эндпоинта с идентичной семантикой: GET /ping (text/plain), GET /json (объект из 5 ключей), GET /users/{id} (динамический маршрут + извлечение параметра).
Инструмент нагрузки: wrk -t4 -c64 -d30s --latency — 4 потока, 64 одновременных соединения, 30 секунд на прогон. Каждый эндпоинт: ~100 000+ запросов. Всего: ~1,6 млн запросов по всем фреймворкам.
Перцентили задержки (p90, p99) из встроенной гистограммы --latency в wrk. avg — среднее за весь прогон.
Абсолютные числа зависят от CPU хоста. Значимый сигнал — это относительный порядок и соотношения.

Воспроизведите сами

Два файла и одна команда — никаких дополнительных инструментов, кроме PHP и Composer.

1 · подготовка

shell

mkdir lift-bench && cd lift-bench
composer require malinichevvv/lift-php
mkdir public

2 · создайте public/index.php

public/index.php

<?php
require '../vendor/autoload.php';

$app = new \Lift\App();

$app->get('/ping', fn() => 'pong');

$app->get('/json', fn() => [
    'status' => 'ok', 'ts' => microtime(true),
    'memory' => memory_get_usage(), 'php' => PHP_VERSION, 'fw' => 'lift',
]);

$app->get('/users/{id:\d+}', fn(\Lift\Http\Request $r) => [
    'id' => (int) $r->param('id'), 'name' => 'Alice', 'email' => '[email protected]',
]);

$app->run();

3 · запустите сервер (OPcache + JIT)

shell

php -d opcache.enable_cli=1 \
    -d opcache.jit_buffer_size=64M \
    -d opcache.jit=tracing \
    -S 127.0.0.1:8000 -t public

4 · нагрузочный тест с помощью wrk

shell

wrk -t4 -c64 -d30s --latency http://127.0.0.1:8000/ping
wrk -t4 -c64 -d30s --latency http://127.0.0.1:8000/json
wrk -t4 -c64 -d30s --latency http://127.0.0.1:8000/users/42