Asynchronous PHP Explained: Fibers, Swoole and FrankenPHP

Asynchronous PHP is one of those topics where the terminology causes more confusion than the technology. Fibers, event loops, coroutines, worker mode, application servers: the words get used interchangeably in blog posts, and everyday developers reasonably conclude the whole area is not for them. That conclusion is half right. Most PHP applications will keep running the classic request-per-process model and be perfectly fine. But the pieces, Fibers in the language, Swoole as a coroutine runtime, FrankenPHP as a modern application server, solve distinct problems, and knowing which is which lets you reach for the right one on the day you actually need it. This post untangles them.

First, the baseline: why PHP is synchronous

Classic PHP under PHP-FPM follows a shared-nothing model: each request gets a fresh process state, runs top to bottom, and throws everything away. When your code queries the database, the worker blocks and waits. This model is why PHP scaled operationally for thirty years, crashes cannot poison the next request, memory leaks die with the request, and no one thinks about locks. Its cost is concurrency: a worker doing nothing but waiting on a slow API call is still an occupied worker. Everything under the "async PHP" umbrella is an attempt to stop paying for waiting, without giving up too much of the model's safety.

Fibers: the language feature, not the solution

Fibers, added in PHP 8.1, are interruptible functions: a block of code that can pause itself mid-execution with Fiber::suspend() and be resumed later, keeping its whole call stack intact. Crucially, a fiber does not make anything concurrent by itself; there is no scheduler in the language. It is a primitive:

$fiber = new Fiber(function (): void {
    $data = Fiber::suspend('waiting for I/O');
    echo "Resumed with: {$data}";
});

$state = $fiber->start();      // pauses at suspend()
$fiber->resume('the payload'); // continues from that exact point

The point of this primitive is what libraries build on it. An event-loop framework such as AMPHP or ReactPHP can suspend a fiber whenever it would block on I/O, run other fibers while the network does its work, and resume the first one when data arrives. Before fibers, that style forced promises or generator-based coroutines onto application code; with fibers, the suspension is invisible and async code reads exactly like synchronous code. The practical guidance for everyday developers is simple: you will probably never instantiate a Fiber directly, and that is fine. Fibers matter because they let the ecosystem hide the event loop from you.

Swoole: the coroutine runtime

Swoole (and its fork OpenSwoole) is a PHP extension that replaces the runtime model entirely: a long-running server with worker processes, coroutines scheduled on top, and non-blocking implementations of sockets, HTTP clients, and database connections. When a coroutine performs I/O through Swoole's hooks, the runtime automatically parks it and schedules another, so a single process can hold thousands of in-flight requests. This delivers the biggest concurrency numbers available in PHP, plus features like connection pools, WebSocket servers and shared memory tables.

The costs are proportional. Your application now lives in a persistent process: static properties and singletons survive between requests, so a leaked user object becomes a data-bleed bug rather than garbage collection's problem. Blocking calls that escape Swoole's hooks stall a whole worker's coroutines. Some extensions are incompatible, and debugging tooling behaves differently. Swoole earns its complexity in genuinely high-concurrency systems, gateways, chat and realtime services, API backends with heavy fan-out to slow upstreams, and teams adopting it should budget for the operational learning curve, not just the benchmark gains.

FrankenPHP: the modern application server

FrankenPHP attacks a different problem. Built in Go on top of the Caddy web server with PHP embedded, it replaces the nginx-plus-FPM stack with a single binary that speaks HTTP/2 and HTTP/3, handles TLS automatically, and supports early hints. In its standard mode it runs ordinary PHP applications unmodified, one request per execution, exactly as FPM would, just with a simpler deployment story that fits containers beautifully.

Its worker mode is where performance changes: the application boots once, then a loop handles many requests with the framework already initialised, eliminating per-request bootstrap. Laravel Octane and Symfony's runtime integration support this out of the box. Worker mode shares the persistent-state caveats of Swoole, state leaks between requests become your responsibility, but the programming model stays request-oriented rather than coroutine-oriented, which makes it a far smaller conceptual jump for a typical team. For many applications in 2026, FrankenPHP in worker mode is the pragmatic sweet spot: a large chunk of the performance win, a fraction of the paradigm shift.

Choosing without the hype

A decision guide that reflects how these tools actually get used:

• Typical web app or API, comfortable performance: stay on PHP-FPM or standard-mode FrankenPHP. Boring is a feature.
• Bootstrap-heavy framework app that needs more throughput: FrankenPHP or Octane worker mode. Audit for static state, then enjoy the speedup.
• A few slow endpoints doing parallel I/O (calling five APIs, fanning out HTTP requests): use an async HTTP client such as AMPHP's, or even curl_multi, inside your otherwise synchronous app. You do not need a new runtime to parallelise one hot spot.
• Sustained high concurrency, WebSockets, realtime: Swoole, or an AMPHP-based server, with the operational investment that implies.
• Background work: queues and workers remain the right answer far more often than async runtimes. Slow tasks belong off the request path entirely.

The takeaway

Asynchronous PHP in 2026 is a layered story, not a single technology. Fibers are the language primitive that made ergonomic async libraries possible; Swoole is the full coroutine runtime for teams that need extreme concurrency and will pay for it; FrankenPHP modernises serving and, in worker mode, removes bootstrap cost while keeping the familiar request model. The old shared-nothing model remains a legitimate default, and the best async strategy for most teams is surgical: keep the application synchronous, parallelise the specific I/O that hurts, and adopt a persistent runtime only when measurements, not fashion, say so.