Lift v1.3.0

Бенчмарки

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

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

GET /ping

# Фреймворк запит./с p99 мс
1 raw-php 9,009 13.15
2 flight 3,923 21.87
3 lift 3,437 24.38
4 slim 1,727 48.21

GET /json

# Фреймворк запит./с p99 мс
1 raw-php 9,030 10.16
2 flight 3,833 22.13
3 lift 3,552 23.91
4 slim 1,759 47.64

GET /users/{id}

# Фреймворк запит./с p99 мс
1 raw-php 8,947 10.10
2 flight 3,679 23.04
3 lift 3,375 25.62
4 slim 1,767 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