Does PHP still has that weird flow where each request is its own process? afair PHP never had an http server baked in, I remember nginx with php etc ...
Yes, each request is handled by its own process. This might sound weird if you're used to other languages, but it's how every language used to work in the good ol' CGI days. PHP doesn't break backward compatibility easily, and I don't think it will ever break this one. Besides, once you get the hang of it, PHP's execution model is highly intuitive and beginner-friendly. You simply don't have to worry about a whole class of concurrency-related problems. Those problems are solved in C, not PHP.
Nowadays everyone uses PHP-FPM (again, written in C) which manages a pool of processes. Once a process is done serving a request, it is cleaned up and becomes available for serving another request. You can tweak the number of processes to control how much concurrency you want, or leave it to PHP-FPM to decide on its own. The process pool is much more efficient than the CGI method of setting up and tearing down a process every time, while preserving much of the conceptual simplicity.
PHP has had a built-in HTTP server since 5.4, but few people use it in production because PHP-FPM is so stable and performant.
I find the built-in web server very useful for running tests. Instead of setting up Apache or nginx on every CI build, you just fire up the built-in web server and point your tests at it.
I use it for small scripted jobs on my own machine that have to go through a proxy, I start the built-in server on the proxy root and point the script to the localhost address.
Surprisingly php these days is actually pretty fast even on forking webserver such as apache. This annoy me to no end because I prefer to use python and django and it can't match php performance on apache even though it handles http requests directly.
Are you using mod_python with Apache? If so, mod_wsgi is what you should be using for Apache + Django applications. mod_wsgi is fantastic and I see no issues with performance matching similar PHP setups via PHP-FPM.
I'm using gunicorn or uvicorn depending on the projects. Doesn't matter which wsgi server I used, the baseline performance level stay the same. For example, a simple django rest api endpoint with nested serializers took 45ms to render, which is similar to the time it take for freshly installed wordpress running on apache/php7.4 (docker) to render the homepage the same test server. All the rest api endpoint did was serializing values from database entries to json, yet it took the same time as a default installation of wordpress to render. Yes, django rest framework serializer is slow and maybe I should use something else, but if cpython is faster maybe there won't be a need to replace the serializer just for a performance issue.
That is not a problem with PHP itself, but the way that Apache/Nginx operates PHP. However, if you want to go full PHP, there is this extension that is pretty amazing (has a built-in server on it and more): https://www.swoole.co.uk/
I tried many things from Apache with mod_php, nginx with php-fpm, Roadrunner and Swoole.
Apache and nginx are both great, both have pros and cons, although I would go with nginx and fpm as my first choice.
Swoole is totally different approach as it runs php as standalone server in a loop, just like python for example. It is great if you serve api but it kills the benefit of having each request isolated as you would have with nginx or apache. So you need to care about memory leaks, db connection pools etc. Also Swoole docs was not great few months ago.
Roadrunner is kind of between apache/nginx and Swoole. It is a golang server that can execute php in workers. For each worker once php is loaded it will stay in memory and it is super fast. The only downside on this one is that Roadrunner is developed by mostly one guy and not much you can find on the internet. Also Roadrunner features set is IMO very narrowed into what the company behind it needs at the time. IMO there is no clear vision where this project is going.
Nowadays everyone uses PHP-FPM (again, written in C) which manages a pool of processes. Once a process is done serving a request, it is cleaned up and becomes available for serving another request. You can tweak the number of processes to control how much concurrency you want, or leave it to PHP-FPM to decide on its own. The process pool is much more efficient than the CGI method of setting up and tearing down a process every time, while preserving much of the conceptual simplicity.
PHP has had a built-in HTTP server since 5.4, but few people use it in production because PHP-FPM is so stable and performant.