You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <ch...@force-elite.com> on 2005/06/24 23:53:58 UTC
Blocking Sockets? was Re: TCP_CORK broken on Linux 2.6?
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
Re: Blocking Sockets? was Re: TCP_CORK broken on Linux 2.6?
Posted by Paul Querna <ch...@force-elite.com>.
Jeff Trawick wrote:
>On 6/24/05, Paul Querna <ch...@force-elite.com> wrote:
>
>dev@apr.apache.org...
>
>
>
>>I thought we were always supposed to be using a blocking socket when
>>doing the sendfile?
>>
>>
>
>no
>
>
Yup. Sorry, I was jumping to conclusions.
I started a thread over in dev@apr about rethinking the timeout stuff.
It just sucks to have to use non-blocking sockets on all operating
systems when we want to use Timeouts.
Re: Blocking Sockets? was Re: TCP_CORK broken on Linux 2.6?
Posted by Jeff Trawick <tr...@gmail.com>.
On 6/24/05, Paul Querna <ch...@force-elite.com> wrote:
dev@apr.apache.org...
> I thought we were always supposed to be using a blocking socket when
> doing the sendfile?
no
> 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);
> +
now you have a denial of service attack ;) connect to Paul's web
server and park...
> Is our code for detection of inheriting non-blocking from the listening
> socket broken?
that doesn't pertain here... listening sockets are non-blocking (to
deal with prematurely reset connection) ... connected sockets are
non-blocking (to deal with timeouts in portable manner)...