Re: pipelined client/server behaviour

The worse aspect kicked in once servers started dropping connections 
when they got a pipelined request.  Rather a negative impact on 
performance that one, esp with connection-based authentication.

So overall statistically we saw it as worse, and the benefit on the 
sites that supported it seemed very small as well.  You're only talking 
about saving one RTTs per request to send requests serialized (after 
response received) than pipelined.  The biggest performance improvement 
we saw in testing came about from the reuse of the connection.

I guess if all servers and intermediaries supported pipelining, it would 
perform better overall, but I don't think it's widespread enough yet, so 
we decided to trade a small performance loss for an improvement in 
stability and ease of implementation.  We may still revert on this.

Adrien



Adrian Chadd wrote:
> 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:31:48 UTC