PHP

What a PHP worker forgets — and twelve consequences

A Java, Node.js or Go service starts once and then serves requests for weeks from the same process. Whatever it puts in memory stays there: a cache, a connection pool, a counter, a timer. A PHP worker does the opposite. It builds the application from nothing for each request and throws all of it away when the response is sent. Almost everything that surprises a developer arriving from another language follows from that one difference. Here are twelve consequences, each with the habit it breaks and what PHP does instead. Later sections cite the rows by number.

One request, one clean process — and a pool with a ceiling

PHP almost never talks to the network by itself. A web server — nginx, Apache or Caddy — accepts the connection and hands the request over a protocol called FastCGI to PHP-FPM, the FastCGI Process Manager. FPM keeps a pool of worker processes. A free worker takes the request, loads the framework, runs your code, writes the response, and then discards every object, variable and connection it created. The next request gets a worker in the same empty state. This is the shared-nothing model: requests share nothing in memory, by design.

The upside is that a whole category of bug cannot exist. A leaked object, a corrupted global, a connection left in a broken state — all of it is thrown away within milliseconds, so a request can only poison itself. A fatal error takes down one request, not a server. Scaling is equally blunt: workers share nothing, so more capacity means more workers, and more workers on more servers means nothing to coordinate except the database.

The pool is the ceiling

Row 12 is the one that causes outages. A worker handles one request at a time, so the pool size is the number of requests PHP can serve at once — and the stock FPM configuration sets pm.max_children = 5. A fresh install handles five concurrent requests; the sixth waits in a queue. The right number comes from memory, not from CPU: measure how much one worker uses under real traffic, divide the memory you can give PHP by it, and leave room for everything else on the box. With 4 GB for PHP and 64 MB per worker, that is about sixty workers.

The pool then has a throughput ceiling, and it is simple arithmetic: workers divided by the time each request takes. Sixty workers at 100 ms a request serve 600 requests a second. Now let a payment provider slow down to 2 seconds. Every request that calls it holds its worker for 2 seconds, the same sixty workers serve 30 requests a second, and everything above that queues. The diagram draws it with a pool of eight. The CPU graph shows the server nearly idle the whole time, because waiting costs no CPU — which is why this outage is so often misread as "not enough servers".

The language people remember, and the one that exists

Most opinions about PHP were formed on PHP 5: no types, comparisons that made no sense, and a speed problem large enough that Facebook wrote its own compiler. PHP 7.0, in December 2015, rewrote the engine and was up to twice as fast as 5.6, and every release since has added to the type system. A release now ships every November, gets two years of bug fixes and two more of security fixes, and then gets nothing. The table lists what each one added that you will actually meet in code, and how long it is patched.

Strict types: the calling file decides

Type declarations in PHP have two modes. By default they coerce: pass the string "5" to an int parameter and PHP quietly converts it to 5. With declare(strict_types=1) at the top of a file they check: the same call throws a TypeError. The part almost everyone gets wrong is which file decides. In the manual’s words, strict typing "applies to function calls made from within the file with strict typing enabled, not to the functions declared within that file". A function written in a strict file still coerces when it is called from a file without the line.

The practical rule follows: put the line in every file, including tests and templates, and let a code-style tool enforce it. A library cannot make its own functions strict for the people who call it. Its only defence is static analysis on the caller’s side. PHPStan and Psalm read the declarations and find the null that reaches a method call before a user does. Both work in levels — PHPStan has eleven, 0 to 10 since its 2.0 release in November 2024 — so an existing code base can climb one level at a time rather than in one impossible sweep.

The comparisons PHP 8 fixed, and the ones it kept

The reputation for "weird comparisons" was earned by the loose operator ==, which converts both sides before it compares them. PHP 8 changed one rule: a number compared with a string that does not look numeric is now compared as a string. That removed the worst cases. The rest are still there, and they are the reason ===, which compares type and value without converting, is the default in modern code.

On the JITJITJust-In-Time compilation — compiling while runningCompiling code while the program is already running: the runtime interprets it at first, watches which parts are hot, and turns those into machine code on the fly. That is why the first seconds after start are slower than the minutes that follow.All terms compiler added in 8.0, be honest. It speeds up long numeric computation measurably and typical web requests barely at all, because a web request spends its time waiting on the database and the network rather than doing arithmetic. If a PHP page is slow, the answer is in the query log and in row 6, not in the JIT.

Laravel, Symfony, and the standards under both

Almost no one starts a PHP application from an empty directory. Composer, the dependency manager, installs packages from Packagist and writes the exact versions it chose into composer.lock; commit that file, and run composer install, never composer update, on a server. Composer also generates the autoloader, so you will not write a single require for your own classes. The autoloader works because of a standard: PHP-FIG, a group of framework and library authors, publishes PSRs — PHP Standard Recommendations — that let code from different projects plug together.

On top of that layer, two frameworks hold the field, and choosing between them is choosing how much the framework decides for you.

The honest summary: for a typical product team, Laravel gets you to a working feature sooner, and the risk is architectural drift. For a system a bank will still run in twelve years, Symfony’s explicitness is worth the ceremony. Both are maintained and fast enough. The difference between a good and a bad code base in either is discipline about where business logic lives, not the framework.

The database, and six calls worth a search before every release

PHP’s reputation for SQL injection came from a real era of queries built by gluing strings together, and the fix has been standard for well over a decade: prepared statements. A prepared statement sends the shape of the query and the values separately, so a value can never be read as SQL. Every ORMORMObject-Relational Mapping — objects instead of SQLA library that hands you language objects where the database has table rows, so you write little or no SQL. The convenience costs control: the query it generates can be far heavier than the one you would have written yourself, and you only find out under load.Full article →All terms and query builder in the ecosystem uses them underneath. The only way back to the vulnerability is to put a variable into SQL by hand.

Two more habits separate a code base that survives growth from one that does not. Keep transactions short: a transaction held open across an HTTP call to a payment provider locks its rows for as long as that provider is slow, and it also holds a worker (row 12). And keep migrations in version control next to the code that needs them, so a deployment and its schema change move together.

Injection is not the only door. Most serious PHP vulnerabilities come from a short list of calls that are safe with your own data and dangerous with anyone else’s. Each is easy to find with a text search, which makes the list a cheap review step before every release:

Long-running PHP: what worker mode gives back and takes away

There is now a second way to run PHP. Application servers boot the framework once and then serve many requests from the same process. FrankenPHP, built on the Caddy web server and officially supported by the PHP Foundation since May 2025, calls it worker mode. RoadRunner does it from a Go process; Swoole and OpenSwoole do it as a PHP extension with coroutines; Laravel Octane wraps all three, and Symfony runs on them through its Runtime component.

What that gives back is rows 1, 5 and 9. The bootstrap is paid once, so a request that spent most of its time loading the framework becomes several times faster. An in-process cache and a persistent connection start to mean something again. What it takes away is the safety of the shared-nothing model. Memory is no longer wiped between requests, so anything a request leaves behind on a long-lived object is visible to the next one — and the next one belongs to a different user.

Code written for FPM was never tested for that, because under FPM it could not happen. Before switching, audit for these five things:

Five cases, and what each one was missing

Each case below is documented in PHP’s own announcements, bug tracker and mailing list, or in the published research that found it. Between them they cover the engine, the seam with the web server, the source repository, the support window and the framework layer.

The first case is why the language section opens with a speed claim. In February 2010 Facebook announced HipHop, which translated PHP into C++ because the standard engine could not keep up with its traffic, and it then replaced it with HHVM, a virtual machine with a JIT. For a few years the fastest way to run PHP was not PHP’s own. The answer came from inside the project: PHP 7.0, released on 3 December 2015, rebuilt the engine’s core data structures and was, in the release announcement’s words, "up to twice as fast as PHP 5.6". In September 2018 the HHVM team announced it would stop supporting PHP, and HHVM 4.0, in February 2019, runs only Hack, Facebook’s own language. Teams that had moved to HHVM for speed moved back. A fork that outperforms the original is a bet on one company’s roadmap.

The third case is about the language’s own source. On 28 March 2021 two commits appeared in php-src on PHP’s self-hosted git server, signed with the names of Rasmus Lerdorf, who created PHP, and Nikita Popov, one of its most active developers. They were labelled as typo fixes. They added code that executed any PHP sent in a User-Agentt header — note the second t — starting with the word "zerodium". Developers reading the commit stream spotted the first one within hours and reverted it; the second put the same code back and was reverted too. The next day the project made its GitHub repository the canonical one, with two-factor authentication required for write access. The later finding was that the git server had probably not been broken into at all: the user database behind it had most likely leaked, so the attacker pushed with real credentials. Review worked. Identity did not.

