Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 97955 invoked by uid 500); 10 Sep 2000 17:05:14 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 97943 invoked from network); 10 Sep 2000 17:05:14 -0000 X-Authentication-Warning: koj.covalent.net: rbb owned process doing -bs Date: Sun, 10 Sep 2000 10:10:26 -0700 (PDT) From: rbb@covalent.net To: new-httpd@apache.org Subject: Re: eek. poor chunking behavior. In-Reply-To: <20000909144515.R3278@lyra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Sat, 9 Sep 2000, Greg Stein wrote: > I'm debugging a problem with the current Apache response behavior, and I > actually got a chance to see the chunking output. > > Using BUFF, the response would be one big-ass chunk. > Using the filter, I've got 21 (!!) > > Simple explanation: each brigade maps into a chunk, rather than each > buffered network packet. > > Solution? Dunno offhand. Going back to using BUFF would be one answer. > Beyond that, I don't have any suggested alternatives. > > Thoughts, anyone? Coalesce the buckets into bigger buckets. This was mentioned as a much needed improvement when the chunking filter was first committed. It is very likely that the comment was deleted at some point. BUFF is not the correct solution, because it forces memcopies. By just having the chunking filter do a bit of buffering, we solve the problem much cleaner, and we can avoid a big number of the memcpys. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------