httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject simple HTTP/1.0 request strace
Date Sun, 07 Jan 2001 19:15:21 GMT
hey so this isn't such a bad starting point.  here's an strace of "GET
/index.html.en HTTP/1.0" on current HEAD, using prefork mpm (on linux of
course).

accept(5, {sin_family=AF_INET, sin_port=htons(1982), sin_addr=inet_addr("204.107.140.52")}},
[16]) = 8
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x807f774, [], SA_INTERRUPT|0x4000000}, 8) = 0
setsockopt(8, IPPROTO_TCP1, [1], 4)     = 0
getsockname(8, {sin_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("204.107.140.52")}},
[16]) = 0
fcntl(8, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(8, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
read(8, "GET /index.html.en HTTP/1.0\nHost"..., 8192) = 46
gettimeofday({978893823, 340674}, NULL) = 0
stat("/home/dean/ap2/htdocs/index.html.en", {st_mode=S_IFREG|0664, st_size=1349, ...}) = 0
open("/home/dean/ap2/htdocs/index.html.en", O_RDONLY) = 9
getsockopt(8, IPPROTO_TCP, 1, [1], [4]) = 0
setsockopt(8, IPPROTO_TCP1, [0], 4)     = 0
setsockopt(8, IPPROTO_TCP3, [1], 4)     = 0
writev(8, [{"HTTP/1.1 200 OK\r\nDate: Sun, 07 J"..., 294}], 1) = 294
sendfile(8, 9, [0], 1349)               = 1349
setsockopt(8, IPPROTO_TCP3, [0], 4)     = 0
setsockopt(8, IPPROTO_TCP1, [1], 4)     = 0
read(8, 0x814cfb0, 8192)                = -1 EAGAIN (Resource temporarily unavailable)
write(4, "204.107.140.52 - - [07/Jan/2001:"..., 87) = 87
shutdown(8, 1 /* send */)               = 0
gettimeofday({978893823, 343148}, NULL) = 0
read(8, "", 512)                        = 0
close(8)                                = 0
rt_sigaction(SIGUSR1, {0x807f774, [], SA_INTERRUPT|0x4000000}, {SIG_IGN}, 8) = 0
close(9)                                = 0

24 system calls (vs. something like 17 or 18 for 1.3 i think)

the {get,set}sockopt stuff is TCP_NODELAY and CORK.  those aren't terribly
expensive system calls at all... but it's still tempting to clean them up.
i'd say that since all sockopt calls go through APR it can keep track
of the current state -- it could even defer setting TCP_NODELAY until
a naked write comes along (i.e. a write which isn't part of a sendfile
sequence which uses CORK).

btw, the sendfile code for linux does a bunch of "if (corked)" tests --
conditionals like that can slow stuff down especially since the most
common usage is going to be one sendfile per response, and it'll always
have headers and always be corked.  it doesn't hurt to always cork.

F_GETFL followed by F_SETFL -- i'm not aware of any case where we have
to do the F_GETFL.  we know we want O_RDWR|O_NONBLOCK and can set it
directly.  worst case scenario is that we can figure something like this
out at config time (or maybe have a hint or whatever so that on linux,
solaris and probably freebsd we just set O_RDWR|O_NONBLOCK directly).

i haven't looked into what's causing the read/EAGAIN -- the response
here had "Connection: close", and there should be no need to read before
going into lingering close.

(ok i'm just babbling for now, not fixing anything.)

-dean


Mime
View raw message