Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 52031 invoked by uid 500); 1 Feb 2001 17:18:35 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 51986 invoked from network); 1 Feb 2001 17:18:31 -0000 Date: Thu, 1 Feb 2001 17:18:33 +0000 (GMT) From: James Sutherland X-Sender: jas88@orange.csi.cam.ac.uk To: new-httpd@apache.org Subject: Re: AP_MIN_SENDFILE_BYTES In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: James Sutherland X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Thu, 1 Feb 2001 rbb@covalent.net wrote: > > > I suspect the answer is 'it depends on the OS'. Apache 1.3 does not mmap files under a certain > > threshold size (a few thousand bytes if I recall). Sendfile on Windows is very efficient (by > > Windows standards :-) even for very small files, especially when you can do the 'reuse the accept > > socket' trick. Worth investigating on Unix for sure. > > Again, it isn't the sendfile call that will hurt us. If that is all you > measure, you will miss the problem. The problem is the small packet that > is going to be sent. That is not a fast operation on any platform. Yes. If I have some spare time, I might try doing some benchmarks of this. Incidentally, does anyone know if a writev() will combine the chunks into large packets, or send each section individually?? If the latter, using mmap()+writev() would avoid this problem completely... James.