Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 36554 invoked by uid 500); 12 Jun 2000 22:09:25 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 36542 invoked from network); 12 Jun 2000 22:09:24 -0000 Date: Mon, 12 Jun 2000 23:09:03 +0100 (BST) From: James Sutherland X-Sender: jas88@dax.joh.cam.ac.uk To: "new-httpd@apache.org" Subject: Re: Performance comparison of mod_cgi and mod_cgid. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Mon, 12 Jun 2000 rbb@covalent.net wrote: > > > mod_cgid: > > Accept on server socket. > > Fork the child > > exec the cgi > > > > mod_cgi: > > ap_createprocattr_init > > ap_setprocattr_io > > ap_setprocattr_dir > > ap_setprocattr_cmdtype > > ap_create_process > > fork child > > exec cgi > > ap_note_subprocess > > > > The other processing before and after the above code is > > very similar between the two. The exception might be in the way > > that mod_cgi does iol handling vs. mod_cgid. > > I have a hard time with this explanation. If you take a look at what the > setprocattr_* functions are doing, it just isn't that much. I also find > it hard to believe that the cmdtype and dir functions can't be removed. > > This explanation really makes it look like APR is a huge drain on system > resources, which is not what we are seeing with the rest of Apache 2.0. I > would prefer that we had some real proof that APR is causing these > problems before this is just assumed. > > The original problem this module was meant to solve (namely forking a > threaded process) seems like a much better explanation for the performance > difference IMHO. It seems to me that fork (on all platforms) must create > all threads and then kill them all to be POSIX compliant. I tend to agree with Ryan here; certainly fork() seems like the most likely culprit, if it's forking a load of threads then killing them all every time. The next stage, of course, is to have the cgid process pre-fork, and add a modular API. Then, after a few years, give it an abstraction layer to aid porting, write multi-threaded versions... :-) On a more serious note, have you tried moving the fork() up before the accept(), so the child accept()s requests then exec()s? If it's possible, this should help cut request latency slightly, I think? (Probably little or no impact on these benchmarks, though...) James.