The fifth case joins row 1 of the grep table to a secret. Laravel encrypts cookiescookiedata the browser sends backA small piece of data a website asks the browser to keep and send back with every request to that site — which is how a server remembers that you are signed in. Because the browser attaches it automatically, even to a request another site triggered, a session cookie needs its flags set and an anti-forgery check on the server.All terms and other values with the application’s APP_KEY, and its decrypt() function unserialises what it decrypts by default. Whoever holds the key can therefore encrypt an object of their choosing, hand it to the application, and have it unserialised — remote code execution. For old Laravel versions this was CVECVECommon Vulnerabilities and Exposures — a public ID for a known vulnerabilityA public identifier for a known security flaw, such as CVE-2021-44228 for Log4Shell, so that vendors, scanners and advisories all mean the same bug. The number says a flaw exists; how dangerous it is for you depends on whether you run the affected version and expose the affected part.All terms-2018-15133. In July 2025 GitGuardian and Synacktiv published what that means at scale: they extracted more than 260,000 APP_KEY values from public GitHub repositories committed between 2018 and May 2025, and identified more than 600 live applications that could be taken over with them. The key had been committed with a .env file, or pasted into a config, and never rotated. The controls were all ordinary — a secret scanner on every push, a rotation when a key leaks — and the design lesson is the old one: never let one secret be the only thing between the internet and unserialize().

Where it degrades

PHP’s model is forgiving, and that is both its strength and the way it fails. A leak, a bad global or a slow loop costs one request and is forgotten, so a code base can carry a great deal of disorder before anything visibly breaks. When it does break, it is almost always one of the twelve rows ignored, or one of the six calls trusted with someone else’s data:

• Slow work inside the request — mail, PDFs, third-party calls — instead of on a queue (row 6).
• A pool left at the stock five workers, or sized for CPU instead of memory (row 12).
• No wall-clock timeout on outgoing calls, so one slow dependency holds every worker.
• Sessions or uploads on local disk, which works on one server and breaks silently on two (rows 2 and 3).
• N+1N+1one query per row, by accidentThe classic ORM trap: one query fetches a list, then the loop over it quietly fires one more query per item — a hundred rows become a hundred and one round trips to the database. The fix is to ask for the related data up front instead of row by row.Full article →All terms queries behind a convenient relation, invisible until the table has real data in it.
• Files without strict_types, so type declarations coerce instead of checking and give false confidence.
• Business logic inside controllers and models, until a rule can only be tested through an HTTP request.
• unserialize() on anything that crossed a network, or a framework key committed to a repository.
• Worker mode switched on for speed without auditing what long-lived objects now keep between users.
• A version past the last column of the table, where the next advisory has no patch.

The honest limit is the model itself. A request that must stay open — a chat, a live dashboard, a stream — fights the one-request-one-worker design the whole way, and the right answer is usually a second, small service in another runtime beside the PHP application, not a PHP application bent into that shape. The same goes for heavy computation and data pipelines: the runtime can do them, but the libraries, the tooling and the people are elsewhere. Worker mode narrows the gap without closing it, and it buys its speed with exactly the safety that made PHP easy to reason about.

The practical check takes five minutes. Run php -v on the production server and find the row in the version table. Run composer audit, which lists installed packages with known advisories. Open the FPM status page (pm.status_path) under real traffic and compare "active processes" with pm.max_children: if they are equal at peak, row 12 is already your bottleneck.

When to use it

Related pages

• DevelopmentNode.jsNode.js is a server runtime for JavaScript that runs all of your code on one thread and hands every wait to the operating system or a small thread pool. That one design is why a single process holds ten thousand idle connections, and why one slow function delays every request at once. The page opens with seventeen things a Node server does and which thread pays for each, then covers the event loop and the pool, releases and support — Node 27 moves to one major a year — what is built in now, scaling and a clean shutdown, five documented cases, and where it degrades.
• DevelopmentMonolithA monolith is an application that is built, tested and deployed as one unit, whatever its size and however its code is organised inside. Most complaints made about monoliths are really about the missing boundaries inside one — a different problem with a cheaper fix — and a monolith with real module boundaries is the right default for most systems. The page opens with sixteen common complaints and where each one actually lives, then covers the two axes every architecture argument confuses, why one deployable is the default and the best argument against it, drawing and enforcing module boundaries, running a large monolith, where it genuinely runs out, five documented cases, and where it degrades.
• DevelopmentPythonPython is a general-purpose language whose standard interpreter runs Python code one thread at a time and leaves heavy number-crunching to compiled libraries. That lock, the GIL, is why four threads are rarely four times faster, why Python web servers run as several processes, and why a slow service needs a diagnosis before a fix: is it waiting, or computing? The page opens with twelve workloads and the tool that actually speeds each one up, then covers the GIL and the new build without it, asyncio, versions and the yearly release, types and packaging, web servers and their memory, five documented cases, and where it degrades.