Show HN: FrankenPHP, an app server for PHP written in Go
frankenphp.dev
frankenphp.dev
Litespeed's PHP LSAPI [1] shows how good performance can be with other setups. It'll be great if FrankenPHP gets to the same state.
1. https://www.litespeedtech.com/open-source/litespeed-sapi/php
Debugging application servers in production comes with its own set of difficulties, but I don't see how this one is worse than others. If anything, the ability to start new sockets without restarting the process is a plus.
PHP-FPM had been more resilient than the other services I run. Rock solid.
I feel like problems with monitoring may be down to lack of proper logging or experience. It's not like FPM is going to leak more memory than your code would in other running contexts. It doesn't "go down" since it spawns a new process for every request. My cold read is that there's something wrong with the code you're running, not with FPM.
Roadrunner executes php-cli and connects it to its web server through GRPC; FrankenPHP uses an ad-hoc SAPI, it is more like Apache's mod_php, the Go code uses the PHP interpreter as a library, it's all in the same process.
RoadRunner only has a worker mode, and can only work with compatible apps; FrankenPHP has a "standard" mode compatible with all existing applications, and a worker mode that requires some code changes (like RR).
RoadRunner runner uses PSR-7 HTTP messages; FrankenPHP uses plain old superglobals and streams (both in normal and in worker modes), they are reset after each handled request.
RoadRunner is battle-tested and production ready; FrankenPHP is experimental and not yet ready for production use.
FrankenPHP can also be used as a Go library to integrate PHP into any Go program or server (theoretically, it should be possible to integrate FrankenPHP into Traefik or the local Symfony web server, which are written in Go).
1. Most PHP frameworks are designed to have all state destroyed at the end of a request. I was trying to integrate a commercial ecommerce framework with something like Road Runner and another one that I forget the name of. The framework had a DI system which provides each module with its own private instance of all injected instances, so having a "worker" that doesn't "boot" everything each request sounded like a good idea (boot was expensive, and a lot of logic was storing module-specific state in module-private instances). I hit a few barriers inside the framework, but actually a lot of them were due to dependencies on PHP global state following state-of-the-art conventions and best practices. It lead to spooky side-effects like cache from one page view loading into the next, and worse. Getting frameworks to run in a loop in PHP can often lead to sharing state in code that was designed in a way that state is assumed to be destroyed soon.
2. PHP depends on lots of unexpected things. If you're deep into language internals already you probably know this however. I was putting symfony2 into a PHP Unikernel a long time ago, and it drove me a bit crazy because everything in the file system, SAPI, locales, etc... it was all missing bridges to something it expected the OS to provide. I ended up making an immutable FS with Nginx and PHP all static linked to each other, but it was really just enough for a POC, a real production ready env would have been a lot more effort. The point is, PHP has a lot of unexpected "hooks" into environments it has grown up around that might be well hidden.
Anyway, really cool project and I like the concept of using a SAPI, I think it has big potential.
I mean, it's not going to be as cheap as getting the thing to actually run in a loop, but it might be enough cheaper than the booting process to be worthwhile.
https://www.php.net/manual/en/opcache.preloading.php
> preload.php is an arbitrary file that will run once at server startup (PHP-FPM, mod_php, etc.) and load code into persistent memory.
It's interesting to me, because in a big ecomm framework we were getting 80ms PHP page loads, with something like preload it could probably be moved down to 25 or 30ms.
The big 'gotcha' here is that the heap is typically shared amongst threads in a process and that's where globals tend to live. However, you could make a heap per thread (which is kind of how some implementations of isolates work). You lose a bit of perf by doing this but it does deal with the global stomping problem.
We've (NanoVMs) looked at this a few times. It can be done but as bdg mentioned most frameworks expect state to be in a completely clear so the real challenge is that you have to go in and deal with each framework itself (for instance using WP as an example).
Anyways, I thought FrankenPHP was pretty cool so went ahead and package it up for Nanos: https://repo.ops.city/v2/packages/eyberg/frankenphp/0.0.1/x8... .
If you had a php framework that wasn't so dependent on global state you could definitely make something way more performant.
In general scripting languages and their usage of global state is a recurring concurrency issue but I'm hopeful that the isolate pattern will catch on in other languages to help alleviate it.
> Roadrunner executes php-cli and connects it to its web server through GRPC;
RR communicates with the PHP process via pipes (stdin/out/err) via our protocol (similar to the IP protocol, we also have a tcp/unix-socket options and shared memory is coming soon). The RR server itself then has various options to connect to the world:
- gRPC (w/o the need to install the `gRPC-php` extension), HTTP (with a lot of different middleware), HTTPS, fCGI. - Queues: kafka, rabbitmq, sqs, beanstalk, nats (with like priorities and so on) - KV/noSQL: memcached, redis, boltdb, memory. - Workflows: Temporal.
I might forget smt, but the main idea is to have a very extensible server. With very little knowledge about Go, you may extend it with your plugins and build your RR binary. Or even embed the RR server into your Go application (https://github.com/roadrunner-server/roadrunner/tree/master/...).
The traditional idea is to build a plug-in for the parent webserver. By essentially "making a fork" of Caddy, if you want to add other plugins to Caddy and then incorporate them into FrankenPHP, it's a lot more work. If instead you ship a PHP plugin to Caddy, you can manage Caddy instead and mix and match different functionality in one place.
But I guess it's heretical to suggest somebody use plugins in Go, if the whole idea is everything is a static binary.
It uses mainline Caddy: https://github.com/dunglas/frankenphp/blob/main/caddy/go.mod
I know you can using Nix for sure. I think Arch/pacman (Arch Build System) and Gentoo/portage (since it is source-based) also have this concept, but I’ve never used it. No clue about other package managers.
The downside is that package updates will require a recompilation, but you can use binary caches to centralise this slightly.
* run plugins as separate processes and expect them to implement a specific RPC api
Compiling in plugins is more practical in Go then it might be in another language, due to the regularity of the go build system.
I'v checked and unfortunately the video recording is not available for now, I will post a link here as son as available.
Is that it?
Previously, there was https://github.com/deuill/go-php which was PHP5 and PHP7, but you needed to build PHP with ZTS. I had to forke it to focus on PHP5 and bring some improvements - my primary goal was to port some legacy PHP over iteratively via the Strangler pattern. If it can still be useful to some, the fork is here - https://github.com/borancar/go-php
Some benchmarks against mod_php, nginx+php-fpm and swoole would be nice.
OPcache improves PHP performance by storing precompiled script bytecode in shared memory
Looks neat!
nginx, php-fpm, some init system, and the convoluted configuration needed to get logs out via Docker's logging mechanism.
Caddy has a supervisor plugin, so can start php-fpm itself and the containers entrypoint can be Caddy, which achieves similar objectives here that Caddy becomes a PHP application server.
But yes, the supervisor plugin is definitely nice to be able to wrap up Caddy + php-fpm in a single container. Makes shipping it easier, especially with the PHP code (because both Caddy and php-fpm need access to the code; Caddy so it can serve static files and check for the existence of PHP files, and php-fpm to actually run your code).
No one can feel 0.01s faster load time and there will be a dozen more things to tune in your app than shave that tiny bit off.
It's true it's probably not for everyone though; the worker mode will not work with legacy apps that heavily use globals and statics, and works best with frameworks that have infrastructure in place to reset in-memory state on each request. Symfony and Laravel are set up for this, for example. API Platform as well, which the author of FrankenPHP himself authored.
The decreased latency means you can serve more requests with the same hardware, with less of an energy cost. That's a win-win. It's not simply about the user experience.
Also remember that loading a webpage often takes many requests. Every little bit shaved off of one request is multiplied. Add onto this that it supports 103 Early Hints which can tell the client to start loading static assets ahead of time, this dramatically reduces total page load times because it avoids the cascade (i.e. browser needing to wait to read the HTML to know what JS/CSS to load). That definitely has a noticeable effect to users.
This pattern is common for background workers too, such as running gunicorn + celery in separate containers (Python tools) but the same image is used for both. You can change the CMD at runtime by overwriting it (for example the `command` property in Docker Compose and Kubernetes).
This avoids needing to hack around things at the Docker level to install an init system and it gives you a way to split things out at runtime so you individually scale and log them as needed.
It does mean a change in your app would restart nginx since the image would change for both but this isn't that big of a deal. If that was a deal breaker then you could create separate images for each one to still avoid an init system running in your container.
What I dislike most about php-fpm is the logging mechanism (or lack thereof). You need to configure it to capture stderr from php processes and then have PHP send logs to stderr. Sorta wonky.
I never used Fly but hosting a web + worker combo is common in a lot of tech stacks and with Docker it's really common to use 1 image to drive both containers with a different command. If Fly doesn't support that then I'd suggest hosting things elsewhere. Docker Compose and Kubernetes supports this no problem, it's a really basic / day 1 use case.
Longer answer: avoiding infrastructure setup - for those who has infrastructure it makes no sense, for those who knows how to run things in Docker and not need much beyond it - eliminates the need of getting familiar with Docker Compose.
Having php stay in memory should make performance benefits [and make sense for the project], but that's different story.
If it is Go, can I not just compile the binary and execute ?
Coupled with a packaging system, like debian gives you, this is all pretty straightforward.
I ran into this yesterday, and turns out I don't want to install docker just to build a program...
Having an "everyone gets the same thing, so no one wastes time on bootstrapping" solution is a perfect use-case for Docker. And then once the bugs have been found and fixed, and the code is production-ready, you can focus on documenting and scripting the setup procedures for the various operating systems.
Docker is definitely not necessary, but it is the easiest way to ship something that just works. Since you need a bunch of build dependencies to compile PHP, the installation steps are different for every distro to pull those in with whatever's your package manager.
My current setup is a DigitalOcean Droplet with Nginx and php-fpm.
Do you have any success story with this application server ?
What happened to the times where some crazy person would simply slap together an interpreter and call it a language?
Somehow, language creation got more and more sophisticated these days.
PHP, Ruby, and Node all use things like cURL or the same PCRE regex lib, but I've seen uninformed or misguided arguments about "how Node is better than PHP at making HTTP requests because of axios", and not "I like Axios more than Guzzle3".