httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Blocking Sockets? was Re: TCP_CORK broken on Linux 2.6?
Date Fri, 24 Jun 2005 21:53:58 GMT
Ugh. Kudos to Greg for getting me to look at a truss/strace of httpd, 
but I didn't find anything good to report...

On FreeBSD, it turns out we are being quite wasteful.  It seems in all 
cases when we are writing to the client, our socket is always 
non-blocking, and therefore sendfile returns EAGAIN:

sendfile(0xf,0xe,0x0,0x0,0xedb4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0x8000,0x0,0x6db4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0x9000,0x0,0x5db4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0xa000,0x0,0x4db4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0xb000,0x0,0x3db4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0xc000,0x0,0x2db4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0xd000,0x0,0x1db4,0xbfbfc5b0,0xbfbfc5a8,0x0) ERR#35 
'Resource temporarily unavailable'
poll({14 0x0|IN|PRI|ERR|HUP|NVAL|RDNORM|RDBAND|WRBAND },1,300000) = 1 (0x1)
sendfile(0xf,0xe,0xe000,0x0,0xdb4,0xbfbfc5b0,0xbfbfc5a8,0x0) = 0 (0x0)
read(0xe,0x8173028,0x1f40)                       ERR#35 'Resource 
temporarily unavailable'
write(8,0x81730f0,77)                            = 77 (0x4d)
close(15)                                        = 0 (0x0)


8 calls to sendfile and poll to send a single 55K file. Ick.

I thought we were always supposed to be using a blocking socket when 
doing the sendfile?

Index: core_filters.c
===================================================================
--- core_filters.c      (revision 201576)
+++ core_filters.c      (working copy)
@@ -845,6 +845,8 @@
             return APR_SUCCESS;
         }

+        apr_socket_opt_set(net->client_socket, APR_SO_NONBLOCK, 0);
+
         if (fd) {
             apr_hdtr_t hdtr;
             apr_size_t bytes_sent;

After adding this patch, truss looks like:
fcntl(14,F_GETFL,0x10)                           = 6 (0x6)
fcntl(14,F_SETFL,0x2)                            = 0 (0x0)
sendfile(0xf,0xe,0x0,0x0,0xedb4,0xbfbfc5b0,0xbfbfc5a8,0x0) = 0 (0x0)
read(0xe,0x8173028,0x1f40)                       = 355 (0x163)
write(8,0x81750f0,77)                            = 77 (0x4d)
close(15)                                        = 0 (0x0)

Is our code for detection of inheriting non-blocking from the listening 
socket broken?

-Paul

Mime
View raw message