Modern PHP

nginx accepts the connection and forwards PHP requests over FastCGI to PHP-FPM. FPM's master process keeps a pool of workers; a free worker runs the entry script, builds the response and returns it. When the request ends, PHP frees every object and variable it created. This share-nothing model is a feature: memory leaks and stale state cannot accumulate, and a crash affects only one request. The cost is bootstrapping the framework on every request, which OPcache reduces by caching compiled bytecode. Persistent state lives outside PHP, in the database, Redis or the session store. Worker-mode runtimes like Octane or FrankenPHP trade that safety for speed.

Several things together. Types became genuinely useful: union, nullable, mixed, never, typed properties and class constants, enforced with strict_types. The language gained expressive features: match expressions, named arguments, constructor promotion, the nullsafe operator, enums in 8.1, readonly properties and classes, property hooks and asymmetric visibility in 8.4, and the pipe operator in 8.5. Attributes replaced docblock annotations for metadata. Performance improved with the JIT compiler and continuous engine work. Around the language, Composer, PSR standards, PHPStan and Rector give a tooling story comparable to TypeScript. The PHP of 2010 tutorials and the PHP of today are very different languages to work in.

match is an expression, so it returns a value you can assign directly. It compares with strict identity (===), so '1' does not match 1, which avoids a whole class of switch bugs. Each arm is a single expression with no fall-through, so you cannot forget a break. Most importantly, if no arm matches and there is no default, match throws UnhandledMatchError instead of silently doing nothing. Combined with enums, that means adding a new case and forgetting to handle it fails loudly in tests. I still use switch rarely, for multi-statement branches with side effects, but match is my default for mapping values.

composer.json declares acceptable version ranges; composer.lock records the exact versions, and their hashes, that were resolved. composer install reads the lock file and installs exactly those versions, so every developer, CI run and server gets identical code. composer update ignores the lock, resolves the newest versions allowed by the ranges and rewrites the lock file. So you run update deliberately, ideally for one package at a time, review the changes and commit the new lock; deploys and CI only ever run install. Without a committed lock file, two servers deployed a week apart can run different library versions.

Layered checks. First, declare(strict_types=1) and full type declarations make PHP throw TypeErrors instead of silently coercing values. Second, static analysis with PHPStan or Psalm, run in CI at a high level, reads the whole codebase and finds wrong types, undefined methods and impossible conditions before deployment. Generics in docblocks (array<int, Order>, Collection<User>) give the analyser even more information. Third, enums and readonly value objects make invalid states harder to express. Finally, tests cover the behaviour that types cannot describe. Together this gets very close to the guarantees of a compiled language.

I consider it when profiling shows that framework bootstrapping, not the database or external APIs, is a large share of response time, and when traffic is high enough that the extra throughput matters, such as a busy API with short requests. Gains of several times are realistic in that case. The risks are about state: static properties, singletons holding the current user or tenant, and caches in memory now survive between requests, which can leak data between customers or grow memory until the process dies. Some packages are not written for it. So I audit the container bindings, mark request-specific services as scoped, add a max-requests limit, and run parallel load tests with different users before switching. If requests are dominated by slow SQL, fixing queries gives more benefit for far less risk.

I start from memory, not from guesses. Measure the average resident memory of a worker under real traffic, subtract what the OS, database, Redis and other services need, and divide: that is the ceiling for pm.max_children. For a dedicated app server with steady traffic, pm = static avoids fork costs and gives predictable memory. For a server hosting several sites, pm = dynamic or ondemand saves memory for quiet pools at the cost of spawning workers under bursts. I set pm.max_requests so slow leaks are contained, enable pm.status_path to watch the listen queue and max children reached, and use the slow log to find requests that hold workers too long. If workers are mostly waiting on I/O, the fix is usually queues or caching, not a bigger pool.

By keeping the code that changes for business reasons separate from the code that changes for technical reasons. Domain logic lives in plain, typed PHP classes, value objects and enums, with as few framework calls as possible, so a framework upgrade touches mostly controllers, configuration and infrastructure adapters. Dependencies are few and chosen for maintenance history, because an abandoned package is often the real upgrade blocker. Static analysis at a high level and automated tests around critical flows make large automated changes safe, and Rector applies most syntax migrations mechanically. CI runs against the next PHP version early, so deprecations show up months before they become errors. The trade-off is slightly more structure up front, which pays back the first time a major version arrives.