Closed withinboredom closed 4 months ago
You mean here? https://github.com/dunglas/frankenphp/blob/main/frankenphp.c#L774-L776
thpool_add_work()
should return as fast in worker or non-worker mode in theory.
Yeah, that's not the main issue (though in this case, it is an issue only because of the main issue -- if that makes sense).
The main issue is that there is only one manager-thread pulling requests from Go. You can see this clearly by putting a timer.sleep(1*time.Second)
in the go_fetch_request()
func, then curling the endpoint multiple times. In other words, we can only go as fast as one thread can context switch (hence why it is an issue at all).
My current thoughts (and I'm still working out the best way to do it) is to create "synthetic workers" that handle non-worker requests.
What happened?
There is exceptionally low performance when not using worker mode.
There is more detail in #833, but this issue is strictly about performance and does not relate to benchmarks or docker.
Build Type
Docker (Debian Bookworm)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
Relevant log output
The main issue revolves around a tight loop in
C.manager_thread
being very slow due to context switching between go/c and single threaded.The goal is to refactor how CGI mode works to take advantage of multiple cores/threads.