Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 05 Jul 2001 13:45:37 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: Extraneous socket read?
To: new-httpd@apache.org
Message-id: <3B44D1F1.2040405@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
References: <Pine.LNX.4.33.0107031113570.10441-100000@twinlark.arctic.org>

dean gaudet wrote:

>On Mon, 2 Jul 2001, Brian Pane wrote:
>
>>Here's a patch that disables the read before the select, but only for
>>the HTTP client socket.  Can somebody with a decent benchmark lab
>>test it out to see if the throughput change is significant?
>>
>
>you can make some reasonable performance measurements with a pair of
>machines and a crossover 100baseT segment.  assuming you're able to max
>out the 100baseT (shouldn't be hard) then you want to use "idle CPU" as
>your metric.  vmstat can help you there.
>
 From a CPU consumption perspective, I'm seeing about a 3% reduction in
system CPU utilization and a 0.5% increase in throughput (when sending a
10KB file to ab over the loopback).  No reduction in user CPU (which makes
sense in this case).  These numbers are in the range that I'd have expected,
given the elimination of the extra read call.  However, they're also small
enough to be within the normal variation of measurement error.  Thus,
while my initial results indicate that the patch will yield a speedup in the
real world, a 3rd party benchmark wouldn't hurt.

--Brian