From dev-return-3040-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jul 06 20:27:39 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 11253 invoked by uid 500); 6 Jul 2001 20:27:30 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 11177 invoked from network); 6 Jul 2001 20:27:27 -0000 Date: Fri, 06 Jul 2001 13:25:36 -0700 From: Brian Pane Subject: Re: [PATCH/CONTRIB] Shared Mem Hash Table To: APR Development List Message-id: <3B461EC0.8040205@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.2) Gecko/20010628 References: <3B43E69F.4010001@cnet.com> <20010704211656.E7717@ebuilt.com> <994347384.2885.1.camel@griffon.cnet.com> <20010705095634.F7717@ebuilt.com> <00b001c1059d$d8016920$4daa2ad5@VAIO> <994371197.12618.2.camel@griffon.cnet.com> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Ian Holsman wrote: >On 05 Jul 2001 22:59:25 +0100, David Reid wrote: > >>OK, to comment on this prior to the patch being posted... >> >>I have SMS running as pools and the implementation I have manages to run the >>server at 80% of the speed of pools. This is with no changes to the httpd >>code except using --enable-sms on the configure line. Now, this isn't >>amazing, but does present a starting point. As I said we haven't started >>optimising or altering. >> [...] >If you post your patch, I'll run it through quantify which should >highlight where the bottlenecks are. > Detailed profile data from Quantify would be extremely useful--not just for the new SMS-based pools, but also for APR and the httpd in general. This morning, I instrumented the latest httpd-2.0 souce and found that it's spending 41% of its CPU time in usr mode and 59% in sys when delivering a 50KB, non-server-parsed file (on Linux, using sendfile). For server-parsed requests, I've seen ratios as high as 70% usr, 30% sys. The bad news: the httpd is wasting a huge amount of CPU time in user-space code (for an optimal httpd serving static files, the usr CPU should approach zero; 41% is surprisingly high). The good news: there's an opportunity to cut the httpd's CPU utilization nearly in half by tuning just the user-space code. --Brian