Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 30682 invoked by uid 500); 26 Apr 2001 19:23:32 -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 Received: (qmail 30627 invoked from network); 26 Apr 2001 19:23:30 -0000 Errors-To: Message-ID: <01e901c0ce86$2ab04af0$95c0b0d0@roweclan.net> Reply-To: "William A. Rowe, Jr." From: "William A. Rowe, Jr." To: References: <003a01c0ce4d$c5f930a0$e4421b09@raleigh.ibm.com> <20010426115726.T29185@ebuilt.com> Subject: Re: thread locking within apr file io Date: Thu, 26 Apr 2001 14:18:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N From: "Justin Erenkrantz" Sent: Thursday, April 26, 2001 1:57 PM > > > > This stuff came up while Justin and Aaron were performance testing > > > > mod_mbox -- right now you can double the requests per second simply > > > > by recompiling with --disable-threads. > > > > Wow, which MPM are you using? That is actually quite a suprise to me as Apache 2.0 performance is > > close to that of Apache 1.3 (on AIX at least) which does not use pool locking or buffer locking for > > file i/o. > > We are currently using prefork because pthread is completely useless at > this point. Hopefully, the signals stuff gets fixed soon... Actually, > on FreeBSD, threaded MPMs are disabled, but no one tells APR, so it > defines APR_HAS_THREADS - we need to fix that. I may submit a patch for > that - just add --disable-threads to APRs configure for these platforms? Hmmm... notice that APR_HAS_THREADS is irrelevant to the MPM selected... you _can_ using threading support in APR with a prefork MPM, and there may be modules that need just that configuration someday soon (say, child threads in a mod_proxy or servlet environment). So you can't indiscriminantly disable APR threads 'just because', there is going to need to be a bit more logic. Contrawise, just because the user enables APR threads does _not_ mean they are choosing pthreads ;-) Bill