Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3FC7FDAF.4080900@f-secure.com>
Date: Sat, 29 Nov 2003 04:00:15 +0200
From: Sami Tikka <sami.tikka@f-secure.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5b) Gecko/20030723 Thunderbird/0.1
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: consider reopening 1.3
References: <143.1c4231ac.2ce9cd3d@aol.com>
In-Reply-To: <143.1c4231ac.2ce9cd3d@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

TOKILEY@aol.com wrote:

> I popped off and looked at 2.0 code again just now and I can tell
> you right now it's (still) the filtering that's killing it.

I am a novice (written 2 modules for apache 1.3 and 1 for 2.0) but I 
have examined the apache 2.0 code quite a lot during the last year and I 
believe this is what happens in 2.0 with static pages:

1. Some core handler creates a bucket-brigade, creates a file bucket 
referring to the static file and inserts the bucket into the brigade. 
(Well, it also appends an EOS bucket). The handler passes the brigade to 
the first output filter.

2. In the basic setup the first filter is probably the CONTENT_LENGTH, 
which asks the file bucket how long it is and sets Content-Length header 
in r->headers_out table. Brigade is passed to next filter.

3. ...which is probably HTTP_HEADER filter, which reads r->headers_out 
and generates the response header. This probably means allocating a 
couple of memory buckets for the it. The buckets are prepended to the 
brigade. Pass to next filter.

4. ... which will be CORE output filter, which pumps out the buckets 
containing the header using writev() and does a single sendfile() call 
for transmitting the file bucket.

As I see it, this is as efficient as it can be. Nothing is copied 
needlessly. The buckets containing the header might be allocated from a 
heap (= "allocator"), even though stack would be more efficient. (Oh, 
they might come from the stack, I'm too tired to see what goes on under 
the hood.)

I never had to learn the BUFF API in 1.3 but it is hard to imagine it 
being more efficient than this.

This design is, I think, similar to the mbufs in *BSD kernel and skbuffs 
in the Linux kernel and it seems to work well for them.


About re-opening 1.3 tree: I'm not sure I understand what is the big 
deal. This is open source. You want to work on 1.3, go do it. Your 
patches are not getting into ASF repository? Create your own. There are 
other open source projects that have started ignoring patches and it has 
caused a competing code fork to emerge. I don't see it necessarily as an 
evil thing. It is called evolution.

(I guess if you start your own repository, you can no longer call it 
Apache, but any other name of an american indian tribe should be ok. :)

-- Sami Tikka