A decade-old question about PHP's performance ceiling has a new answer. EGreg, a long-time PHP developer, released Qbix Webserver 1.2, a full web server written in pure PHP that claims to outperform not just php-fpm but also async runtimes like FrankenPHP, Swoole, and amphp, all while running unmodified PHP applications.

PHP Has Always Needed a Stack Around It

PHP's traditional deployment model involves a pile of external tools. Nginx or Apache serves static files and proxies requests to php-fpm, which manages worker processes. Certbot handles TLS certificates. Cron runs periodic tasks. Node.js handles WebSocket connections. Each tool solves a real problem, but the result is a fragile collection of moving parts that developers must configure, monitor, and keep updated.

The async PHP ecosystem offered a different path. Swoole, amphp, and FrankenPHP replaced the blocking I/O model with event-driven concurrency, delivering significant performance gains. The catch is that they require rewriting application code to use their async libraries. Most existing PHP applications, including WordPress, Drupal, and the vast universe of legacy codebases, would need substantial porting work to run on these runtimes.

Forking Instead of Events

Qbix takes a fundamentally different approach. Instead of converting blocking I/O to async, it leans into the process model. When a PHP script makes a blocking call to a database, file, or network endpoint, the thread blocks. But Qbix spawns hundreds or thousands of worker processes using pcntl_fork, so the blocked thread does not prevent other requests from being served.

The trick that makes this viable is copy-on-write memory. On Linux and macOS, forked processes share memory pages with their parent until a variable is modified. Qbix lets applications preload files and classes before forking workers, so the shared bytecode and framework code never gets duplicated. For a typical WordPress installation, each worker occupies around 140KB of memory. Compare that to php-fpm, where each worker loads a full copy of the PHP bytecode and framework, consuming roughly 40MB.

The math is straightforward. On a 4GB machine, php-fpm might run 100 workers. Qbix can run tens of thousands. If all variables fit on a single memory page, a worker can weigh as little as 4 to 16KB. That density means the server can handle massive concurrency without running out of memory, even on modest hardware.

What the Server Actually Handles

Qbix is not just a fast static file server. It handles HTTP requests, WebSocket connections, and rooms (the grouping mechanism that socket.io uses for targeted broadcasts). It supports HTTP Push for streaming, which matters for AI applications that send tokens incrementally. TLS certificate management is built in, as is cron-style periodic task execution.

The server also supports X-Accel-Redirect, a header that lets the application control file serving while offloading access control. For public static files, the recommendation is to use a CDN. For protected files, proxying X-Accel-Redirect headers to Nginx still yields a performance boost, since PHP lacks native sendfile support.

One feature that does not exist elsewhere is X-Cache-Tree, a mechanism for partial page caching. Instead of invalidating and re-rendering an entire page when one section changes, the server can invalidate and regenerate only the affected portion. The X-Cache-Invalidate header coordinates this across pages, so a single data change can invalidate multiple cached regions at once.

No Code Changes Required

The most consequential claim is that Qbix runs existing PHP applications without modification. Unlike Swoole or amphp, which require refactoring I/O calls, Qbix works with the blocking code that the majority of PHP applications already contain. If your WordPress site works with php-fpm, it works with Qbix, according to the project.

Applications that do use amphp or similar async libraries can still run on Qbix. The server detects when code uses epoll-style event loops and integrates with them, making the application even more efficient without requiring a migration away from async code.

What This Means for PHP Deployments

If the performance claims hold up under independent testing, Qbix eliminates the need for several layers in a typical PHP deployment stack. No Nginx for reverse proxying. No separate WebSocket server. No external certificate management. The visual dashboard and control panel handle configuration through a browser interface.

The standalone binaries for Linux and macOS package an entire web application into a single executable, which changes the deployment model significantly. Instead of provisioning a server, installing PHP, configuring php-fpm, and setting up Nginx, a developer can ship one binary that contains the application and the runtime.

There are tradeoffs. The pure PHP implementation means the server itself is subject to PHP's performance characteristics for CPU-bound work. The forking model works well for I/O-heavy web applications but does not help with compute-intensive tasks. And the project is new enough that it has not been battle-tested at scale in production environments.

The project is MIT licensed. Version 1.2 is available at qbixserver.com, along with documentation and download links for the standalone binaries.