From new-httpd-return-17666-apmail-new-httpd-archive=apache.org@apache.org Wed Jul 18 19:47:22 2001 Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 47744 invoked by uid 500); 18 Jul 2001 19:47:22 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Delivered-To: moderator for new-httpd@apache.org Received: (qmail 81381 invoked from network); 18 Jul 2001 18:53:31 -0000 From: "Benjamin W. Ritcey" To: Subject: RE: [PATCH] Problems with MPM threaded Date: Wed, 18 Jul 2001 14:53:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N As an end-user of apache, I'd like to chime in: please, please, please leave the N processes with M threads model available -- "the hypothetical buggy 3rd party modules should be fixed rather than hacked around" is fine in theory, but in practice I'd rather have an Apache that can soldier on regardless of the crappy modules it's forced to run. Tuxedo has used the N x M model for a long time with good results for similar reasons. My $0.02 Thanks, -b -----Original Message----- From: dean gaudet [mailto:dgaudet-list-new-httpd@arctic.org] Sent: Tuesday, July 17, 2001 4:13 AM To: new-httpd@apache.org Subject: Re: [PATCH] Problems with MPM threaded On Sat, 14 Jul 2001 rbb@covalent.net wrote: > Having multiple processes each with multiple threads provides for FAR > more robustness than just a single process with multiple threads. ya know, i'm not really convinced of the desirability of this explanation anymore. maybe the hypothetical buggy 3rd party modules should be fixed rather than hacked around. and they won't be fixed as long as apache continues to hide the problem. however i can provide two more justifications which are pretty weak: - userland thread libraries need multiple processes in order to get disk i/o parallelism (and multi-cpu parallelism) - suppose you configure apache with exactly the number of children as you have processors. and suppose that somehow magically the CPU requirements of each process' threads is about even. then a good (kernel) scheduler will likely migrate each process to its own CPU and time slice just the threads within that process. this will tend to decrease the overall memory system traffic (because L2 caches won't be competing for the same process' memory), and increase the TLB hit rate. it may even be possible to avoid interprocessor interrupts every time the memory map is changed (to make sure that remote TLBs are up to date). that's a lot of conditionals to get right. -dean