phk at phk.freebsd.dk
Sat Aug 5 23:21:02 CEST 2006
In message <18126.96.36.199.4.1154812048.squirrel at denise.vg.no>, "Anders Berg"
>> W nbr 34 sess 0x16c1008 fd 158 xid 2017851670 step 7 handling 128 age 8555
>> W nbr 34 sess 0x1b3f008 fd 173 xid 2018914270 step 9 handling 64 age 5960
>> W nbr 29 sess 0x1902008 fd 80 xid 2019001809 step 7 handling 128 age 5729
>> W nbr 41 sess 0x1ef7008 fd 319 xid 2019426763 step 7 handling 128 age 4648
>> W nbr 35 sess 0x1c7f008 fd 45 xid 2019626419 step 7 handling 128 age 4174
>> W nbr 39 sess 0x1feb008 fd 264 xid 2019738777 step 1 handling 4 age 3893
>> This bugs me a bit, clients which for some reason or other does not
>> pick up their document, but which leaves the TCP connection stalled.
>Ouch. Can you see if Opera is overrepresente in those? I see some funny
>behavior from Opera in my work, but it may be just a different
>implementation of HTTP/1.1 than Firefox and IE, and still a be after RFC
Opera is quite agressive HTTP wise, that's for sure. I havn't really
examined it in details yet.
>> sendfile() has no way to specify a timeout. I may have to find a way
>> to kill these worker threads with violent means.
>I guess there is no way round it. Would it make any difference if it was
>kernelspace and not userland?
I think there are two ways:
Use the relatively simple way we do it now and have a watcher thread
kill them if it takes too long. This is a fair bit more violent
than I like, and quite prone to errors in threading implementations.
The other way is to make the sockets nonblocking and let sendfile(2)
return partial writes and then enter a poll/sendfile look with a
A variation of the second scheme is that after N seconds, the session
is handed over to a central "slow session pusher" thread and the
worker thread grabs interesting new work instead.
I'll have to think about that one some more...
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the varnish-dev