Performance of classic mode vs PHP-FPM

[binaryfire]

Hi all,

Just wondering if anyone has any thoughts on this: https://tideways.com/profiler/blog/testing-if-franken-php-classic-mode-is-faster-and-more-scalable-than-php-fpm

Their conclusion was that FPM and FrankenPHP in Classic mode were similar. But looking at the benchmarks more closely, it looks like FPM would actually be faster and scale better in many common web app scenarios.

Are these results as expected? I use worker mode for my own apps, but I’m trying to decide if I’d be better off sticking with FPM for third party apps that won’t work with worker mode (eg. WP).

I’m running those apps behind a load balancer that takes care of compression, early hints, SSL termination etc. So those benefits of FrankenPHP aren’t a factor in this particular decision - just performance.

I’d certainly prefer to not have to deal with things like FPM pools, but not at the expense of performance. I’ve seen a few people say FrankenPHP is faster even in Classic mode but I’m unsure about that now.

[nickchomey]

Their conclusion was that FPM and FrankenPHP in Classic mode were similar. But looking at the benchmarks more closely, it looks like FPM would actually be faster and scale better in many common web app scenarios.

In what way, exactly, do you think they drew the wrong conclusion?

[AlliBalliBaba]

Makes sense if it's only the 99th percentile. Nginx might keep most requests at lower latency and have a few that get severely slowed down or rejected. Go's net/http probably has a more 'fair' approach where every request will slow down more evenly when overloaded.

I'd probably prefer nginx's approach to go's. Realistically, you'll never reach that amount of CPU saturation with application servers though.

[henderkes]

Makes sense if it's only the 99th percentile. Nginx might keep most requests at lower latency and have a few that get severely slowed down or rejected. Go's net/http probably has a more 'fair' approach where every request will slow down more evenly when overloaded.

Aren't the results indicating the opposite? Average and median latency are better for FrankenPHP across the board, only the slowest 1% have better latency with nginx. And it might also just be a case of not immediately closing the connection, TTFB was generally faster with FrankenPHP. It could also be a case of gc cycles, requests would inherently slow down while the gc has to run. C++ doesn't have gc cycles thanks to RAII.

[AlliBalliBaba]

Hmm maybe you're right, would need to see the actual distribution. Could be that random GC slows down the 1%

[TimWolla]

C++ doesn't have gc cycles thanks to RAII.

Neither nginx, nor HAProxy, nor FPM are written in C++.

From what I found, it's only 99% latency that is sometimes worse with FrankenPHP, average latency was always lower.

The raw Vegeta output in TFA shows better latency for nginx+FPM across the board for the “50 kB of HTML” example: https://gist.githubusercontent.com/DianaSchef/f838ef1572e3d7e5dbc1f92d14c91fda/raw/2df024d10eae4e3205d332d277021dbcd8cbb78d/01_html-response.txt (I got even better results with HAProxy).

(Edit: Wrong link)

[henderkes]

I was speaking about my own benchmarks, our results were slightly different.

I'll try to build two (three) dockerfiles tomorrow, to automate the testing and run it on my dedicated server, rather than local hardware.

Neither nginx, nor HAProxy, nor FPM are written in C++.

Silly me, I thought nginx was writen in C++, but I guess it's C. Either way, no gc.

[henderkes]

I’d certainly prefer to not have to deal with things like FPM pools, but not at the expense of performance. I’ve seen a few people say FrankenPHP is faster even in Classic mode but I’m unsure about that now.

Not to a measurable extent, if one at all. 99% of the execution time in php projects is inside php. Both FrankenPHP and php-fpm use the same, official php runtime, except that FrankenPHP uses the ZTS instead of the NTS version. With PHP 8.4/8.5 that difference is around 0.1% average, up to at most 0.5% in my testing in favour of NTS using phoronix-test-suite and wrk on x86_64-linux. A meaningless difference that is more than made up for by better compilation options (such as -O3 instead of -O2). FrankenPHP also has the added benefit of not relying on unix sockets to communicate with another service, so the two are virtually identical.

You should however try not to use the static binary we provide. It's compiled with -Os -march=generic, targeting glibc 2.17, so we're intrntionally leaving performance on the table for broader compatibility.

If you want maximum performance, compile php (and FrankenPHP) from source with -Ofast -march=native and some extra aggressive optimisations. If you want great performance that's compiled for your platform, look at https://rpms.henderkes.com. The el9 version is compiled with -march=x86-64-v2, the el10 with -v3, as that's the platform requirement. If you want php-fpm, just use your system provided version. We're looking at 5% performance difference at most, that's just not worth the hassle of the first option imo.

Tl;dr: no performance difference between FrankenPHP (non-worker) and php-fpm. Prefer better compilation options instead.

[tkrtmy]

@henderkes Hi!

Apologies for piggy-backing on this thread, but since the static-php repository is being discussed here, I wanted to ask if there are any plans to add Amazon Linux 2023 (el2023) support?

