Re: Redis pipeline vs multi/exec

[Salvatore Sanfilippo]

Hello

On Fri, Nov 9, 2012 at 10:42 AM, Kapil Israni <kapil....@gmail.com> wrote:
> We are sending batch statements to redis server which is under heavy load,
> both writes and reads. Right now we are using multi/exec for batch
> statements, "atomicity" is not necessarily an application requirement. We
> are using multi/exec just for batching purpose. I was wondering if thats the
> case will we be better off in terms of performance by using pipeline?

Pipelining will perform better in your case for two reasons:

1) MULTI/EXEC has a cost itself, to accumulate commands, send back the
QUEUED reply, and so forth.
2) MULTI/EXEC prevent other requests to be interleaved (your next
question basically), the block of commands is executed in isolation as
a whole thing.

So if you don't have atomicity concerns (other than the single command
being atomic, and this is always true in Redis), just use pipelining.

> Also reading the following from redis transaction writeup
> (http://redis.io/topics/transactions) I am a little confused by - "It can
> never happen that a request issued by another client is served in the middle
> of the execution of a Redis transaction."
>
> Isnt that statement true for any redis write or even read command, since
> redis is single-threaded?

Normally every Redis single command is isolated.
With transactions the group of commands inside the transaction is
isolated as well as an unique thing, as if it was an unique command.

So if I do

MULTI
SADD foo a
SADD foo b
EXEC

And other clients are calling SMEMBERS, it is not possible that a
client will just "a" as a result of the command, but will always see
nothing at all or "a,b".

Cheers,
Salvatore

> If it helps we are running on redis 2.4.13 and ruby 1.9.3 is the client
> driver.



--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter