Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <BB9C79FF-D4E5-4A19-B978-D82E77B8F8B5@apache.org>
References: <20051231234515.90084.qmail@minotaur.apache.org>
 <E4137D84-F99C-4AD9-A49F-0CFFF02A0FBC@gbiv.com>
 <856FE865-C612-4F84-BB83-E01F459340F6@apache.org>
 <4D48232A-E733-44BA-9F84-9B735991C79C@gbiv.com>
 <BB9C79FF-D4E5-4A19-B978-D82E77B8F8B5@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1D1F86C5-B4E7-4646-8B90-C9AD1B653B99@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES
 include/ap_mmn.h include/httpd.h server/protocol.c
Date: Mon, 2 Jan 2006 14:14:01 -0800
To: dev@httpd.apache.org

On Jan 2, 2006, at 1:37 PM, Brian Pane wrote:

> "Significantly faster than prefork" has never been a litmus test for
> assessing new features, and I'm -1 for adding it now.  A reasonable
> technical metric for validating the async changes would "significantly
> more scalable than the 2.2 Event MPM" or "memory footprint
> competitive with IIS/Zeus/phttpd/one's-competitive-benchmark-of- 
> choice."

Those aren't features.  They are properties of the resulting system
assuming all goes well.

> The bit about degrading the rest of the server is a wonderful sound
> bite, but we need to engineer the httpd based on data, not FUD.

I said leave it on the async branch until you have data.  You moved
it to trunk before you've even implemented the async part, which I
think is wrong because the way you implemented it damages the
performance of prefork and needlessly creates an incompatible MMN.
Maybe it would be easier for me to understand why the event loop is
being controlled at such a high level if I could see it work first.

Now, if you want to tell me that those changes produced a net
performance benefit on prefork (and thus are applicable to other MPMs),
then I am all ears.  I am easily convinced by comparative performance
figures when the comparison is meaningful.

....Roy