Benchmarking on Luther Monson

Fourth Place in Worker Mode, and Why It Wasn't PHP

Thu, 15 Oct 2026 19:45:00 -0700

We added ePHPm to the Yii3 runtime benchmark. It runs the same Yii3 API app on a bunch of PHP runtimes and compares them. Our fork with the ePHPm runner is ephpm/app-api.

Most of the results were good. ePHPm came first in classic mode and first on the database endpoint in both modes. Classic mode is the PHP-FPM style, where every request starts fresh.

Worker mode was the surprise. In worker mode the app boots once and stays in memory, like Octane or FrankenPHP’s worker mode. We came fourth of ten at about 50.7k requests a second. Workerman (~65k) and Swoole (~62k) were ahead.

P99 From 280 ms to 58 ms by Making the Queue Fair

Mon, 07 Sep 2026 19:45:00 -0700

A third-party Laravel runtime comparison put ePHPm’s worker mode at the top on throughput. It was about 19% ahead of FrankenPHP on /api/static. It was also at the bottom of the fast group on tail latency, with a P99 of 157 ms against FrankenPHP’s 57 ms. Best throughput plus the fattest tail is a shape worth chasing, because fast execution can’t produce it. Making requests faster lowers the mean and the tail. Only waiting can pull them apart. Specifically, unfair waiting.

Stop Running PHP on tokio's spawn_blocking - Own Your Thread Pool

Fri, 04 Sep 2026 20:30:00 -0700

For most of its life, ePHPm ran every PHP request on tokio’s spawn_blocking pool. It works. It passes tests and it serves benchmarks fine. It’s the first thing anybody reaches for when they need to call blocking code from async Rust. It’s also quietly wrong for a language runtime. The problems only show up under overload or after a crash. Over the last three weeks it got replaced with a pool of OS threads that ePHPm owns. That pool shipped first behind a config flag, then as the default. As of v0.9.0 the spawn_blocking engine is gone.

What Does One More WordPress Site Cost?

Tue, 25 Aug 2026 20:20:00 -0700

ePHPm v0.7.0 shipped per-site multi-tenancy. Point [server] sites_dir at a directory and every Host maps to its own docroot and its own Turso database file. One process serves all of them. The first question anybody asks about that is “how many sites fit on a box?” The honest way to answer it is to turn the question around. What does one more site cost? If you know the marginal RAM, file descriptors, CPU and disk for a tenant, the box size falls out of arithmetic.

What an Overloaded PHP Server Actually Returns

Mon, 24 Aug 2026 19:40:00 -0700

Ask most people what their PHP server does when it’s overloaded and you’ll hear “it returns 503s.” Ask them how they know and it usually comes down to a config setting they read about. I was in that camp for ePHPm. We had a [server.limits] max_connections knob, and the docs said it returned 503 at the cap. Every benchmark we had ever run reported zero errors under heavy load. Then I wrote a load generator that could produce overload. The honest answer was that an overloaded ePHPm returned nothing at all.

My Benchmark Was 4x Wrong Because of WSL

Thu, 20 Aug 2026 20:45:00 -0700

I do most of my benchmarking on a Windows box in WSL2. It’s the machine on my desk with 32 threads and 62 GB of RAM. Everybody who does that learns the first rule early: don’t put your data on /mnt/c. DrvFs is the 9p-backed mount that exposes the Windows drives inside WSL, and it’s slow for file-heavy work. So the databases, the docroot and the build output all live on the WSL ext4 disk. My scaling harness for ePHPm even says so in capital letters in its README.