PHP-FPM vs Swoole execution model
HTML-код
- Опубликовано: 13 июн 2024
- Note: I used async I/O and non-blocking I/O interchangeably, but they're not the same thing. Async I/O is a way to implement non-blocking I/O.
Note 2: I'm sorry some words are cutting off. I had my preamp improperly configured.
👨💻 Learn Test-Driven Development with Laravel!
tddwithlaravel.com
Sign up to 30 Days of Laravel 👉🏻 30daysoflaravel.com
👨💻 Sign up to my newsletter and receive PHP, JS and Laravel news in a weekly-basis:
subscribe.mateusguimaraes.com
🎉 Party up:
/ mateusjatenee
/ mateusjatenee
/ mateusguimaraes
Thanks for watching! 
Наука
Informative video, thank u so much. please continue this kind of video.❤
Does anybody know how to install swoole in macos using brew ?
Very detailed. Thanks!!!! Now you should compare swoole with frankenPHP.
Will do :-)
I wish I could like this twice.
Thank you :-)
Thank you
You're welcome
Hey dude, appreciate the video and all the effort into the quality of the presentation. Regarding FPM's manager process being blocking. You state: "It's also not very effecient, because the requests are blocking." that's not really right. I/O operations are not blocking with PHP FPM. Try executing an expensive query in one PHP request while making requests to another endpoint. You'll notice it's not blocking. But why? The reason is that there's an event loop the same way a node.js server would be able to handle many many requests simultaneously without blocking.
Note: One possible gotcha in PHP is that sometimes sessions can cause blocking due to how sessions are configured, where the session file for a user may be locked and prevent other requests from executing. Mattias Geniar has a good write up on this issue. One way to easily prevent this from affecting the test above is to open the requests in separate browsers or use incognito mode for one session.
Hey man! Thanks for the comment.
My understanding is that’s because the 2nd request is going to passed on to a different worker process.
If you limit php-fpm to a single worker process and shoot one request with expensive I/O and then another, the second one should hang until the first one is completed - that is, a single process can only handle one request at a time. If it were able to handle multiple it wouldn’t be shared nothing too.
Happy to make any corrections to the video and it’s very possible I’m wrong - can you link me any resources?
Thanks!
@ In the video around the 6:00 mark you discuss the PHP-FPM setup with many workers, so while your reply mentioning "single worker process" and "one request with expensive I/O" is correct with respect to blocking under that constraint, when you are talking about one worker for PHP FPM and multiple workers for Swoole, it's no longer a fair comparison. When comparing multiple workers with each setup, the benefits will be broadly similar, but with some tradeoffs. In the case of PHP FPM, the execution model is more stable and reliable and on Swoole's side processes are more lightweight and you don't have to run your application's bootstrap code for each request. With FPM processes, the performance cost is somewhat offset since processes are pre-forked and you don't need to create a new process for incoming requests (since a configurable number of idle workers will be waiting ready to serve requests) and additionally the Opcache is shared between all requests bringing the resources required of each process down substantially. With Swoole based setups like Laravel's Octane setup, there are specialized requirements of framework and application code so you're definitely paying a fairly significant complexity/risk tax for what I'd argue are relatively small performance improvements.
I run Apache with PHP-FPM on judyrecords it's been more than suitable for handling even extreme reddit spikes. You can see a screenshot of the server load and Apache workers at news.ycombinator.com/item?id=30481230. You can also see from scerenshot here showing memory usage is only about 500kb per PHP request. postimg.cc/TLbvvSzm
@@kevanschwitzer8585 hey - thanks for the reply.
I mentioned an example with 1 worker - if you have 50 workers and 100 requests, they’ll be processed sequentially. PHP has blocking I/O by default.
If you take the same 1 worker example with Swoole, it’ll be able to handle multiple requests concurrently. That’s the difference.
Even if FPM maintains a worker pool, you’re still limited by the fact that each worker can only handle a single request at a time. You can still have multiple requests being handled in parallel through different processes, bit that’s not what I’m talking about. The video uses multiple workers examples for both PHP-FPM and Swoole.
I don’t think the results are similar either - Swoole and FPM will have very different results in an I/O bound application. Obviously you need to have enough load for this to make a difference.
I hope that clears things up!
@ I think the main snag here is your framing of the comparison between FPM and Swoole. I think it helps to reason from first principles. Let's say you have a machine with 4 cores. That machine can only ever do up to 4 things at a time. Anything more than this is simply an illusion of parallelism -- the operating system just executes tasks so fast that it only looks like there are more than four things happening at once.
PHP FPM only has a different process model with heavier processes -- there is no inherent blocking restriction based on its design. With PHP FPM, it's one manager process and many children. With Swoole, it's multiple managers with many children. Saying that FPM blocks with 1 worker is irrelevant, because that's not how you process things concurrently in FPM. You're saying Swoole's way of processing things in parallel is better than FPMs way of processing one thing at a time. Of course it is! You need to compare FPM's way of processing things in parallel with Swoole's way of procesing things in parallel.
At this point, it becomes clear that the only difference is a heavier process model with FPM which offers much more stability and predictability. Swoole has a lighter weight process model. If you need to support a truly extraordinary request capacity and the application logic is on the light side, where the price to pay for complexity/risk of sharing memory is able to be justified, then Swoole would be a good option. For context, a stock Laravel installation is around 100,000+ lines framework of code to start, and your average application includes various third-party libraries/packages. It is unlikely that this much in framework and libraries dependencies is going to be without substantial hurdles running Swoole workers with a high-risk memory sharing model.
You mention: "Even if FPM maintains a worker pool, you’re still limited by the fact that each worker can only handle a single request at a time." But you have to remember, what defines the limit for the number of workers? There is no limit to the number of workers that can spawn as load increases -- you're only limited by the machine's capacity. At some point, a lighter weight process model will be able to give more throughput than a heavier weight process model, but fundamentally the restriction is not in the process model or anything to do with blocking.
Last thing to clarify, you mention: "Swoole and FPM will have very different results in an I/O bound application." What needs to be kept in mind here is that performance benchmarks of hello world requests (that have no actual processing) Swoole will kill FPM by comparison because there is no actual work being done in the request. It's just outputting a sentence (as light weight of an application as you can get). However, as soon as you have, say, 10 database queries the cost of each request will be dominated by the time it takes to execute database queries and the PHP code executed will become a relatively minor factor. Once this happens, the performance difference between processing models will be largely eliminated.
@@kevanschwitzer8585 well, processes are much more expensive than coroutines - another thing to mention is that in the FPM model, memory will be cleaned between requests (even if the worker is not recycled), whereas in Swoole they’re long-running.
I mention in the video that FPM’s shared-nothing model is much simpler than Swoole’s, so I think we agree here - but both are very different.
Processes are expensive and consume much more memory - you’re limited to how many processes you can spawn and even then, I/O *is* blocking at the script level.
There are many tradeoffs, and PHP-FPM is fine for the majority of projects,!but the two are definitely not similar when we’re looking at performance.
I don’t think Octane is a good example too because Laravel wasn’t made for Swoole; Hyperf is a better example.
You mentioned the 4-cores example - yes, if you have many processes, the OS will switch between tasks and execute them concurrently (even w/ 1 core), but the PHP script itself will be blocking - to handle a new request a new process will need to be spawned or resumed. This is a major difference IMO.
(Writing from my phone - sorry for any possible typos)
Awesome content. Congrats.
oh why oh why do I have to program in PHP. Great video btw
This was amazing. Please make more content like this
Thanks for the content
love these new videos.
Glad you like them!
So can you show us what changes when we write code for workers, api calls and controllers?
Very informative.
Glad you liked it
Congratulations. Is It possible to replicate this video in PT-BR?
Unlikely
Pretty good.
Thanks!
good video
Thanks
what about roadrunner ?
I have not used RR but I assume it leverages a similar execution model to Swoole, but using Goroutines.
good content, thank you for taking the time to explain this, but please work on your writing/drawing skills space things out more
Thanks, will do!