Garrett Rooney wrote:
So I've been taking a look at the new work Paul's been doing on the fcgi-proxy-dev branch, and it looks really cool, but I've got some questions on its direction. What's there now is the beginnings of functionality to let you use mod_proxy to send requests for particular parts of the URL space to a back end FastCGI process. This is fantastic, but it's only part of the equation. We also need some mechanism for actually starting and managing the FastCGi processes.
Yup, I have pretty much not done any work on a local FastCGI process management so far. I figure once we have the wire protocol down, adding all the process management stuff is a whole different project.
One of the things people like about lighttpd is the way it can start up N back end processes, then if one of them dies for some reason it'll simply restart it for you. In order to do this kind of thing it seems like we'll need something keeping track of what FastCGI processes have been started, which are currently in use, and other such bookkeeping information. Now since we need to be able to run in multiprocess configurations, that means either the bookkeeping data needs to be kept in shared memory, or all this info needs to be managed by a separate child process (similar to the mod_cgid stuff I imagine). The separate child process plan seems easier to implement correctly, but it also means that the process of grabbing hold of a FastCGI process would reqiure some sort of IPC, sending requests over a socket or something, which is potentially slow.
I personally like a background process, that takes care of managing all the backend FastCGIs, kinda like mod_cgid. The one major thing I would change, is for Unix Platforms, you would use unixd sockets, to connect from the worker to the fastcgi Backend, to avoid the overhead of a 3rd process proxying it. On Win32, you could just use a manager thread, and pipes to the FastCGI, instead of unixd. (winnt MPM is only threaded)
We will also need some way of creating a one of these that can connect via the mod_proxy worker/backend concept, so it can slide right into the whole proxy_balancer code. Currently the proxy backend code assumes TCP sockets, and there doesn't seem to be any way around that.
I suppose this could be made less of an issue by introducing some sort of scheme where a httpd process can hold on to a back end FastCGI process as long as it wants to use it, which is fine as long as the manager child can tell when the httpd process has died or otherwise gone to never never land so it can either regain control of the FastCGI process or kill it and start another.
This kind of talking back and forth sounds like lots of context switching, no matter which method of IPC is used. I would like things to be.. more automagical.
-Paul
