Node-redis: Pipeline

Est-ce fait via les commandes client.multi & multi.exec ?

Salut @saritasa -- le pipeline est automatique. Cela se passe toujours à l'intérieur du client. Vous n'avez pas besoin d'utiliser multi ou exec pour l'activer.

Salut Bryce,

1. Je suis confus, à quoi servent les fonctions "multi" dans node_redis alors?
2. Quel est l'algorithme utilisé pour pipeliner automatiquement les commandes ?

Merci,
Dmitry

Les opérations multiples proviennent de la spécification du protocole Redis, elles ont un objectif transactionnel en dehors du pipeline : http://redis.io/commands/multi

En termes de fonctionnement du pipeline : http://redis.io/topics/pipelining, il s'agit simplement que le client écrive des commandes à Redis aussi rapidement que vous les envoyez sans attendre la réponse avant d'écrire la suivante. Le client garde une trace des commandes envoyées, puis réaligne les réponses avec les commandes envoyées une fois que Redis a répondu.

Merci Bryce, je comprends comment fonctionne http://redis.io/topics/pipelining . dans une application node.js - comment le code doit-il être structuré pour que les requêtes soient acheminées ?

donc dans l'exemple ci-dessous

hgetall & expire - sont en pipeline ou non ? L'un des appels est à l'intérieur du rappel.

fonction getByID(table, id, suivant) {
if (!success) return setTimeout(function () {
getByID(table, id, suivant);
}, 2000);

var end = utils.getEndTime(),
    base = getBase(),
    client = getClient(PK2str(table, id)),
    key = getHashID(table, id);

base.sismember(table, key, function (err, val) {
    if (err || !val) return next();

    client.hgetall(key, function (err, val) {
        if (err || !val) return next(new Error('Expired'), id);

        val = arrays_parse(table, val);
        next(null, val);
        client.expire(key, cfg.ttl.shards);

        if (!exports.silent) {
            profiler.log('cache', {
                'table': table,
                'id': key,
                'method': 'getByID',
                'data': val,
                'time': end()
            });
        }
    });  
});

}

Toutes les commandes sont envoyées « en pipeline », mais elles ne seraient jamais envoyées dans le même cadre d'écriture en pipeline pour une ou deux raisons :

1. Le rappel pour le sismember est ce qui invoque l'appel hgetall -- par conséquent, vous empêchez implicitement que ces commandes soient mises en pipeline ensemble pour tout appel sismember donné. Le rappel n'est pas invoqué tant que Redis n'a pas répondu.
2. Si base et client sont des clients Redis différents, ils pourraient _JAMAIS_ partager le même pipeline.

Les commandes doivent être exécutées à partir du même contexte* pour voir tout avantage du pipeline. Par exemple, similaire à l'exemple PING dans les documents de pipeline de redis :

// These commands will all be pipelined together:
client.ping()
client.ping()
client.ping()
client.ping(function () {
  // This would *NEVER* be in the same pipeline frame as the other four because it requires a reply to be received first
  client.ping()
})

* ou à partir de contextes distincts s'il est envoyé plus rapidement que Redis ne répond, mais ne répond jamais à des contextes dépendants

je l'ai maintenant - merci! C'est un commentaire très précieux !

Je pense que le "pipelining automatique" de node_redis n'est pas le pipeline référencé par redis officiel.

Ce temps est appelé RTT (Round Trip Time). Il est très facile de voir comment cela peut affecter les performances lorsqu'un client doit effectuer de nombreuses requêtes à la suite (par exemple, ajouter de nombreux éléments à la même liste, ou remplir une base de données avec de nombreuses clés). Par exemple, si le temps RTT est de 250 millisecondes (dans le cas d'un lien très lent sur Internet), même si le serveur est capable de traiter 100 000 requêtes par seconde, nous pourrons traiter au maximum quatre requêtes par seconde.
Si l'interface utilisée est une interface de bouclage, le RTT est beaucoup plus court (par exemple mon hôte rapporte 0,044 millisecondes ping 127.0.0.1), mais c'est quand même beaucoup si vous devez effectuer de nombreuses écritures à la suite.

Ce que signifie le pipeline par redis officiel, c'est combiner plusieurs commandes et les envoyer une fois pour contrer la latence due à RTT, qui n'est pas adressée par node_redis. Et le "pipelining automatique" dans node_redis envoie en fait autant de commandes que possible en même temps en utilisant le modèle de programmation asynchrone de Node.

Voici un bon article traitant de cette question. http://informatikr.com/2012/redis-pipelining.html

@Vizwind @saritasa .multi et .batch utilisent le pipeline comme prévu à partir de la version 2.2.