httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: non-buffered CGIs suck
Date Fri, 06 Mar 1998 06:53:00 GMT


On Thu, 5 Mar 1998, Marc Slemko wrote:

> But it is small because you are adding extra overhead for no reason.  Any
> decent filesystem is going to be reading more than 4k anyway, and bumping
> it up to 16k or 32k or more would remove a certain amount of overhead
> while adding other overhead.  It isn't that easy though, since there are
> oodles of interactions that go on between things that aren't obvious.

The larger you make these buffers, the more you exacerbate the pipelining
problem that I just mentioned -- a bunch of small responses get stuck in
the buffer waiting for one long response to fill it up. 

> Look at it this way: is it worth it to use 1/8th of the system calls
> (non-mmap, of course) for reading and sending the body data in exchange
> for giving up 28k of memory?  

I'm not interested in non-mmap and performance really... the systems we
don't do mmap on aren't typically going to be used in performance critical
situations. 

PIPE_BUF is typically 4k, and I bet if you look around you'll find that
you only ever get 4k reads from pipes on many systems -- I know linux is
this way... but I haven't tested others.  It may be 8k on alphas and a few
others. 

So that essentially leaves mod_include... (and mod_proxy, but mod_proxy's
cache should be changed to use mmap as well). 

Although I'm finding right now what looks like a linux performance bug if
you've got a system that's just a bit over its RAM -- with mmap() I'm
seeing more swap activity than I do with read().  I think it's a known
problem... linux does great until it starts swapping...

> (unrelated) What does Linux default to for a send buffer size?

65535 (tested on 2.1.86 and 2.0.33) 

Dean


Mime
View raw message