RE: Why FastCGI?
| From: | Gunter Grodotzki | Date: | Sun, 21 Mar 2021 20:19:22 +0000 |
| Subject: | RE: Why FastCGI? | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-327520@lists.php.net to get a copy of this message | ||
> To serve content from PHP by using HTTP in a professional way, there is a need http/2 +
> http/3 (quic), to implement it, an event handler/concurrency is needed, in the same way, the
> professional HTTP servers do as Nginx, Litespeed Web Server or CloudflareYes, I suppose I am not
> asking for a “full” http server (nor wanting PHP to replace Cloudflare!!).In the real-world, you
> would have some type of loadbalancer (or even CDN such as Cloudflare or Cloudfront) in front. Maybe
> even some http-ingress router if you are into docker orchestrations. Having PHP-FPM serve http
> (“simplified”) – does not stop you from putting Nginx in-front to do the more complex stuff
> (headers, redirects, rewriting, etc.). At least though it is a “reverse proxy” protocol
> understood by many upstream software/solutions. So really nothing changes (neither for small nor
> bigger installations) – you can still run Nginx. Its just the protocol between Nginx <>
> PHP-FPM that changes 😊 > But, I do not recommend serving HTTP content directly from PHP, the
> core PHP developers only have reached a dev HTTP server, it's due to event/threads in PHP still
> not safe for enterprise, instead, the best connector so far isn't FPM, it is LSAPI based on
> this benchmark I agree, maybe not php-cli itself, but why not FPM? It is already doing what is
> needed, except using a different protocol :) Cheers,Gunter