Currently, the repo supports el7, el8, el9, and el10, but Fedora-based Amazon Linux 2023 isn't available yet. Amazon Linux 2023 is widely used in AWS environments, so it would be really helpful to have official support for it.

When trying to install on Amazon Linux 2023 (aarch64), I'm getting a 404 error when dnf tries to access:
https://rpm.henderkes.com/aarch64/el2023.x.xxxxxxxx/repodata/repomd.xml

Would this be possible to add?

Thanks for the great work on the repository!

[henderkes]

Hi @tkrtmy what glibc version does it run on?

[tkrtmy]

According to https://docs.aws.amazon.com/linux/al2023/ug/core-glibc.html, Amazon Linux 2023 uses glibc 2.34.

[henderkes]

Added a redirect to the el9 packages. Please try again!

[tkrtmy]

Wow, that was incredibly fast! Thank you so much for the quick response!

Just tested it and confirmed it's working perfectly! Really appreciate your help! 🙏

[bukka]

So it means that I just need to add worker mode to FPM and we are on par? :) That won't happen in 8.6 but it should introduce better event loop bits for that so maybe 8.7 could bring it in but we will see. It's not actually that difficult to add.

[henderkes]

I would be surprised if that weren't the case, in the end performance of all the worker modes with default php runtimes are very close to each other. The way the worker scripts are handled is but an implementation detail that (if done properly) shouldn't really have an effect on performance.

[henderkes]

So I just did my own benchmarks to verify the results and they... somewhat line up? Although my figures are rather low...

Edit: xdebug was on, ignore.

Testing nginx vs frankenphp php-server --root=./:

Test	FPM req/s	FrankenPHP req/s	FPM 99% (ms)	FrankenPHP 99% (ms)
Code1	12683.76	12263.79	0.628	1.35
Code2	12508.75	12291.24	1.12	1.33
Code3	11508.11	10667.54	1.27	1.49
Code4	20815.43	19433.15	0.542	0.74

[henderkes]

Disabling it doesn't seem to change too much:

Test	Server	Req/s	Req/s Δ%	Avg Latency	50%	99%	Latency Δ%
Code1	Nginx+FPM	12896.45	0%	617.97µs	590µs	1.01ms	0%
Code1	FrankenPHP	17230.37	+33.6%	464.34µs	443µs	0.98ms	-24.9%
Code2	Nginx+FPM	12912.65	0%	617.04µs	592µs	1.00ms	0%
Code2	FrankenPHP	17351.71	+34.4%	460.86µs	441µs	0.97ms	-25.3%
Code3	Nginx+FPM	11693.88	0%	681.91µs	648µs	1.22ms	0%
Code3	FrankenPHP	14777.14	+26.4%	541.38µs	513µs	1.09ms	-20.6%
Code4	Nginx+FPM	20861.63	0%	380.94µs	372µs	538µs	0%
Code4	FrankenPHP	28696.03	+37.5%	279.60µs	264µs	695µs	-26.6%

[bukka]

what's the nginx and fpm config?

[henderkes]

what's the nginx and fpm config?

server {
    listen 80;
    root /var/www/html;
    index index.php;
    access_log off;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_keep_conn on;
    }
}

pm = dynamic
pm.max_children = 50

