Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 10114 invoked by uid 500); 17 Aug 2001 06:18:16 -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 10099 invoked from network); 17 Aug 2001 06:18:16 -0000 Date: Thu, 16 Aug 2001 23:15:30 -0700 From: Brian Pane Subject: Re: Performance numbers..... ;( To: new-httpd@apache.org Message-id: <3B7CB682.5070308@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 References: <15228.16811.269589.434751@critterling.garfield.home> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 708 Victor J. Orlikowski wrote: >Hi all, > >Was running some performance tests on AIX... >And oddities popped up between 1.3 and 2.0 (latest CVS of both). > >Requests/sec. > no keepalive keepalive >2.0 - prefork 420 590 >2.0 - threaded 390 580 >1.3 420 700 > >(Semi) Good news: Without keepalives, prefork performance in 2.0 >matches 1.3. Threaded performance comes close. > >Bad news: 1.3 trashed 2.0 on keepalives. Especially odd is the fact >that the threaded and prefork numbers here are *so* close. > >So, threaded isn't getting trounced too badly, currently. But >keepalive performance in 2.0 has me worried. > >Anyone have any ideas? > As a first step, do you have a means of capturing a system call trace (with something like strace)? If there are any obvious differences in the system call profile between 1.3 with keepalives and 2.0-prefork with keepalives, that may help to isolate the problem. If the system call behavior isn't substantially different, I'd expect to see a higher percentage of usr (as compared to sys) CPU time in 2.0 with keepalives. My hypothesis is that the extra brigade processing involved in keepalive handling in 2.0 may be contributing to the slowness. But it's tough to tell without fine-grained profiling tools. Can anybody with a statement-level or basic-block-level profiler (e.g., Quantify) post an analysis of the bottlenecks in 2.0? --Brian