the write strategy of the client implement affects the set performance dramatically?

[Maxim Dounin]

Hello!

On Wed, Mar 05, 2008 at 11:59:25AM +0300, Tomash Brechko wrote:

>On Wed, Mar 05, 2008 at 05:29:03 +0300, Maxim Dounin wrote:
>> E.g. for 'noreply' commands recently introduced you have to use
>> TCP_NODELAY anyway.
>
>This depends on how you look on the problem.  With 'noreply' you can't
>tell when the command will take the effect (you won't get the reply,
>so even if you push the command to the server, it will still be
>unclear when it will be completed).  If so, then there's no real need
>to push the request.  C::M::F does not use TCP_NODELAY at all.  This
>way the last chunk (and hence 'noreply' command execution) may be
>delayed up to 500ms (time is from
>http://en.wikipedia.org/wiki/Nagle_algorithm), but OTOH the throughput
>will be better if you are sending other commands during this time.

Consider the following scenario: 

1. Client sents several 'noreply' commands.
2. Then normal command.
3. Repeat from 1.

This way without TCP_NODELAY you have to wait for delayed ack timeout on 
every iteration.

Probably the best solution here is to switch on TCP_NODELAY when 
you expect reply.  This will keep packet rate low while not 
penalizing the above scenario.

Using TCP_NOPUSH/TCP_CORK appropriately may help too, but it's less 
portable.

>For C::M::F I tried both TCP_NODELAY and TCP_CORK in all combinations,
>but couldn't achieve any _repeatable_ latency improvement (i.e. I
>observed both speedups and slowdowns on different runs; maybe I did
>the measurements wrongly?). However switching to TCP_CORK in the
>server when needed does really improve latency.

 From my experience delayed ack problem effects are unnoticable 
unless you specially craft the workload.  But when you real 
workload happens to trigger the problem - you have nothing to do 
except turning on TCP_NODELAY (or turning off delayed ack).

Additionally, problems with delayed acks are rather hard to 
diagnose at production web service, and probably it's a good idea to 
address the issue before it'll appear in real life. 

Maxim Dounin