Re: pipelined client/server behaviour

On Sun, Apr 01, 2007, Adrien de Croy wrote:
> 
> Is there still some confusion about what we mean by pipelining?

There's none from me. I understand that pipelining wasn't viewed as a
property of connections, its what you've said:

> In my understanding it's when multiple requests are sent down a single 
> connection and subsequent requests are sent before the previous response 
> is received back.

And the behaviour of this is what I'm going to do a little more research
into. I'm currently specifying the pipeline in this application as a property
of the connection and requests will be pipelined only to the server or
upstream over the same connection - I'm trying to avoid having to build
my own pipeline logic and would like instead to trust the user-agent's
pipeline logic.

(This means passing the invalid HTTP replies back up to the client though;
and that could be rather exciting to try and attempt..)

> The approach we took with WinGate was to serialize the requests.  Whilst 
> this effectively breaks potential pipelining performance benefits, it's 
> about the only way we found to make the system stable.  We tried various 
> ways where we honoured the client and server pipelining (i.e. pass 
> through), but actually found the performance to be worse.  So now, we 
> don't even process the FD_READ notification on the socket if it's a 
> client send and we've received the entire message from the client and 
> the server response hasn't been sent back, so TCP windowing etc should 
> choke back the sends of subsequent requests.

You found it performed worse? Did you ever investigate why it turned out to be
worse?




Adrian

Received on Sunday, 1 April 2007 11:08:03 UTC