On 3/6/07, Bob Kline <bkline@xxxxxxxxxxxxx> wrote:
I'd like to replace mod_cgi with mod_cgid in order to avoid an annoying
bug which is in the former but not the latter. What would be the
drawbacks (if any) of doing this? I noticed the following sentence in
http://httpd.apache.org/docs/2.0/mpm.html:
For example, sites that need a great deal of scalability can choose
to use a
threaded MPM like |worker
<http://httpd.apache.org/docs/2.0/mod/worker.html>|, while sites
requiring stability or compatibility with
older software can use a |prefork
<http://httpd.apache.org/docs/2.0/mod/prefork.html>|.
Does this imply (as it seems to) that the MPM approach is not stable?
Any other pitfalls to watch out for? This would be on a
single-processor (AMD64) machine.
First, both worker and prefork are MPMs, so you are not really talking about an "MPM approach", you are talking about choosing between a threaded (worker) and non-threaded (prefork) MPM. Second, you don't need to change MPMs to use mod_cgid. It is the default CGI module when using worker, but I don't see any reason it can't be used along with prefork. It does add a level of complication to the CGI launch process, but I believe it is fairly well tested, so it shouldn't be a problem. Finally, if you do wish to go with the worker MPM, then I can clarify the stability comment. It is not a question of woker itself not being stable. The problem is that when you run a multi-threaded server, a problem in any of the worker threads can take down a whole process, meaning multiple clients will be affected. With prefork, on the other hand, different client requests are better isolated from each other. This is not usually an issue unless you are using third-party modules that have a tendency to crash the server. Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|