Benchmarks

Kinetis wins five of six TechEmpower-style benchmark tests against eight other PHP frameworks — Laravel, Laravel Octane, Symfony, CodeIgniter, Yii2, CakePHP, and Slim on two runtimes — measured on isolated AWS hardware on August 18, 2026. TechEmpower sunset its own benchmark project in March 2026, so no neutral third party runs this kind of comparison anymore, which is exactly why the full methodology and every framework’s implementation are public in the benchmark repository: the numbers below are reproducible, not just reported. This page covers what was tested and what came out, not how the rig is built.

What was tested

Six TechEmpower Framework Benchmarks test types — /json, /plaintext, /db, /fortunes, /queries, /updates — against identical MySQL schema and data, one implementation per framework using that framework’s own idiomatic routing, database layer, and templating. Every target runs the same production PHP configuration (opcache with a tracing JIT, timestamps disabled, access logging off) and its own ahead-of-time caching mechanism where it has one. Three separate EC2 instances — application, database, load generator — provide real machine isolation, the same methodology TechEmpower’s own benchmark used; its test types remain the de facto standard for comparing web frameworks.

Two pairs of targets separate the framework from the runtime it runs on. kinetis and kinetis-fpm are the identical, unmodified application on FrankenPHP worker mode and on classic nginx with PHP-FPM. slim-frankenphp and slim are the same pairing for Slim.

Slim is a minimalistic “framework”: the target is nothing more than a request router and a PSR-7 implementation (slim/slim with slim/psr7) — no ORM, no templating, no service container, no validation. That is what makes the second pair a control rather than a competitor: slim-frankenphp puts that bare router on the same FrankenPHP worker runtime Kinetis runs on, which is the only way to tell how much of a result belongs to the framework and how much to the runtime underneath it. It is excluded from the leader board below and given its own comparison further down.

What that comparison shows is worth saying up front: Kinetis carries a full framework on top of that same runtime — attribute routing, validation, dependency injection, a middleware pipeline, OpenAPI generation — and where it trails the bare router it trails by 2.4% on average and 3.8% at worst. Once a request issues more than a handful of queries, it is ahead instead.

The fairness rules — what was tuned, why, and what was deliberately left alone — are documented in full in the repository’s own README; they aren’t repeated here.

Who leads each test

Winner among the eight competing frameworks at the heaviest level of each test, with the margin over second place.

/json · c=256

kinetis

25,676req/s

+95% over slim

/plaintext · c=256

kinetis

25,888req/s

+98% over slim

/db · c=256

kinetis

18,732req/s

+147% over slim

/fortunes · c=256

kinetis

15,689req/s

+120% over slim

/queries · n=20

kinetis

4,538req/s

+5% over slim

/updates · n=20

slim

1,860req/s

+17% over yii2

The same application on classic PHP-FPM tells its own story. kinetis-fpm leads every full framework in the field — including yii2, the fastest of them — on /json, /plaintext and /db, by around 3%, and is level with the fastest on /fortunes. It gives that back on /queries and /updates: under a boot-and-die runtime Kinetis uses a blocking PDO driver, so a request’s concurrent query fan-out has nothing to overlap and pays for the scheduling anyway. Query fan-out is where the persistent worker earns its keep — see Runtime Adapters.

Every measurement

Requests per second; higher is better. Bar length is relative to the fastest result anywhere in that test, so a row reads across columns. The highlighted figure leads its column. The last column is p99 latency at the heaviest level. Kinetis rows are tinted; the same-runtime control is marked.

/json

Serialize a single JSON object. No database.

concurrency	16	32	64	128	256	p99 ms
kinetis	23,848	24,585	25,005	25,181	25,676	22.8
slim-frankenphp	24,389	25,280	25,527	25,766	26,310	21.1
slim	11,236	12,053	12,547	12,820	13,141	43.0
kinetis-fpm	9,025	9,579	9,857	10,034	10,149	60.7
yii2	8,730	9,271	9,381	9,738	9,812	61.7
symfony	4,840	4,985	5,074	5,091	5,095	99.4
codeigniter	5,745	6,040	6,133	6,210	6,191	97.9
cakephp	5,539	5,789	5,885	5,892	5,855	91.4
laravel-octane	5,521	5,526	5,454	5,267	5,020	138.4
laravel	2,543	2,588	2,542	2,567	2,553	157.5

/plaintext

Return a fixed string. The floor of framework overhead.

