On Friday 02 October 2009 11:10:25 am Barry Scott wrote: > Jeff Trawick wrote: > > On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott <barry.sc...@onelan.co.uk > > <mailto:barry.sc...@onelan.co.uk>> wrote: > > > > Jeff Trawick wrote: > > > > (instead of based on uri or vhost) > > > > FCGIDCommand /path/to/command > > IdleTimeout n > > MaxProcessLifetime n > > MinProcesses n > > MaxProcesses n > > MaxRequestsPerProcess n > > InitialEnv var[=val] ... > > <class> > > > > (the names of these options follow my proposal for the names > > of existing directives ;) ) > > > > When a command is to be started by mod_fcgid, any options > > specified for the command on this directive override those > > defined for the uri, vhost, global, or the defaults. When a > > wrapper is used, it is that wrapper which must be specified on > > this directive. This directive is not required unless one or > > more options must be customized for a command. > > > > Initially this would be allowed only in global sections. > > InitialEnv can be repeated. > > > > Regarding *class*: Something is needed to disable or alter > > existing management of applications based on their class. > > Currently a class is limited to the processes started by the > > same command within the same vhost (except when ServerName > > isn't specified) with the same identity. > > > > One possibility is to provide an option to ignore the vhost > > name when managing the class (IgnoreVHost or ClassIsGlobal). > > Another possibility is to set the name of the class to be > > used in lieu of the virtual host (ClassName foo), which could > > be used to the same effect but might be more useful in the > > future when the process manager can see per-server configs > > (for existing directives as well as FCGIDCommand). > > > > None of this would affect the identity checks. (Processes > > with different uid/gid would never be considered to be in the > > same class.) > > > > This seems to offer all the features of mod_fastcgi process > > configuration and then go usefully beyond what mod_fastcgi does. > > > > > > Thanks for looking. Does anyone else care to comment? > > > > > > > > Is it possible to also ask for the fcgi process to be started > > before any request arrive? > > > > > > Sure. I guess there could be some "InitialProcesses n" option on this > > directive. (If this appears to be forgotten, open a bug at > > https://issues.apache.org/bugzilla/ and set the severity to > > "enhancement." Product = Apache httpd-2, component = mod_fcgid.) > > > > BTW, do you need to pre-spawn just on general principle (don't want > > any initial delay), or is the on-demand spawning not aggressive > > enough, such that it takes too long to create an adequate number of > > application processes? > > We have a setup that can be CPU time and memory limited. > Using Static servers allows the start up overhead to be suffer once at > boot time. > Our fast CGI servers are python processes that run very fast but can be > slow to start, > a few seconds, which is bad for response times. So do you want a fixed number of these python processes to be pre-spawned and for the pm to stay out of the way? (never start any more or terminate any that were pre-spawned)
> > We have also had data collection going on in the fast CGI process, but > we are moving > away from that for a number of reasons. > > Barry > -- Computer Services Ricardo Cantu Vice President Home office 3506 Buchanan St Suite C Wichita Falls, TX 76308 (940) 696-3010 El Paso branch 1644 Ronnie Reif Dr. El Paso, TX 79936 (915) 219-7119
