httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Heidemann <jo...@ISI.EDU>
Subject Re: performance ``bugs'' in apache-1.1b4's P-HTTP
Date Thu, 11 Jul 1996 20:45:49 GMT
On Thu, 11 Jul 1996 11:57:58 PDT, Cliff Skolnick wrote: 
>On Thu, 11 Jul 1996, John Heidemann wrote:
>> I don't believe they apply to Apache.  Apache nearly always writes
>> data in 4KB units.  (Nearly all Apache data goes through the buffered
>> IO routines.)  Since the only data to send is in a single contiguous
>> buffer, writev has no advantage over write.  Since the data is written
>> in relatively large chunks, Apache nearly always writes full-size
>> segments and the Nagle can't reduce packet count.
>
>So turning if off will have no effect :)

No, turning it of also influences silly-window-avoidance algorithm and
improves P-HTTP connection performance by about a factor of 7.5 (over
10Mbps Ethernet, for the workload described in
<http://www.isi.edu/lsam/publications/phttp_tcp_interactions/>.)

>Actually nagle does smooth out traffic here at Organic.  I've looked at
>the packet size distribution from our web server with it on and off.  This
>may be because of our heavy use of server side includes and CGIs.  For a
>large pool of static docs, what you say is 100% correct.

It seems very plausible that CGI scripts which don't do buffering
would do many writes and so would benefit from Nagle's algorithm.
(The same holds true for SSI, although a brief look at the Apache code
suggests that any Apache output except for mod_proxy will be
buffered.)

If there are CGI scripts which don't do buffering, there seem to be
several work-arounds:

	(1) Add text to the documentation recommending that CGI
		scripts use buffered I/O or that they enable
		Nagle.

	(2) Have Apache re-enable Nagle on the connection before
		running any CGI script.

	(3) Have Apache enable Nagle only after it realizes
		that it's serving a static document.

(From least to most conservative.)

Perl uses buffered I/O by default; there are very few cases where data
produced in small chunks shouldn't be buffered.
(Robert Thau basically presented this argument in the context of writev:
rst> (In the header, most of that 4K is copied from other places into the
rst> common buffer, but the bookkeeping to keep track of all those places
rst> is probably as much of a headache as simply doing the copies, so I
rst> have trouble seeing it as a win.  As for body data, that generally is
rst> read in bulk by the buffer-ful, and I don't see any immediately
rst> obvious use for a non-trivial version of writev() in that context).
)

Unless, of course, you're doing something interactive.
(Are you implementing telnet in Java?.)

   -John Heidemann


Mime
View raw message