concurrency	16	32	64	128	256	p99 ms
kinetis	23,766	24,607	24,643	24,835	25,888	22.1
slim-frankenphp	24,378	25,272	25,538	25,826	26,303	21.5
slim	11,146	12,009	12,288	12,679	13,049	50.3
kinetis-fpm	9,069	9,648	9,936	10,252	10,246	56.3
yii2	8,836	9,436	9,777	9,985	9,968	63.1
symfony	4,835	5,021	5,069	5,108	5,123	102.9
codeigniter	5,642	6,026	6,126	6,137	6,140	95.5
cakephp	5,485	5,762	5,894	5,964	5,914	89.8
laravel-octane	5,542	5,549	5,477	5,337	5,119	129.2
laravel	2,559	2,578	2,514	2,572	2,550	157.4

/db

One random row by primary key, per request.

concurrency	16	32	64	128	256	p99 ms
kinetis	16,075	16,656	16,942	17,801	18,732	29.1
slim-frankenphp	15,410	16,170	16,768	17,415	18,140	29.1
slim	6,426	7,129	7,424	7,577	7,573	70.8
kinetis-fpm	5,304	5,765	5,870	6,008	6,003	96.5
yii2	5,114	5,630	5,896	6,007	5,853	89.7
symfony	3,715	3,861	3,892	3,889	3,943	111.3
codeigniter	2,165	2,243	2,229	2,133	2,181	172.6
cakephp	2,946	3,098	3,091	3,119	3,093	125.3
laravel-octane	4,653	4,780	4,758	4,679	4,523	151.9
laravel	1,978	2,042	2,015	2,026	2,025	184.2

/fortunes

Fetch a table, add a row, sort, render HTML.

concurrency	16	32	64	128	256	p99 ms
kinetis	13,631	14,090	14,577	15,158	15,689	33.3
slim-frankenphp	13,820	14,530	15,040	15,658	16,040	29.2
slim	6,072	6,749	6,955	7,117	7,134	75.5
kinetis-fpm	4,971	5,405	5,498	5,543	5,501	105.4
yii2	4,925	5,341	5,384	5,516	5,558	91.1
symfony	3,494	3,589	3,696	3,643	3,621	120.6
codeigniter	2,037	2,050	2,059	2,030	2,024	186.9
cakephp	2,801	2,912	2,892	2,916	2,862	133.7
laravel-octane	4,308	4,420	4,392	4,317	4,177	162.7
laravel	1,874	1,917	1,924	1,905	1,870	173.9

/queries

N random rows per request, at concurrency 256.

queries	1	5	10	15	20	p99 ms
kinetis	17,555	11,624	8,008	5,788	4,538	62.3
slim-frankenphp	17,812	11,308	7,011	5,022	3,906	67.7
slim	7,502	6,385	5,483	4,797	4,339	94.8
kinetis-fpm	5,391	3,884	2,932	2,415	2,042	146.8
yii2	5,789	4,701	3,865	3,263	2,875	129.2
symfony	3,823	3,406	3,101	2,841	2,602	127.0
codeigniter	2,144	2,017	1,827	1,707	1,586	246.4
cakephp	2,987	2,282	1,928	1,607	1,409	209.1
laravel-octane	4,420	3,075	2,242	1,765	1,432	352.8
laravel	1,984	1,631	1,373	1,174	1,041	283.2

/updates

N rows read and written per request, at concurrency 256.

queries	1	5	10	15	20	p99 ms
kinetis	14,151	6,098	3,000	1,973	1,504	347.9
slim-frankenphp	13,727	5,399	2,882	2,008	1,533	245.6
slim	6,864	4,903	3,175	2,364	1,860	200.2
kinetis-fpm	4,820	2,789	1,906	1,423	1,130	426.8
yii2	5,445	3,728	2,662	2,047	1,588	245.9
symfony	3,752	2,773	2,474	1,826	1,500	368.2
codeigniter	2,123	1,863	1,565	1,325	1,200	376.3
cakephp	2,937	1,997	1,452	1,161	1,002	370.7
laravel-octane	3,948	2,281	1,431	1,079	841	435.2
laravel	1,884	1,355	1,043	830	716	799.0

Same runtime, different framework

kinetis and slim-frankenphp both run FrankenPHP in worker mode with 20 workers, so this pair isolates the framework itself from the runtime underneath it. Ratios above 1.05× or below 0.95× are highlighted; anything between sits inside this rig’s run-to-run noise.

