Serve 100× more users
on one machine

The problem with php-fpm: Whether opcache is enabled or not, the vast majority of production PHP code is I/O-bound. Workers wait for the database, the filesystem, an API call. During that wait, the worker is doing nothing — but it’s holding 30–60MB of RAM. On a 4GB server, fpm gets maybe 80 workers. Each one blocks on a 200ms query. That’s the ceiling.

The problem with Swoole, RoadRunner, and FrankenPHP: They try to solve this by making PHP evented, like Node.js. But that means rewriting your code to use their async libraries. Every PDO::query(), every file_get_contents(), every curl_exec() in every WordPress plugin and Laravel package uses blocking I/O. It doesn’t yield. Swoole can’t help with code that doesn’t cooperate.

How Qbix solves it: Instead of making each worker do more, run more workers. The server loads your framework into a parent process, then calls pcntl_fork(). The kernel marks every page copy-on-write. Each worker shares the parent’s loaded classes and only pays for pages it writes to. A WordPress-like request dirties 30 pages = 120KB. The same 4GB that gives fpm 80 workers gives Qbix thousands.

Your code runs unmodified, in two modes:

Persistent workers (default) — workers stay alive across requests. 27 functions are rewritten as files load. Static properties restored from snapshot in 0.03ms. This is the fast path: 2,294 req/s on CPU-bound work.

Fork-per-request — for code the shim can’t track (functions with internal static variables, plugins that register untrackable global state). Each request gets a fresh fork. Slower than persistent mode, but each worker still costs only 120KB instead of 50MB — so you can run 100× more workers than fpm on the same hardware. That’s the whole point.

Even on Windows — where fork isn’t available, the server runs persistent workers with the same 27-function rewriting. You don’t get COW memory savings, but you get the same code compatibility and the same control panel.

We proposed this for PHP core as switch_global_context(). While that works its way through the RFC process, the server does it in userland today.

CPU-bound (WordPress-like workload, same 200MB):

I/O-bound (50ms database query):

I/O-bound (200ms — real database load):

* Swoole coroutines require Runtime::enableCoroutine() and coroutine-aware drivers. Unmodified WordPress/Laravel uses blocking I/O and hits fpm’s ceiling.

Workers are persistent — they handle thousands of requests without restarting. Between each request, a Reflection-based snapshot restores all static properties in 0.03ms. 27 PHP functions are rewritten as each file is loaded, before PHP compiles it:

header(), setcookie(), session_start(), move_uploaded_file(), ini_set(), register_shutdown_function(), set_error_handler(), spl_autoload_register(), putenv(), and 18 others — all tracked per request and cleaned up between requests.

Unmodified WordPress, Laravel, Symfony, and Drupal get shared-nothing safety automatically. No adapters, no code auditing.

Full compatibility details → · What gets rewritten in each framework →

One machine. No database server, no Redis, no Node, no Docker. Add a second with DNS failover for redundancy — distributed mode keeps both SQLite copies in sync.