Re: [Chicken-users] Re: Very slow keep-alive behaviour on Spiffy

[F. Wittenberger]

Hi,

as I wrote Graham in private mail already: you always want to buffer you
network traffic.  I experienced the very same when I wrote the http
server and client code for askemos.org.  One more hint: for at least
FreeBSD, you want it the other way around too: break large strings in
small ones, otherwise your threading system will be blocked for too long
time.

Furthermore, when it comes to http, depending on your taste it might be
a good idea to integrate the xml entity mapping and iconv calling with
the buffering code to avoid excessive memory use and additional scan
loops.

/Jörg

Am Samstag, den 20.05.2006, 10:18 +0900 schrieb Daishi Kato:
> Hi,
> 
> I too have noticed this problem while I was modifying
> http-client.scm. ngrep (or tcpdump) shows
> several packets for even a small http request/response.
> This could have been solved by buffering in http-client,
> but the better solution I imagined was also to buffer
> at tcp port level, which I'm not sure how to code it.
> 
> Thanks,
> Daishi
> 
> At Fri, 19 May 2006 14:16:47 -0400,
> Graham Fawcett wrote:
> > 
> > On 5/19/06, Graham Fawcett <address@hidden> wrote:
> > > Hi folks,
> > >
> > > I'm seeing strange behaviour in Spiffy regarding Keep-alive
> > > connections. On my Linux server, subsequent requests on Keep-alive
> > > connections are taking much longer to complete than requests on new
> > > connections -- the wall-clock time is more than 10x greater (CPU usage
> > > on client and server is almost identical). Tests and results are below.
> > 
> > All right, I've gotten to the bottom of it. It definitely has to do
> > with small messages, and has little to do (directly) with Spiffy,
> > though Spiffy's design (or tcp-server's) does aggravate the problem.
> > 
> > Small content can be sent extremely efficiently if the entire HTTP
> > response can be fit into a single IP frame -- that is, both the
> > header+body is smaller than the MTU on the IP interface, and the
> > message is sent at once to the output-port, not dribbled out via
> > multiple write requests (which can force the output to be fragmented
> > across multiple packets). It may be a Linux-specific problem -- there
> > appear to be numerous posts on the Web about small-message passing
> > over TCP on Linux being something of a bottleneck.
> > 
> > Retooling my Web stack with a (short-response) procedure, which writes
> > only once if the message length <= MTU, immediately solved the
> > performance problem here.
> > 
> > I'm not a TCP wizard, so I'm not entirely clear why this behaviour
> > affects persistent connections more than newly-created ones, nor why
> > the performance difference at the client-side is so huge. It's
> > significant enough that, if anyone is using tcp-server (or
> > http-server, or Spiffy) for small-message passsing (e.g. an Ajax
> > application, where a client might ask for a lot of very small
> > messages) they might see a signifigant performance drop -- like I did!
> > 
> > A general solution would be to introduce a buffer in front of the
> > tcp-output port, where output queues up until the content reaches a
> > size near the MTU, and then flushes itself out. The buffer could have
> > port semantics, and so could be flushed, closed, etc., by client code,
> > passing these effects onward to the tcp-output port. Adding such an
> > element to tcp-server could improve performance significantly to a
> > number of network apps, with little effort. If I get time, I'll try to
> > whip up such a buffer, and do some tests; but I think my R&D time has
> > run out for the week.
> > 
> > Thanks for listening to me talk to myself in public! :-)
> > 
> > Graham
> > 
> > 
> > _______________________________________________
> > Chicken-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/chicken-users
> 
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>