test	level	kinetis	slim-frankenphp	ratio
/json	16	23,848	24,389	0.98×
/json	32	24,585	25,280	0.97×
/json	64	25,005	25,527	0.98×
/json	128	25,181	25,766	0.98×
/json	256	25,676	26,310	0.98×
/plaintext	16	23,766	24,378	0.97×
/plaintext	32	24,607	25,272	0.97×
/plaintext	64	24,643	25,538	0.96×
/plaintext	128	24,835	25,826	0.96×
/plaintext	256	25,888	26,303	0.98×
/db	16	16,075	15,410	1.04×
/db	32	16,656	16,170	1.03×
/db	64	16,942	16,768	1.01×
/db	128	17,801	17,415	1.02×
/db	256	18,732	18,140	1.03×
/fortunes	16	13,631	13,820	0.99×
/fortunes	32	14,090	14,530	0.97×
/fortunes	64	14,577	15,040	0.97×
/fortunes	128	15,158	15,658	0.97×
/fortunes	256	15,689	16,040	0.98×
/queries	1	17,555	17,812	0.99×
/queries	5	11,624	11,308	1.03×
/queries	10	8,008	7,011	1.14×
/queries	15	5,788	5,022	1.15×
/queries	20	4,538	3,906	1.16×
/updates	1	14,151	13,727	1.03×
/updates	5	6,098	5,399	1.13×
/updates	10	3,000	2,882	1.04×
/updates	15	1,973	2,008	0.98×
/updates	20	1,504	1,533	0.98×

The two track each other within a few percent until query fan-out grows: 0.99× at one query per request, 1.14× at ten, 1.16× at twenty. That gap is Kinetis issuing a request’s queries concurrently — see Concurrency — and it is the one place where the framework rather than the runtime shows up. The single 1.13× on /updates at five queries is an outlier the levels either side of it don’t support; treat it as noise.

Versions tested

Target	Package	Version	PHP
kinetis	kinetis/framework	1.17.1	8.5.9 (FrankenPHP, ZTS)
kinetis-fpm	kinetis/framework	1.17.1	8.4.24
slim-frankenphp	slim/slim	4.15.2	8.5.9 (FrankenPHP, ZTS)
slim	slim/slim	4.15.2	8.4.24
yii2	yiisoft/yii2	2.0.55	8.4.24
symfony	symfony/framework-bundle	7.4.16	8.4.24
cakephp	cakephp/cakephp	5.4.1	8.4.24
codeigniter	codeigniter4/framework	4.7.4	8.4.24
laravel	laravel/framework	13.25.0	8.4.24
laravel-octane	laravel/framework + laravel/octane	13.25.0 + 2.19.0	8.5.9 (FrankenPHP, ZTS)

kinetis/kinetis-fpm also ran kinetis/persistence 1.10.1 and kinetis/query-builder 1.2.4. FrankenPHP-based targets run a newer PHP than the PHP-FPM targets because that’s what the dunglas/frankenphp image ships — see Runtime Adapters for how Kinetis picks a runtime.

Reading these numbers

Worker count is a variable this run holds fixed. Both worker-mode targets got 20 workers on 8 vCPUs. An earlier run on a 2-CPU machine with 2 workers each put kinetis further ahead of the control on /queries and /updates. Where workers are plentiful, a blocking framework gets its parallelism from workers instead, and the gap narrows — see Performance tuning for how to size a deployment.

/updates is bound by the database’s own write path. At twenty queries per request every target lands between 716 and 1,860 req/s, and slim wins it. Row locks, index maintenance and the redo log set that ceiling; the database instance runs at the same load for every target, so no application-side change moves that number.

One measurement each, not an average. Targets ran back to back under identical conditions, but every cell is a single 15-second run after a 5-second warmup. Differences under roughly 5% are not distinguishable from noise.

Not comparable to published TechEmpower figures. The methodology matches — separate application, database and client machines — but the hardware and configuration do not.

Full methodology

The benchmark repository has the complete picture: every framework’s implementation, the AWS infrastructure as code, and the fairness rules applied identically across all ten targets — everything needed to run the same sweep yourself and check these numbers directly.

See also

• Performance tuning — the settings these numbers were produced with, and how to apply them to your own application.

• Runtime Adapters — worker thread sizing, the single setting that moved these results most.

• Caching & AOT Compilation — the production AOT cache the benchmarked configuration builds ahead of time.

• Concurrency — the reason the query-heavy tests scale the way they do.