Tutoriel Redis (13) : Explication détaillée du pipeline

1. Protocole de réponse aux requêtes et RTT :

Redis est un serveur TCP typique basé sur le modèle C/S. Dans le processus de communication entre le client et le serveur, le client lance généralement la demande en premier, et le serveur effectue les tâches correspondantes après avoir reçu la demande, et envoie enfin les données obtenues ou les résultats du traitement au client sous la forme d'une réponse. Durant ce processus, le client attendra de manière bloquante les résultats renvoyés par le serveur. Voir la séquence de commandes suivante :

Client: INCR X
    Server: 1
    Client: INCR X
    Server: 2
    Client: INCR X
    Server: 3
    Client: INCR X
    Server: 4

Dans le processus de chaque paire de requête et de réponse, nous devons supporter la surcharge supplémentaire causée par la transmission réseau. Nous appelons habituellement ce temps aérien RTT (Round Trip Time). Nous supposons maintenant que le RTT de chaque requête et réponse est de 250 millisecondes et que notre serveur peut traiter 100 000 données en une seconde, mais le résultat est que notre serveur peut traiter au maximum 4 requêtes par seconde. Pour résoudre ce problème de performances, comment pouvons-nous l’optimiser ?

2. Pipelining :

Redis a fourni la prise en charge des pipelines de commandes dans les toutes premières versions. Avant de donner une explication spécifique, nous transformons d'abord l'exemple ci-dessus de la méthode de réponse synchrone en une méthode de réponse asynchrone basée sur le pipeline de commandes, afin que chacun puisse avoir une meilleure compréhension perceptuelle.

   Client: INCR X
    Client: INCR X
    Client: INCR X
    Client: INCR X
    Server: 1
    Server: 2
    Server: 3
    Server: 4

Comme le montre l'exemple ci-dessus, après l'envoi de la commande, le client n'a pas besoin d'attendre immédiatement une réponse du serveur, mais peut continuer à envoyer les commandes suivantes. Une fois la commande envoyée, les réponses à toutes les commandes précédentes sont lues en même temps. Cela permet d'économiser la surcharge RTT en mode synchrone.
La dernière chose à noter est que si le serveur Redis constate que la requête du client est basée sur un pipeline, après avoir reçu la requête et l'avoir traitée, le serveur stockera les données de réponse de chaque commande dans la file d'attente, puis l'enverra. au client.

3. Benchmark :

Voici les cas de test et les résultats des tests du site officiel de Redis. Il convient de noter que ce test est basé sur le bouclage (127.0.0.1), donc le temps pris par RTT est relativement faible s'il est basé sur l'interface réseau réelle, alors l'amélioration des performances apportée par le mécanisme de pipeline sera encore plus. significatif.

require 'rubygems'
    require 'redis'
    
    def bench(descr)
        start = Time.now
        yield
        puts "#{descr} #{Time.now-start} seconds"
    end
    
    def without_pipelining
        r = Redis.new
        10000.times {
            r.ping
        }
    end
    
    def with_pipelining
        r = Redis.new
        r.pipelined {
            10000.times {
                r.ping
            }
        }
    end
    
    bench("without pipelining") {
        without_pipelining
    }
    bench("with pipelining") {
        with_pipelining
    }
    //without pipelining 1.185238 seconds
    //with pipelining 0.250783 seconds

Ce qui précède est le contenu du didacticiel Redis (13) : explication détaillée du pipeline. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (m.sbmmt.com) !