Slow clients...

[Poul-Henning Kamp]

In message <1847.193.69.165.4.1154812048.squirrel at denise.vg.no>, "Anders Berg" 
writes:
>>
>> 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
>2616.

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
timeout.

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.