(remi's default config). I updated the results with static and 64 down below which resulted in a much smaller difference.

[bukka]

You could try to increase even more (over 100) and see if increasing pm.start_servers will make any difference. Althoug sometime higher max can have negative effect. There are some others like pm.max_spawn_rate that might have effect but depeneds on workload. The main killer is often pm.max_requests if it's set to low value but think it's disabled by default even in Remi's config so that should be fine.

It would be interesting to see if UDS is really faster than localhost. UDS used to be faster but I'm not sure it's still the case.

[henderkes]

I've tried with both frankenphp and php-fpm between 64 and 256 threads/processes and got inconclusive changes (+/- 0.1%). Don't really want to faff around with tcp vs uds, but I doubt the latter is slower, so it should be fine.

[henderkes]

Trying to recreate the results with similar configuration, using wrk -t8 -c8 -d60s --latency http://localhost:80/Code1.php:

php-fpm from remi modular EL10 repo, nginx from EL10 repo:

PHP 8.4.14 (cli) (built: Oct 21 2025 19:23:55) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Remi's RPM repository <https://rpms.remirepo.net/> #StandWithUkraine
Zend Engine v4.4.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.14, Copyright (c), by Zend Technologies

FrankenPHP from my own repo:

PHP 8.4.14 (cli) (built: Oct 24 2025 03:24:04) (ZTS gcc 14.2.1 x86_64)
Copyright (c) The PHP Group
Built by Static PHP <https://static-php.dev> #StandWithUkraine
Zend Engine v4.4.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.14, Copyright (c), by Zend Technologies

php-fpm config: (systemctl start php-fpm systemctl start nginx)

pm = static
pm.max_children = 64

Nginx config:

server {
  listen 80;
  root /var/www/html;
  index index.php;
  access_log off;
  location / {
      try_files $uri $uri/ =404;
  }
  location ~ \.php$ {
      try_files $uri =404;
      fastcgi_pass unix:/run/php-fpm/www.sock;
      fastcgi_index index.php;
      include fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_keep_conn on;
  }
}

Caddyfile (frankenphp run -c Caddyfile)

http://
php {
        root /home/m/bench
}

Results (markup with AI):

Test	Server	Req/s	Req/s Δ%	50%	99%	99% Δ%
Code1	Nginx+FPM	15305.53	0%	503µs	0.91ms	0%
Code1	FrankenPHP	17230.37	+12.6%	443µs	0.98ms	+7.7%
Code2	Nginx+FPM	15189.62	0%	507µs	0.93ms	0%
Code2	FrankenPHP	17351.71	+14.4%	441µs	0.97ms	+4.3%
Code3	Nginx+FPM	14938.70	0%	505µs	1.39ms	0%
Code3	FrankenPHP	14777.14	-1.1%	513µs	1.09ms	-21.6%
Code4	Nginx+FPM	28465.21	0%	273µs	437µs	0%
Code4	FrankenPHP	28696.03	+0.8%	264µs	695µs	+59.0%

[henderkes]

I've created a hacked-together repo to simplify testing a bit:

https://github.com/henderkes/frankenphp-benchmarks

Wasn't able to get many readings out yet, my machine had tremendous issues with caddy when using more than 25 connections with wrk.

[withinboredom]

There are only so many sockets set aside on WSL2 for WSL2, I always have to run it on a real linux machine.

[henderkes]

That was a virtual machine, not WSL2 and it only affected Caddy, not Nginx. I'll get around test on real hardware... tomorrow, I hope.

[binaryfire]

@henderkes If possible, testing on an IaaS VM (DO, Hetzner etc) would be ideal since that’s what the majority of people are running these services on.

[henderkes]

I did some testing on a Hetzner dedicated and Oracle's free tier Ampere A1. See below. I think these latency figures aren't actually representative and artificially inflated, given that FrankenPHP serves more requests in the same time than Nginx.

[henderkes]

Seems like the >25 connections "issue" wasn't limited to the local machine there, but also happens on my other pc, ionos vps (0.5vcore, so ignore) and 4 core oracle VM. RPS is higher but latency shoots through the roof - I guess that's what @withinboredom was saying with connection closing becoming extremely delayed?

Edit: caddy + fpm shows similar latency to FrankenPHP, but serves RPS roughly comparable (~-10%) compared to nginx.

Picture dumping because I can't get it nicely formatted on GitHub:

[henderkes]

I'll have to revert to using wrk to test that. Hold on a minute,

[nickchomey]

Also, if you're running WordPress or anything that actually does more than 2-3 lines of php code, you're never going to see a meaningful difference in webserver choice, anyhow. Remember that these examples are serving 30k "Hello World!" requests per second. Plop WordPress in that without plugins and we're looking at 2k.

More like 20, likely less depending on hardware

[henderkes]

Really? My rather large Symfony project reaches 2-10k RPS depending on how complex the route is (when I disable session locks). Given, that is with worker mode, but I was under the impression that wordpress itself is quite performant.

[withinboredom]

WordPress itself is pretty performant (1ms homepage load times with a vanilla installation). It’s once you start installing plugins that things start to become an issue.

[nickchomey]

1ms? You're using a different WordPress than the rest of the world... You're off by more than an order of magnitude...

See near the bottom
https://make.wordpress.org/core/2025/11/18/wordpress-6-9-frontend-performance-field-guide/

Or are you talking about something different?

And given that no one uses WordPress without plugins, it only gets slower. Moreover, the only requests that should ultimately actually hit wp are necessarily dynamic (otherwise they hit one of various caches), which require heavier plugins and more db queries.

And if symfony is using worker mode, then that's just an entirely different, incomparable situation.

[henderkes]

@withinboredom setting GOMAXPROCS to high values seems to affect the whole thing very negatively.

[withinboredom]

Finally, found the smoking gun...

1. Goroutine A (created at t=0) lands on busy listener P with 18 others
2. Goroutine B (created at t=1ms) gets work-stolen to idle P
3. Goroutine B runs immediately, tries to send on channel, blocks in sendq
4. Goroutine A finally gets scheduled at t=10ms, tries to send, blocks in sendq after B
5. When workers receive, they dequeue in order: B, then A

This is pretty well documented behaviour. So, not a "bug" per se. I should have a PR here in a bit to address this in a bit. I've already reduced p99 latency by 50%, but I think I can get it down further.

[henderkes]

Give me a mention and I'll rebuild and test.

[withinboredom]

Also check my PR

[henderkes]

Waiting until you're ready with your changes, got something else I'm working on atm.

[withinboredom]

all tests are green on #2016 if you want to give it a whirl. Workers need a slightly different treatment, so I'll tackle that tomorrow.