PHP versions, measured — four pairings, four washes

PHP versions, measured — four pairings, four washes

PHP 8.3, 8.4 and 8.5 were compared four separate times, on four machines, across both release families. All four came out a wash. The differences are real enough to print and small enough to sit inside the same measurement's own resolution floor, so none of them is actionable.

That settles the version question by removing it. What is left is where PHP comes from, and there the answer is one-sided: each supported release's archive carries exactly one PHP series, and taking another means adding a third-party repository and losing automatic security patches.

The short answer

8.3, 8.4 or 8.5 — whichever your release supplies. All three run this application.

PHP ships a patch release about every 28 days, measured from upstream's own release dates. Whether those reach your server without anyone doing anything is a bigger question than which series you are on, and it is the only question this page ends up answering.

The four pairings

Every one of these was measured within a single machine, by running two or three FPM pools side by side and swapping which one served. That cancels the hardware entirely — which matters here, because two byte-identical machines in this round measured 11.6 % apart on 20 of 20 rows.

The control rows are the reason none of this is reportable. A static file served by nginx, and the micro-cache hits that never reach PHP at all, execute no PHP whatsoever. Whatever they move by is the arrangement's resolution floor. In all four pairings the effect sits inside it — and in one, the controls move further than the effect and in the opposite direction.

Two independent runs of the same design on the same machine also disagreed with each other, at −0.2 % and then −4.0 %, which says the same thing from another direction.

The three-way, in full

Both Debian machines, all three series installed on the same machine, six rounds each. The starting series rotates every round and reverses on alternate rounds, so each series takes each position an equal number of times.

Held constant across every arm: the same dataset, the same tuning read back from the serving process rather than from a configuration file, 10 workers per pool, JIT in tracing mode, opcache at 256 MB with timestamp validation off, and Laravel's config and route caches built.

Debian 13 — kernel 6.12.88, MariaDB 11.8

Debian 12 — kernel 6.1.0-47, MariaDB 10.11

Both machines together

Why the two machines disagree about which series is best

On Debian 13, 8.4 is 6.7 % behind. On Debian 12 it is 1.0 % ahead of 8.5 and 1.0 % behind 8.3. A version effect does not change sign between two machines running the same code.

Two things say the spread is the machines, not PHP. The per-row spread within each arm runs 8 to 40 %, so differences of 1 to 7 % sit inside it. And the control rows — which no PHP touches — move by the same order of magnitude across arms.

Add the round's standing measurement fact, that two byte-identical machines measured 11.6 % apart one-directionally on 20 of 20 rows, and any per-machine PHP ranking under about 10 % is noise.

So 8.5 ≈ 8.3, and 8.4 is two to seven percent behind

Taking all four pairings together, that is the shape: 8.4 comes out behind on four comparisons, by two to seven percent.

And in three of those four, the control rows moved the opposite way. That is not drift — drift shows up as controls moving with the treatment. But controls moving against it by a comparable amount is not a clean result either. The honest reading is that the arrangement cannot resolve the difference, and 8.4 is not slower in any way a shop would feel.

It changes nothing anyway, and that is the point of the next section.

Why the version does not decide anything

Each supported release's archive carries exactly one PHP series. Read from the repository indices with third-party sources filtered out:

So choosing a series other than your release's means adding a third-party repository. And the automatic-update mechanism matches on the origin strings in each repository's own metadata: it covers o=Ubuntu and origin=Debian, and it covers no third-party origin. A PHP installed that way waits for someone to run an update by hand — for the component with the largest attack surface in the stack, on a roughly 28-day patch cadence.

There is no measured gain on the other side of that trade. That is the whole argument.

Two specific consequences worth naming:

Do not put 8.4 on Ubuntu 24.04. That package is not in 24.04's archive, so it means a third-party source and losing automatic PHP patches — in exchange for a wash across 24 alternating pairs on two release families.

If your PHP comes from a third-party repository, which is how most panels and most hand-built servers get a version newer than the distribution's, do not stay on 8.3. Upstream bug-fix support for it ended in December 2025, and outside a distribution that backports its own fixes, that matters.

