krakjoe
Test failures with PHP 8.3
Using 8.3.0RC1
TEST 130/134 [tests/sync/002.phpt]
========DIFF========
object(parallel\Sync)#%d (%d) {
002- ["value"]=>
003- int(42)
}
005- object(parallel\Sync)#%d (%d) {
006- ["value"]=>
007- int(42)
object(parallel\Sync)#%d (%d) {
}
========DONE========
FAIL Check sync get/set [tests/sync/002.phpt]
TEST 131/134 [tests/sync/003.phpt]
========DIFF========
object(parallel\Sync)#%d (%d) {
002- ["value"]=>
003- int(42)
}
========DONE========
FAIL Check sync notify one [tests/sync/003.phpt]
Hey @remicollet, do you know if these tests will be fixed, I really think this extension is worth keeping up-to-date?
@krakjoe any idea about parallel and 8.3 ?
May be related to new stack management (zend_call_stack_init) but can't find any solution
It seems @krakjoe is MIA. Possibly no longer with us. Would be nice to fork this and continue their work both because it is useful and because @krakjoe would like for his work to flourish and be used.
Anyone up to the task of forking?
@ww9 This work is HUGE for the PHP ecosystem. It brings the PHP multithreading that anyone says is missing to reality. IMO, it should be a part of the PHP core. It would be best if someone contacts @ThePHPF to reach for this.
@ww9 Also, the reference to the old pthreads extension in the official docs should IMO be removed entirely to not appear in the search engines. Every new developer googling the multithreading for PHP reaches that crap and then says that PHP is broken. 😄
@michael-rubel you are perhaps a little late to the party. Search this repo and issues/comments from Joe. He left a couple detailed messages why he stepped away. We've been using PHP threads and more recently parallel for over a decade, for CLI. One of the reasons it hasn't gained much traction is because many people incorrectly think they can or should use it for HTTP/web related stuff, that's not what it's for. Also not many folks have experience getting a ZTS build going although it has become easier over the years. In short, yea it works and works fine for us in production under heavy load on 16+ core boxes.
@tacticallinux As far as I know, he stepped away from the pthreads, but not from the parallel. Am I missing something?
Also not many folks have experience getting a ZTS build going although it has become easier over the years.
ZTS build with the parallel is a breeze on RHEL-compatible distributions. Huge thanks to @remicollet for this!
https://web.archive.org/web/20230327175920/https://blog.krakjoe.ninja/2022/11/but-is-it-burnout.html
Pretty sure there were some other issues/posts/whatever a while back of why Joe was more specifically sorta burnt on Parallel, can't seem to locate them, maybe Remi knows.
Thank you both @tacticallinux and @michael-rubel.
I'd appreciate if you could educate me on why this isn't a good fit for HTTP servers.
Also, do you think https://github.com/walkor/workerman is a good fit? I get thousands of req/s on an old laptop. From their README:
What is it Workerman is an asynchronous event-driven PHP framework with high performance to build fast and scalable network applications. Workerman supports HTTP, Websocket, SSL and other custom protocols. Workerman supports event extension.
Requires A POSIX compatible operating system (Linux, OSX, BSD) POSIX and PCNTL extensions required Event extension recommended for better performance
@ww9 I once benchmarked the workerman. It performed better than Swoole in the synthetic environment. It also shocked me, because the results were even better than the Golang's HTTP server. Again, in pure isolation. Not sure how it will work in a real-world app.
I'd appreciate if you could educate me on why this isn't a good fit for HTTP servers.
Parallel possibly has it's place if it's being used AS a HTTP server, but then it's operating as CLI. Many folks were using it behind Apache/nginx (FPM) and while it can work that way and maybe there is some odd use case for that somewhere that's not really how it's intended to be used. Apache/nginx/whatever already uses threads/workers so further threading behind those doesn't make a ton of sense. Maybe someone can argue a case for it, I dunno. We use it for long running system daemons totally unrelated to HTTP.
I suppose it comes down to your HTTP request lifetime and what you are trying to do.
Parallel possibly has it's place if it's being used AS a HTTP server, but then it's operating as CLI. Many folks were using it behind Apache/nginx (FPM) and while it can work that way and maybe there is some odd use case for that somewhere that's not really how it's intended to be used. Apache/nginx/whatever already uses threads/workers so further threading behind those doesn't make a ton of sense. Maybe someone can argue a case for it, I dunno. We use it for long running system daemons totally unrelated to HTTP.
I suppose it comes down to your HTTP request lifetime and what you are trying to do.
For non-CLI apps, it probably makes more sense to use something like Laravel Octane than rely on userland threading. However, the authors of stateful servers might try to use threading as an underlying mechanism for handling requests instead of spawning processes. Not sure if it fits reality, though.
Apache/nginx/whatever already uses threads/workers so further threading behind those doesn't make a ton of sense.
The problem with Apache or Nginx is that threading is useless on their side if the bottleneck is the PHP process that can handle only one request at a time. The rise of stateful servers began solving this problem. And by the way, the stateful server processes, are surprisingly, CLI processes. 😉
Let's hope PHP will soon get built-in high-performance web server implementation, so setups like Apache will become obsolete.