FastCGI has many advantages, and it’s our preferred interface when it’s available for the required script language (such as PHP). However, we generally see environments where the php-fpm processes (for instance) are run on the same system as the web server, even though that’s not necessary. In FastCGI space, the web server (say nginx) passes a request through a socket or TCP/IP address:port, and the application delivers back an response (web page, web service JSON result, etc). Obviously sockets only work locally, but the port can be on another machine.
So the question is, how do you arrange your virtual server rack? While splitting things out like that tends to add a few ms of latency, the advantages tend to justify this approach:
- Not running PHP on your web-server, and only having connectivity web-server -> application, is good for security:
- should the web server get compromised, it can still only make application requests, not reconfigure the application server in any way;
- should the application get compromised, it will not be able to gain control over the web-server as there is no connectivity path in that direction.
- nginx is exceedingly good at “smart proxy”-style tasks, and that’s essentially already what it’s doing with FastCGI anyway;
- you could have multiple application servers, rather than just one. Optionally scaled dynamically as traffic needs change;
- this effectively turns nginx into a kind of load-balancer for the application server back-ends; the way you specify this is through
- a single name that resolves to multiple address which are then used in a round-robin fashion (not necessarily optimal as some requests may take longer than others), or
- a server group as provided by the ngx_http_upstream_module module.
- nginx can detect when a back-end is unresponsive, and connect to an alternative;
- thinking back to the fact that some requests take longer than others, that’s usually URL-specific. That is, it’s relevant for queries in certain areas (such as reporting, or drill-down type searches) of a web interface. Now, you can tell nginx to use a different FastCGI destination for those, and thus separate (insulate, really) the handling of that application traffic from the rest of the application.
- This all fits very neatly with containers, should your infrastructure use those or if you’re considering moving towards containers and micro-services.
The possibilities are quite extensive, but naturally the details and available options will depend on your needs and what you already have in place. We regularly help our clients with such questions. Solutions Architecture, both for evolving existing environments as well as for greenfield projects.