PHP 8.5 — the claim we had wrong, and how it was corrected

What this site said until 27 August 2026: 6amMart cannot run PHP 8.5. The spreadsheet library behind Bulk Import, Bulk Export and every Excel report declares that it needs PHP below 8.5, and a failure there is the worst kind — the APIs and the storefront keep answering normally while nobody can download a report, so a smoke test would not catch it.

That was derived from reading a constraint, not from running the code. Running it disproved it.

The bound is a declaration in the library's own metadata, not a measurement, and nothing enforces it at runtime: the application sets a platform version and switches the platform check off, in both the optimised fork and the untouched CodeCanyon tree. So no platform-check file is generated, and install and update both succeed on 8.5 with no override flag needed.

So it was tested rather than trusted, on PHP 8.5.4, against a real shop's data — 66,701 orders, 17,534 users, 192 tables:

Verified on both the plain CodeCanyon tree and the optimised fork. The Excel round-trip came back byte-identical including Devanagari text and an em dash; the CSV export byte-exact.

The one real difference is a single deprecation notice inside the spreadsheet library, where it increments a column letter using the numeric increment operator. PHP 8.5 deprecates that in favour of a purpose-built function. It does not break, and a production error-reporting level does not even log it. It becomes a real problem at PHP 9, by which time the library will have moved — the newer Excel package already requires a newer spreadsheet library that allows PHP 8.2 upward.

What is still open, and stated rather than hidden: 6amMart's own metadata declares support for 8.2, 8.3 and 8.4. 8.5 is not in the vendor's declared range. It works — everything above — but that is ahead of what the script's author supports, so each new vendor release gets re-tested on 8.5 rather than assumed. And because the platform check is switched off, the dependency manager will be silent about the next incompatibility too. The safety net is testing, not tooling.

Two more claims from this round that were withdrawn

"PHP 8.4 is faster at concurrency 1 and the sign inverts under load." Neither half survives, and the reason is a method error worth publishing.

The original passes alternated between series, which looks balanced. But inside every pair the order was fixed, so everything that warms up during a pair — database buffer pages, the opcode cache, the kernel's page cache for the storefront's asset chunks — landed on the same series in every single pair. That manufactured a median of −15.1 % which halved to −6.1 % when the order was reversed, with two rows changing sign.

The tell was in the rows where no PHP runs at all. They moved 10 to 13 % in the same direction as the PHP rows. A control that moves with the treatment means the measurement window moved, not the treatment. Re-measured with the order alternating within each pair, the axis is a wash.

"26.04 must take PHP 8.4 from a third-party repository." Withdrawn, because 8.5 was tested and works. That single change removed the last third-party PHP source from the recommended release — and with it a telemetry patch that the third-party build carried. Verified on the machine: every restart of that build emitted a DNS query to the provider's telemetry host carrying an encoded payload. It was restart-only, present in the FPM binary and absent from the command-line one, and no configuration switch to disable it could be found. Because it rides on DNS, an outbound firewall rule does not stop it.

Worth stating fairly: that provider is Debian's own PHP package maintainer, and upstream PHP publishes no package repository of its own, so every Debian and Ubuntu PHP comes from a packager. The trust order is the distribution's archive first, then that provider, then anything else. We simply no longer need the second row.

And a correction on top of that correction: the telemetry patch is in the provider's Ubuntu builds and absent from the Debian twin — same upstream version, same build date, same source commit, different target. So it is a property of one build, not of the repository. Both of the original statements about it were derived from one machine and generalised.

What this does not tell you

Every figure here is from a 2-core, 3.9 GB server. We have not measured larger.

The four pairings are four pairings, on one application. They say nothing about PHP's performance in general — only that for this codebase, at this scale, the series does not decide anything.

And the resolution floor is doing real work in all of them. A difference of two or three percent may well be there; this arrangement cannot see it, and a difference it cannot see is not one a shop can feel.

Related

The OS and stack round is where this axis sits among the other five. MariaDB versions, measured is the same shape of finding on the database. How we measure covers the alternating-order design that turned an 8 % result into a wash, and why control rows are the floor.

For the decisions rather than the evidence: which operating system and which database engine.