On Aug 26, 2005, at 12:55 AM, Joe Orton wrote:
On Fri, Aug 26, 2005 at 12:42:19AM -0700, Brian Pane wrote:
The attached patch delays the setting of TCP_NODELAY on client
connections until the first time core_output_filter has to do a
writev_it_all() or emulate_sendfile(). My motivation for this is to
work around the TCP_NODELAY/TCP_CORK problem in Linux 2.6. However,
it also will save a couple of syscalls for any request that is
handled
with sendfile(2).
This will actually end up being *more* expensive on 2.6 systems in the
long run, though, right? I'm not convinced this is a good idea. With
APR changed to allow setting TCP_CORK and TCP_NODELAY at the same time
with 2.6, it is cheaper to just set TCP_NODELAY once on the listening
socket and never have to touch it again.
I didn't think it was actually possible for APR to allow TCP_CORK and
TCP_NODELAY
at the same time. From the tcp(7) manual page on my FC4 installation,
TCP_CORK
If set, don’t send out partial frames. All
queued partial
frames are sent when the option is cleared again.
This is use-
ful for prepending headers before calling sendfile
(2), or for
throughput optimization. This option cannot be
combined with
TCP_NODELAY. This option should not be used in code
intended to
be portable.
and
TCP_NODELAY
If set, disable the Nagle algorithm. This means
that segments
are always sent as soon as possible, even if there
is only a
small amount of data. When not set, data is
buffered until
there is a sufficient amount to send out, thereby
avoiding the
frequent sending of small packets, which results in
poor uti-
lization of the network. This option cannot be used
at the same
time as the option TCP_CORK.
Is the manpage out of date?
If it's possible to use both TCP_CORK and TCP_NODELAY on the same
socket in 2.6.13 or later (assuming that's when the fix for the current
NODELAY toggling problem becomes available), then yes, my lazy
evaluation approach will be less efficient than just setting TCP_NODELAY
on the listener socket--for requests that don't use sendfile. For
requests
that do use sendfile, I think the logic implemented by my patch will be
optimal for both 2.6.1-2.6.12 and 2.6.13+
Brian
