>> I wonder the optional RFC2616 pipelining mechanism for requests in 
>> HTTP/1.1
>> is anything utilized by clients in the real world or just hypothetical?
>> Currently no ICS code (client/server) supports it.

> Pipelining use would require changing the state machine in ICS component. At 
> first glance I don't think it is too much difficult to implement. But 
> performance would be enhanced only when using threads to serve each request 
> in the HTTP server component. The thread has to be used not for the entire 
> client instance but for HTTP request processing only so that pipelining 
> could start different threads to execute each request. Of course 
> serialization would be necessary to send the results in the correct order.

> Is there any client which make use of pipelining ? I doubt !

I don't know, but I'm sure there are. For example, web page downloaders may
do - as this method is less server-expensive (it may use single thread to
process all of requests - not in parallel of course, but it may process
clients in parallel). In real life, if all clients would make use of
pipelining, server CPU and RAM usage would drop significantly (as less
connections would be involved) resulting in saturated client connections.

I did something like this for TPop3Cli and TNntpCli and observed significant
performance boost (I was writing about this some time - year or two - ago).
The changes needed for clients are not that large (at least for TPop3Cli and
TNntpCli weren't), but for proper usage of this feature, logic had to be
extended - performance boost gained this way was still worth it
anyway for both clients connected throught classical network connections
(ethernet, dialup) and the GPRS ones (as less packets were transmitted,
meaning less bytes transferred in both ways). Also note that in a lagged
networks performance boost is even more noticeable (user had to wait for
every send command and get response steps, and when pipelining is used, user
would wait only for two such steps - send all commands and get all

The only caveat I find is - if the client's connection throughtput is higher
than client's overall performance and client doesn't use multithreading,
such actions may lock it (make unresponsive) for as long as responses are
comming and are parsed. One way to overcome this is to use multithreading
and put connection in a separate thread - obviously. Others include
agressive code optimzation (neither "str := str + char" nor frequent
progressbar updates allowed...) - what I find difficult for most today's
Delphi programmers (the funniest thing is that the same guys say "Delphi is
a bad compiler").

Piotr Dalek

PS. Fajny portal... >>> http://link.interia.pl/f196a

To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to