It would be nice to have a generic protocol between webservers and "spawn-managers".
The idea of a spawn-manager is to spawn backends (independent of the protocol used to connect to the backend - FastCGI, scgi, HTTP, ...) on demand.
Phusion Passenger is one example for this - as far as i understood the concept the webserver (apache) connects to the spawn manager to request a backend; the spawn manager will return a socket to an available backend, to which the webserver connects to handle the request.
So here are some ideas how such a protocol could be designed.
- I think there are two ways to control how many backends are needed: either the webserver decides how many backends are needed or the spawn-manager.
If the spawn-manager has to decide,
- the webserver has to send regular updates to the spawn-manager (overhead?)
- one could use multiple web servers with the same spawn-manager
- writing the spawn-manager is easier :)
- less overhead
- the protocol could easily be reused in the following scenario:
the spawn-manager spawns a php backend, which by default would run 1 child, so it can handle one request at a time.
if another backend is needed the spawn-manager could forward this request to the php master, which would fork another child; many opcode caches work best in this mode (one master, one shared cache, many children) - another master would mean another cache.
Perhaps both modes could be allowed by the protocol?
- The webserver should be allowed to reuse a previously received backend address as long as it doesn't disconnect from the spawn manager (or releases the backend)
- The spawn-manager should support spawning for different system users; this requires running the spawn-manager as root and to implement some security checks in the spawn-manager
I don't think authentication/encryption/... is needed; the protocol should be only used on trusted networks - or just with unix domain sockets.
Updated by stbuehler about 7 years ago · 3 revisions