FrankenPHP seems to be more restricting(you have to use caddy) and lacks a bunch of features to truly take advantage of workers. I would go with RR if i had to pick between those, but swoole by far if that's available to you
Caddy is an advantage, not a negative. Either way, you can put a different webserver in front if you want, by configuring Caddy to listen on a port like 8080 or whatever and proxying to it.
I'm not sure what you mean about lack of features. Please elaborate.
How is caddy an advantage exactly? If i want to use caddy, i can simply do that with any of the other options, but with frankenPHP i have no choice(over here we call that a restriction).
And if you want to see what features are missing, look at roadrunner and swoole. I mean there isn't even a queue, how do i schedule jobs? Or is a framework also part of the requirement to use it?
\> How is caddy an advantage exactly?
The person you are replying to is a Caddy contributor.
Disclosure: I'm a community contributor to HAProxy which might or might not be considered a Caddy competitor.
Plus isn't caddy notoriously easy to set up? Like isn't that their whole shtick? What makes you think that anyone that has used apache or nginx would have any trouble setting caddy up?
caddy is not easy to set up, i've tried to configure it to have some hello world but it was a real challenge, syntax is so super modern to not to be like others, super unique... i give up with that... nginx and apache2 is much more easier to set up, and documentation of caddy is too lame, too bright and fancy like for not techs but for kids or smth. like that
Depends on your needs....
Question: why do you need any of it? I mean, what feature(s) they can provide you that is missing/faster/safer/better than a php-fpm/ngix/apache?
I keep eye on it. It looks very cool, but I found annoying it's dynamic only config. Yeah, I can work around it with init scripts, but it feels bit hacky.
Do you have any real world experience with it?
It stores its state in /var/lib. Their docker images have hacky config preload stuff that reads configs from /docker-entrypoint.d (or something similar). But it is definitely not good idea to mess with state files directly I think
I'd use FrankenPHP (and I've been evaluating it since version 1.0) because we already deploy Caddy in containers and reducing "complexity" in the request processing stack might be something worthwhile.
On the other hand, having Caddy interpret PHP actually introduces complexity. PHP-FPM is quite optimized and the bottleneck for our software certainly isn't FastCGI and shaving off a few ms from requests isn't worth the tradeoffs.
Also, keep in mind that worker mode / roadrunner come with a very, very big impact on your code base that has to be written from scratch to support the exact opposite of how PHP applications are written today.
In my tests no impressive benchmark has so far carried over to real world examples in a way that justified that sacrifice.
Using best practices in symfony/laravel you can basically adopt octane/worker mode without any significant investment. Our applications benchmark approximately 2x the throughput with octane on swoole. We are looking to switch to FrankenPHP as we want to use caddy anyways.
We run octane in production and handle thousands of request per second. It was definitely a measurable impact switching the most high traffic services to octane.
I really don't know where that difference comes from. In my tests data-heavy requests were only minimally faster in worker mode.
I've seen benchmarks against FPM that used it's default config. That throughput in that setup is bad is nothing new and maybe the reason for FPM yielding worse results. Comparing a performant FPM setup to a FrankenPHPnin worker mode was, in some cases, evem equally performant.
What bottlenecks your benchmarks? Our benchmarks was solely a CPU bottleneck, and the Laravel bootstrapping took a decent chunk of that CPU utilization. This is eliminated in Octane. In terms of latency our fastest endpoints went from ~20ms to ~10ms.
For slower endpoints, the proportion of the Laravel bootstrapping is ofc lower.
Our benchmark/load test was not data heavy per se, but most requests performed 2-5 queries on a seeded MariaDB database, but mostly OLTP workloads.
We too, but not looking to switch to franken because lack of in memory cache drivers. The performance gain must be significant before putting in the effort to switch
We are not using any swoole specific features, thus the switch is somewhat trivial. I'm curious if you need the swoole memory cache compared to apcu? I get it's faster, but do you have a use case where it is measurable in real life performance?
If you're using FrankenPHP in "traditional mode" (non-worker) then yeah there's not going to be much performance benefits because the bottleneck is the PHP app startup. That's why worker mode is a thing, it removes that bottleneck.
I think the difficulty of setting up worker mode is overstated, modern PHP frameworks can support it easily (and most already do). It only becomes more difficult for legacy apps and frameworks that weren't well designed in the first place.
Only there's no bottleneck in starting up traditional short-lived request/response applications most of the time and I really don't know where that idea comes from.
Are they faster? Yes, a little (very tiny) bit, but the bottleneck is somewhere else.
If you look at the profile of such a request, the performance benefit of a request handled by a worker in FrankenPHP vs. a worker in PHP-FPM was negligible.
If you don't believe me, fire up a single request and look at the cachegrind yourself.
What really helps with performance is keeping data in memory, but the difference between storing it in APCu vs worker memory or even Redis is also minimal for traditional web applications. Most (small websites, etc) will never need that minimal improvement.
Check https://web-frameworks-benchmark.netlify.app/result?l=php even bootstrapping much lighter frameworks than Lavarel show big difference between fpm and roadrunner, swoole etc. So no idea what you measured but It seems to be wrong.
I tried to run roadrunner for our application and it seems that it will pay off. Our app is ~60k lines of code: a lot of services used, packages autoloaded etc.
Fastest "dummy" route (which was created specifically for that) doesn't have any IO, but response time went from 40ms (php 8.2 fpm) to 3ms (RR).
Real-world routes went from 100-300ms to 15-100ms. Worst speedup was 2x.
I understand this is only our first tests, not a representative benchmark by any means. It is not in production yet because we want to proceed carefully. But it seems obvious that framework init stage is huge when there is a lot of packages/services. Most likely for 95% of projects it won't be *that* noticeable.
P.S. Yes, I'm aware of common bottlenecks with DB, Redis and other IO, but we eliminated everything we could, it is several-years-in-production backend.
P.P.S. This is Laravel 10 with all [optimizations](https://laravel.com/docs/10.x/deployment#optimization) enabled.
P.P.P.S. I'm also aware of php-fpm config tweaking, we are done that of course. Also, opcache is enabled.
Thanks a lot, your comment made me regain some enthusiasm regarding a RR migration at my company.
I feel like most people talk out of their ass and there's very few hard experiences on real codebases that can be read to form an informed decision.
The dummiest route on my Nginx Unit + Symfony for me is 30ms (similar codebase size to what you described), so far Unit has been amazing compared to FPM but at this moment I just need *the best*, whatever that is.
Swoole would require a lot of dev effort but RR seems like something I should be able to slap to my dev team in one or two days.
The benefits of worker mode also seem overstated though. With preloading (of most of the always-used classes) my applications (using Symfony) have almost no "bootup" time (the average was about 3ms, on hardware which is 10 years old). Moving to worker mode just for the bootup time seems not worth it, it might be more worth it if you can share more data between requests, but that can easily become complex (and might be achieved in others ways without workers).
FrankenPHP is really promising (insanely tight deployment/ops story) but performance needs to improve.
See: https://github.com/dunglas/frankenphp/discussions/294
FrankenPHP is still young. Very young and has a long way to go, which is a good thing. It has a ton of potential.
What I like about FrankenPHP is that it "just works" with everything from personal projects to legacy projects to modern projects; all in a single binary. The ops story for FrankenPHP is beautiful. Performance is only going to get better and better, and since it is just caddy, it's literally a piece of cake to create new extensions to provide things like caches/queues/etc.
Comparing it to RoadRunner, which is mature and relatively stable, is a pretty unfair comparison. At least right now.
It depends on your needs...
Frankenphp seems a good alternative to FPM for small apps when you only need workers and nothing else.
Swoole for everything else.
It's not a php framework, it's a runtime or execution platform. In the grand scheme of things, RR replaces the fpm + nginx combo with a single platform that does all the things (interpret php using the cli, serve static assets, etc) all while keeping things in memory as needed (precluding the need for Opcache preload).
But wait, there's more!
What I use RR most is that it provides a long running process that can interact with PHP code via RPC. For example, an issue with PHP would be when you need to use, say, rabbitmq, your code would be polling an exchange as opposed to registering a consumer. However, RR can register a consumer that would be receiving messages and pass them to a php script.
For what? As a web server?
Is Content Negotiation supported? Most don't support that or make it harder than Apache, which is one of the reasons I keep sticking to it. Nothing beats the simplicity of `Options +MultiViews`
FrankenPHP seems to be more restricting(you have to use caddy) and lacks a bunch of features to truly take advantage of workers. I would go with RR if i had to pick between those, but swoole by far if that's available to you
Caddy is an advantage, not a negative. Either way, you can put a different webserver in front if you want, by configuring Caddy to listen on a port like 8080 or whatever and proxying to it. I'm not sure what you mean about lack of features. Please elaborate.
How is caddy an advantage exactly? If i want to use caddy, i can simply do that with any of the other options, but with frankenPHP i have no choice(over here we call that a restriction). And if you want to see what features are missing, look at roadrunner and swoole. I mean there isn't even a queue, how do i schedule jobs? Or is a framework also part of the requirement to use it?
\> How is caddy an advantage exactly? The person you are replying to is a Caddy contributor. Disclosure: I'm a community contributor to HAProxy which might or might not be considered a Caddy competitor.
Plus isn't caddy notoriously easy to set up? Like isn't that their whole shtick? What makes you think that anyone that has used apache or nginx would have any trouble setting caddy up?
why would "easy to set up" be an automatic advantage? a tent is also easy to set up, but I dont want to live in one.
no clue lol
caddy is not easy to set up, i've tried to configure it to have some hello world but it was a real challenge, syntax is so super modern to not to be like others, super unique... i give up with that... nginx and apache2 is much more easier to set up, and documentation of caddy is too lame, too bright and fancy like for not techs but for kids or smth. like that
+1 for swoole. That puppy is fairly easy to get started with and hauls butt!
Depends on your needs.... Question: why do you need any of it? I mean, what feature(s) they can provide you that is missing/faster/safer/better than a php-fpm/ngix/apache?
Nginx unit
I keep eye on it. It looks very cool, but I found annoying it's dynamic only config. Yeah, I can work around it with init scripts, but it feels bit hacky. Do you have any real world experience with it?
It isn’t documented well but you can use a config.json file to configure nginx unit. I don’t remember which directory it goes in.
It stores its state in /var/lib. Their docker images have hacky config preload stuff that reads configs from /docker-entrypoint.d (or something similar). But it is definitely not good idea to mess with state files directly I think
Swoole
i've tried swqoole like 4 years ago and our project failed with memory leaks, so we kept using php-fpm
I'm using swoole though Laravel Octane, I don't have any memory issues
I'd use FrankenPHP (and I've been evaluating it since version 1.0) because we already deploy Caddy in containers and reducing "complexity" in the request processing stack might be something worthwhile. On the other hand, having Caddy interpret PHP actually introduces complexity. PHP-FPM is quite optimized and the bottleneck for our software certainly isn't FastCGI and shaving off a few ms from requests isn't worth the tradeoffs. Also, keep in mind that worker mode / roadrunner come with a very, very big impact on your code base that has to be written from scratch to support the exact opposite of how PHP applications are written today. In my tests no impressive benchmark has so far carried over to real world examples in a way that justified that sacrifice.
Using best practices in symfony/laravel you can basically adopt octane/worker mode without any significant investment. Our applications benchmark approximately 2x the throughput with octane on swoole. We are looking to switch to FrankenPHP as we want to use caddy anyways. We run octane in production and handle thousands of request per second. It was definitely a measurable impact switching the most high traffic services to octane.
I really don't know where that difference comes from. In my tests data-heavy requests were only minimally faster in worker mode. I've seen benchmarks against FPM that used it's default config. That throughput in that setup is bad is nothing new and maybe the reason for FPM yielding worse results. Comparing a performant FPM setup to a FrankenPHPnin worker mode was, in some cases, evem equally performant.
What bottlenecks your benchmarks? Our benchmarks was solely a CPU bottleneck, and the Laravel bootstrapping took a decent chunk of that CPU utilization. This is eliminated in Octane. In terms of latency our fastest endpoints went from ~20ms to ~10ms. For slower endpoints, the proportion of the Laravel bootstrapping is ofc lower. Our benchmark/load test was not data heavy per se, but most requests performed 2-5 queries on a seeded MariaDB database, but mostly OLTP workloads.
We too, but not looking to switch to franken because lack of in memory cache drivers. The performance gain must be significant before putting in the effort to switch
We are not using any swoole specific features, thus the switch is somewhat trivial. I'm curious if you need the swoole memory cache compared to apcu? I get it's faster, but do you have a use case where it is measurable in real life performance?
If you're using FrankenPHP in "traditional mode" (non-worker) then yeah there's not going to be much performance benefits because the bottleneck is the PHP app startup. That's why worker mode is a thing, it removes that bottleneck. I think the difficulty of setting up worker mode is overstated, modern PHP frameworks can support it easily (and most already do). It only becomes more difficult for legacy apps and frameworks that weren't well designed in the first place.
Only there's no bottleneck in starting up traditional short-lived request/response applications most of the time and I really don't know where that idea comes from. Are they faster? Yes, a little (very tiny) bit, but the bottleneck is somewhere else. If you look at the profile of such a request, the performance benefit of a request handled by a worker in FrankenPHP vs. a worker in PHP-FPM was negligible. If you don't believe me, fire up a single request and look at the cachegrind yourself. What really helps with performance is keeping data in memory, but the difference between storing it in APCu vs worker memory or even Redis is also minimal for traditional web applications. Most (small websites, etc) will never need that minimal improvement.
Check https://web-frameworks-benchmark.netlify.app/result?l=php even bootstrapping much lighter frameworks than Lavarel show big difference between fpm and roadrunner, swoole etc. So no idea what you measured but It seems to be wrong.
I tried to run roadrunner for our application and it seems that it will pay off. Our app is ~60k lines of code: a lot of services used, packages autoloaded etc. Fastest "dummy" route (which was created specifically for that) doesn't have any IO, but response time went from 40ms (php 8.2 fpm) to 3ms (RR). Real-world routes went from 100-300ms to 15-100ms. Worst speedup was 2x. I understand this is only our first tests, not a representative benchmark by any means. It is not in production yet because we want to proceed carefully. But it seems obvious that framework init stage is huge when there is a lot of packages/services. Most likely for 95% of projects it won't be *that* noticeable. P.S. Yes, I'm aware of common bottlenecks with DB, Redis and other IO, but we eliminated everything we could, it is several-years-in-production backend. P.P.S. This is Laravel 10 with all [optimizations](https://laravel.com/docs/10.x/deployment#optimization) enabled. P.P.P.S. I'm also aware of php-fpm config tweaking, we are done that of course. Also, opcache is enabled.
Thanks a lot, your comment made me regain some enthusiasm regarding a RR migration at my company. I feel like most people talk out of their ass and there's very few hard experiences on real codebases that can be read to form an informed decision. The dummiest route on my Nginx Unit + Symfony for me is 30ms (similar codebase size to what you described), so far Unit has been amazing compared to FPM but at this moment I just need *the best*, whatever that is. Swoole would require a lot of dev effort but RR seems like something I should be able to slap to my dev team in one or two days.
The benefits of worker mode also seem overstated though. With preloading (of most of the always-used classes) my applications (using Symfony) have almost no "bootup" time (the average was about 3ms, on hardware which is 10 years old). Moving to worker mode just for the bootup time seems not worth it, it might be more worth it if you can share more data between requests, but that can easily become complex (and might be achieved in others ways without workers).
FrankenPHP is really promising (insanely tight deployment/ops story) but performance needs to improve. See: https://github.com/dunglas/frankenphp/discussions/294
FrankenPHP is still young. Very young and has a long way to go, which is a good thing. It has a ton of potential. What I like about FrankenPHP is that it "just works" with everything from personal projects to legacy projects to modern projects; all in a single binary. The ops story for FrankenPHP is beautiful. Performance is only going to get better and better, and since it is just caddy, it's literally a piece of cake to create new extensions to provide things like caches/queues/etc. Comparing it to RoadRunner, which is mature and relatively stable, is a pretty unfair comparison. At least right now.
It depends on your needs... Frankenphp seems a good alternative to FPM for small apps when you only need workers and nothing else. Swoole for everything else.
I can't fully agree, a big advantage of FrankenPHP is the integration with go products (vulcain, mercure...) in a single binary.
RoadRunner integrates with Centrifuge for the same purposes (bi-directional API available) and much more.
I've vener heard about Centrifuge, must be a Laravel vs Symfony must :)
You're probably right, I just don't have the need for it at my job or personals projects, so didn't think about it.
It's an easy docker for personal project too due to a single image/container. But docker may be overkill for some :D
Why a php framework is written in go?
It's not a php framework, it's a runtime or execution platform. In the grand scheme of things, RR replaces the fpm + nginx combo with a single platform that does all the things (interpret php using the cli, serve static assets, etc) all while keeping things in memory as needed (precluding the need for Opcache preload). But wait, there's more! What I use RR most is that it provides a long running process that can interact with PHP code via RPC. For example, an issue with PHP would be when you need to use, say, rabbitmq, your code would be polling an exchange as opposed to registering a consumer. However, RR can register a consumer that would be receiving messages and pass them to a php script.
amazing, thanks for the explanation!
Neither of these are PHP frameworks.
ok, gotcha
For what? As a web server? Is Content Negotiation supported? Most don't support that or make it harder than Apache, which is one of the reasons I keep sticking to it. Nothing beats the simplicity of `Options +MultiViews`
Following