
PHP has a reputation for being strictly "one thing at a time": a request comes in, your code runs top to bottom, and while it waits for the database or an HTTP call, it just... waits. PHP 8.1 quietly added a feature that changes what's possible here: **PHP Fibers**. They are the foundation for coroutines and cooperative concurrency in PHP.

Fibers are a low-level tool, and most developers will use them through a library rather than directly. But understanding what they are makes a lot of modern async PHP click into place.

## Table of contents

1. [Blocking vs non-blocking, quickly](#blocking-vs-non-blocking-quickly)
2. [What a PHP Fiber actually is](#what-a-php-fiber-actually-is)
3. [A tiny Fiber example](#a-tiny-fiber-example)
4. [Fibers vs threads vs async](#fibers-vs-threads-vs-async)
5. [When you actually need this](#when-you-actually-need-this)

## Blocking vs non-blocking, quickly

When your code calls a database or an external API, most of the time is spent *waiting* for the answer. In normal PHP, that wait is "blocking": nothing else can happen on that process until the answer arrives.

If you need to make ten independent API calls, blocking code does them one after another — ten waits in a row. What if the process could start the next call while waiting for the first? That's the problem concurrency solves.

## What a PHP Fiber actually is

A Fiber is a block of code that can **pause itself** and hand control back to the caller, then **resume later** exactly where it left off. That's the whole idea.

Think of reading a book with a bookmark. You can stop at any page, go do something else, and later open back to the exact page and continue. A Fiber is that bookmark for running code.

Crucially, this is *cooperative*: the Fiber decides when to pause (it "yields"). Nothing interrupts it by force. That makes the behavior predictable and avoids many of the classic pitfalls of threads.

## A tiny Fiber example

```php
$fiber = new Fiber(function (): void {
    echo "start\n";
    $value = Fiber::suspend('paused here');  // hand control back
    echo "resumed with: $value\n";
});

$signal = $fiber->start();      // prints "start", returns 'paused here'
echo "fiber said: $signal\n";

$fiber->resume('hello again');  // prints "resumed with: hello again"
```

Running this prints:

```
start
fiber said: paused here
resumed with: hello again
```

Notice how execution jumped *out* of the fiber at `suspend`, ran the outer code, then jumped back *in* at `resume`. That pause-and-resume ability is everything you need to build cooperative concurrency.

## Fibers vs threads vs async

It helps to compare three ideas people often confuse:

- **Threads** run code truly in parallel, and the operating system can interrupt them at any moment. Powerful, but you must guard shared data carefully.
- **Fibers** run one at a time and only switch when the code chooses to. No surprise interruptions, so far fewer concurrency bugs.
- **Async/await** in other languages is usually built on top of a Fiber-like mechanism plus an event loop.

So a Fiber is not parallelism. It's a way to interleave waiting tasks efficiently on a single thread.

## When you actually need this

Be honest: for a typical request-response web app, you probably don't use Fibers directly. Your framework and the classic model work great.

Fibers shine when you have lots of I/O waiting at once — many concurrent API calls, a long-lived server handling many connections, or real-time features. In those cases you'll usually reach for a library (like an async runtime) that uses Fibers under the hood, so you write simple-looking code that runs concurrently. If long-lived processes interest you, see how [FrankenPHP worker mode](/blogs/frankenphp-worker-mode) keeps your app booted between requests.

## Conclusion

PHP Fibers gave the language a proper, built-in way to pause and resume code — the missing piece for real cooperative concurrency. You may never call `Fiber::suspend` yourself, but knowing what it does demystifies every async PHP library you'll meet. Start by recognizing where your code spends its time waiting; that's where this idea pays off.

## Resources

- [PHP manual: the Fiber class](https://www.php.net/manual/en/language.fibers.php)
- [ReactPHP](https://reactphp.org/) and [AMPHP](https://amphp.org/) (async runtimes that build on Fibers)


Understanding PHP Fibers and Coroutines


For years, the mental model of a PHP application was simple: a request comes in, PHP boots up, runs your code, sends a response, and then throws everything away. The next request starts from zero. This "share nothing" model is easy to reason about and hard to leak memory with, but it also means you pay a startup cost on **every single request**.

FrankenPHP is one of the projects trying to change that — without forcing you to rewrite your application. Its headline feature, FrankenPHP worker mode, is what actually moves the needle on PHP performance. Let's look at what it does and when it makes sense.

## Table of contents

1. [The classic setup, briefly](#the-classic-setup-briefly)
2. [What FrankenPHP is](#what-frankenphp-is)
3. [FrankenPHP worker mode: boot once, serve many](#frankenphp-worker-mode-boot-once-serve-many)
4. [The catch: state now leaks between requests](#the-catch-state-now-leaks-between-requests)
5. [When is it worth it?](#when-is-it-worth-it)
6. [Takeaways](#takeaways)

## The classic setup, briefly

A traditional PHP stack looks like this: a web server (Nginx or Apache) talks to **PHP-FPM**, a process manager that keeps a pool of PHP workers ready. For each request, FPM hands the work to a worker, the worker bootstraps your framework (autoloading, config, service container, routes), runs the request, and tears it all down.

That bootstrap is the hidden tax. On a small script it's nothing. On a full framework like Laravel or Symfony — or a large legacy app — rebuilding the whole world on every request adds up.

## What FrankenPHP is

FrankenPHP is a modern application server for PHP, built on top of the Caddy web server. In practice it gives you two things:

1. **A single binary** that serves your PHP app directly — no separate Nginx + PHP-FPM to wire together. It also brings HTTPS, HTTP/2 and HTTP/3 out of the box.
2. **Worker mode** — the feature that actually moves the performance needle.

You can adopt point 1 without changing your code at all: FrankenPHP can run a normal PHP app exactly like FPM would. That alone simplifies your deployment. The interesting part is worker mode.

## FrankenPHP worker mode: boot once, serve many

The idea behind FrankenPHP worker mode is straightforward. Instead of bootstrapping your framework on every request, you bootstrap it **once**, keep it in memory, and then loop: wait for a request, handle it, wait for the next one.

Conceptually, a worker script looks like this:

```php
<?php
// This runs ONCE, when the worker starts
require __DIR__ . '/vendor/autoload.php';
$app = require __DIR__ . '/bootstrap/app.php'; // expensive setup

// This loop runs for EACH request, reusing $app
$handler = static function () use ($app) {
    $request = // build request from globals
    $response = $app->handle($request);
    $response->send();
};

// FrankenPHP feeds requests into the handler
$maxRequests = (int) ($_SERVER['MAX_REQUESTS'] ?? 0);
for ($i = 0; !$maxRequests || $i < $maxRequests; $i++) {
    $keepRunning = \frankenphp_handle_request($handler);
    if (!$keepRunning) {
        break;
    }
}
```

The expensive part — autoloading, reading config, building the container — happens before the loop. Inside the loop you only do the per-request work. For a heavy framework this can cut response times dramatically, because you've deleted the repeated bootstrap. If you want to push PHP performance even further, techniques like [coroutines and fibers](/blogs/php-coroutines-and-fibers) build on the same "keep it in memory" mindset.

Most frameworks already ship an integration so you don't hand-write this. Laravel has Octane (which supports FrankenPHP as a backend), and Symfony has a runtime component. You usually just install a package and point the server at it.

## The catch: state now leaks between requests

There is no free lunch. The whole point of the classic model was that each request starts clean. In worker mode, **the process lives across many requests**, so anything you leave lying around sticks around too.

Two things to watch:

- **Global and static state.** A static variable, a singleton holding request-specific data, or a global you mutate will carry over to the next visitor. That can leak one user's data into another user's response — a real bug, not just a performance issue.
- **Memory growth.** Small leaks that never mattered in a short-lived request now accumulate. This is why the loop above respects a `MAX_REQUESTS` limit: workers are recycled periodically so any slow leak gets reset.

The practical rule: your per-request code must not depend on, or pollute, long-lived state. Well-structured apps that already lean on dependency injection tend to adapt easily. Older code full of globals needs more care.

## When is it worth it?

Worker mode shines when **bootstrap cost dominates** — big frameworks, lots of service wiring, high request volume. If your app is a thin script that barely boots anything, the gain is small.

A sensible way to decide:

1. Measure first. Look at how much of your response time is framework bootstrap versus actual work (a profiler or even simple timers will tell you).
2. Try FrankenPHP in plain mode first — you get the simpler single-binary deployment and HTTP/3 with zero code changes.
3. Move to worker mode once you're confident about your app's state handling, and load-test it before shipping.

## Takeaways

- The traditional PHP model rebuilds everything on every request; that bootstrap is a real cost at scale.
- FrankenPHP gives you a single-binary server (easy win) and worker mode (the big performance win).
- Worker mode keeps your app booted in memory and loops over requests — fast, but it breaks the "clean slate" assumption.
- Audit global/static state and recycle workers to stay safe.

You don't have to rewrite anything to start. Run your existing app on FrankenPHP in plain mode, measure, and reach for FrankenPHP worker mode when the numbers say it's worth it.

## Resources

- [FrankenPHP documentation](https://frankenphp.dev/docs/)
- [FrankenPHP worker mode guide](https://frankenphp.dev/docs/worker/)
- [Laravel Octane](https://laravel.com/docs/octane) (uses FrankenPHP as a backend)


Category: PHP

Understanding PHP Fibers and Coroutines

FrankenPHP Worker Mode: Making Legacy PHP Fast