On 3/7/06, Brian Candler <[EMAIL PROTECTED]> wrote: > I'm not sure what you mean there, in particular what you mean by 'assumes > that you can make multiple connections to back end fastcgi processes' > > What I'm familiar with is apache 1.x with mod_fcgi. In that case, the > typical fastcgi program does indeed handle a single request at once, but you > have a pool of them, analagous to httpd with its pool of worker processes. > > Multiple front-end processes can open sockets to the pool, and each > connection is assigned to a different worker. In this regard, a fastcgi > process is just like a httpd process. I don't see why mod_proxy_foo can't > open multiple fastcgi connections to the pool, in the same way as it could > open multiple http connections to an apache 1.x server. > > (You could think of the fastcgi protocol as just a bastardised form of HTTP. > I wonder why they didn't just use HTTP as the protocol, and add some > X-CGI-Environment: headers or somesuch)
Oh, believe me, I'm fully aware of how fastcgi typically works ;-) The problem is meshing that concept with how mod_proxy works. When you give ProxyPass a URL it really wants a host + port combo, you can't (now anyway) have N different backend processes (listening on different ports) all associated with the same URL. To do that you need to wrap them up in a balancer group and use mod_proxy_balancer. Balancer the has the problem that the worker processes don't coordinate things with each other, so even if you're droping the connection to the back end process as soon as you're done with it you can still get into situations where there are free back end processes, but you're sitting there waiting because you tried to connect to one that's already in use. > > Second, mod_proxy_balancer doesn't (seem to) have any real mechanism > > for adding back end processes on the fly, which is something that > > would be really nice to be able to do. I'd eventually love to be able > > to tell mod_proxy_fcgi that it should start up N back end processes at > > startup, and create up to M more if needed at any given time. > > Processes should be able to be killed off if they become nonresponsive > > (or probably after processing a certain number of requests) > > ... sounds very similar to httpd worker process management (for non-threaded > workers) > > > , and they > > should NOT be bound up to a single httpd worker process. > > In that case, is the underlying problem that mod_proxy_foo shouldn't really > hold open a *persistent* connection to the fastcgi worker pool, otherwise it > will tie up a fastcgi worker without good reason, preventing it from doing > work for someone else? Just keeping it from having a persistant connection helps, but it's not sufficient to solve the entire problem. > > So is there some reason I'm missing that justifies staying within the > > proxy framework > > Maybe. You might want to consider the case where the fastcgi server is a > *remote* pool of workers, where the fastcgi messages are sent over a TCP/IP > socket, rather than a local Unix domain socket. In that case, some remote > process is responsible for managing the pool, and this is arguably very > similar to the proxy case. That's actually the case we support now. There is no support for unix domain sockets yet, it's all TCP. > OTOH, the typical approach when using such a remote pool is to have a > different port number for each fastcgi application, since I'm not sure that > the fastcgi protocol itself has some way of passing down a URL or partial > URL which could identify the particular worker of interest. If it did, a > single process listening on a single socket could manage a number of > different applications, each with a different pool of workers. In any case, > though, it probably needs a configured list of applications, as it will need > some parameters for each one (e.g. minimum and maximum size of pool, as you > state) That's what you'd be doing with the current state of things, you use mod_proxy_balancer to wrap up the different back end processes. Alternatively, you can just use the new -N flag I gave to fcgistarter, which lets you start N workers that all listen on the same port, then your problem has sort of gone away. Unfortunately, at this point you don't really have a good solution for managing the processes, since you can't easily start new ones (fcgistarter would have to persist for that) and you can't easily (from mod_proxy_fcgi's point of view) tell the difference between the various back end processes because they all listen on the same port, so when one of them times out you can't say "kill that off and start a new one" because you don't know which one to kill off. Anyway, as you can see there are a number of issues at this point. -garrett
