Return-Path: owner-new-httpd Received: by taz.hyperreal.com (8.6.10/8.6.5) id OAA26723; Sun, 9 Apr 1995 14:45:02 -0700 Received: from ooo.lanl.gov by taz.hyperreal.com (8.6.10/8.6.5) with ESMTP id OAA26714; Sun, 9 Apr 1995 14:45:00 -0700 Received: by ooo.lanl.gov (1.37.109.16/16.2) id AA174443896; Sun, 9 Apr 1995 15:44:57 -0600 From: Rob Hartill Message-Id: <199504092144.AA174443896@ooo.lanl.gov> Subject: NCSA non-forking model doesn't fix the problem To: new-httpd@hyperreal.com (New httpd project) Date: Sun, 9 Apr 95 15:44:56 MDT Organization: Theoretical Division, T-8. Los Alamos National Laboratory Address: LANL Theoretical Divi' T-8, MS B285, P.O Box 1663, Los Alamos NM 87545 Fax: (505) 667 5585 Phone: (505) 665-2280 or 667-5336 (T-8 Secretary) Mailer: Elm [revision: 70.85] Sender: owner-new-httpd@hyperreal.com Precedence: bulk Reply-To: new-httpd@hyperreal.com Using some code which Rob T's been working on, I have the following theory about the NCSA approach to non-forking that I'd like to air for comments... The NCSA 1.4 model for a non-forking httpd is fundamentally flawed.. and here's why *I* think so, 1.4 requires the root-httpd to do all the "accept()" calls, and to feed the child-httpd's with file descriptors to complete the request. This effectively make root-httpd a process scheduler. All systems already have an optimized process scheduler, and bolting another one on top of this to be run in user-mode is a bad idea. I did some quick tests with a NCSA 1.4 like configuration, and setup 5 child-httpds. With continuous requests coming in from 11 different sources, one or more of the child-https sat idle for long periods while the others were left to do all the work. What I think was happening was that root-httpd was iteslf not being scheduled frequently enough for it to do a decent job of scheduling the child-httpds. In the time it took root-httpd to be recheduled, one of the "busy" child-httpds had finished it's latest request and had become "ready". But during this time, there were requests coming into port 80 that were not being serviced, but which had idle child-httpds sitting there eager to do some work. A single processor system doesn't need a root-httpd to act as a scheduler. All the work can be performed inside the http-child processes. MP systems only need a locking mechanism around accept() to make this simpler model work. I base this on empirical data and a belief that the theory it highlights is sound. While forking is known to be costly, the biggest bottleneck that a non-forking model should attack is the single process responsible for the accept(). Remove that from the equation and things should really fly. comments ? robh