Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 8901 invoked from network); 30 Nov 2007 03:46:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Nov 2007 03:46:16 -0000 Received: (qmail 31779 invoked by uid 500); 30 Nov 2007 03:45:58 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 31708 invoked by uid 500); 30 Nov 2007 03:45:57 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 31697 invoked by uid 99); 30 Nov 2007 03:45:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Nov 2007 19:45:57 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.202.165.221] (HELO smtpout05.prod.mesa1.secureserver.net) (64.202.165.221) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 30 Nov 2007 03:46:00 +0000 Received: (qmail 12308 invoked from network); 30 Nov 2007 03:45:36 -0000 Received: from unknown (67.162.45.134) by smtpout05-04.prod.mesa1.secureserver.net (64.202.165.221) with ESMTP; 30 Nov 2007 03:45:35 -0000 Message-ID: <474F875E.2020506@rowe-clan.net> Date: Thu, 29 Nov 2007 21:45:34 -0600 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: randomized request for apache benchmark References: <2196cb850711291907i1c8ffc7fud364d53de74de345@mail.gmail.com> In-Reply-To: <2196cb850711291907i1c8ffc7fud364d53de74de345@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org kaby wrote: > For the primarily web application is no longer static. > Considering factors like cache, instruction prediction, I suppose randomized > request is need to avoid possible bias in benchmark. > So I wanna proposal a patch for this. Any suggestion? ab.c isn't the place for such work, and you are absolutely right (modern architectures are incredibly good at doing stupidly repetitive tasks efficiently, and this doesn't mirror the real world). Would you take a look at http://svn.apache.org/repos/asf/httpd/test/trunk/flood/ which is already moving in the direction of flexibility you seek, and is actively soliciting new ideas and patches? Bill