How to configure amount of workers used by Standalone Binary? #558
-
I cannot figure out how to configure the amount of workers started by the Standalone Binary. Currently I use: I tried 'index.php 1', but I think this short form only works when using a Caddy file or when passing it to docker. Using Does anyone have any idea how I can accomplish this? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Just out of curiosity, why do you want to configure the number of workers this way? (mostly just trying to understand the use case). To answer your question, |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick answer! I tried it and it works for me.
I dunno about the people who know what they are doing, but personally I had 3 use-cases for this: Use case 1. A lot of the time spent in our applications is waiting for files, external databases, external redis, etc. In these cases the CPU could switch to another worker. I should note that the above considerations are based on how Swoole (which we use) works, with its explicit asynchronous support for these things. We are currently (slowly) starting our porting process, going from Swoole to FrankenPHP. But I am aware FrankenPHP might handle this differently (would love to know). Use case 2. On the other hand: we also have a few beefy servers with multiple responsibilities. Such as running jobs that might do things like process images, running a database, running redis, and of course, running the application server. In these cases we often want to have some measure of control of how many CPU's certain applications can use, to prevent all CPU's from being saturated in exceptional events, leaving nothing for the others. Use case 3. This one requires some context (and is a bit long winded, sorry). Going back to the Swoole example: you could choose a mode to run in, and in some of these modes each worker itself could also run multiple requests at the same time. This was actually the default mode it ran in (See dispatch_mode if you are interested). For our use-case, this didn't work. Because our framework was building up state during the request processing, and only during the termination event would this state be cleared. For example: writing logs to the DB would happen at the end, during the terminate event and then be cleared. When running 2 requests by the same worker at the same time, the logs would contain information about both requests, or they might be cleared during the second half of the second request. It was a disaster. FrankenPHP does not have a lot of documentation. Which is totally fine&understandable, given its age. However, because of that, I could find very little information about how workers function, and I wanted to know in what kind of 'dispatch_mode' they worked. And testing these kinds of things is easier when you can configure your local dev-env frankenphp binary to use 2 workers, instead of (in my case default) 64. |
Beta Was this translation helpful? Give feedback.
Just out of curiosity, why do you want to configure the number of workers this way? (mostly just trying to understand the use case).
To answer your question,
./frankenphp php-server --worker index.php,16 --listen 127.0.0.1:9001 -v
, would create 16 workers. (or it should, anyway).