Pourquoi le nombre de connexions client affecte-t-il les performances de Redis?

Question

J'ai lu la documentation Redis et je ne comprends pas le paragraphe suivant (de lien http://redis.io/topics/benchmarks):

« itérer Naïvement sur les commandes Redis synchrones ne se Redis pas de référence, mais mesure plutôt votre réseau (ou IPC) Pour vraiment tester Redis, vous avez besoin de plusieurs connexions et/ou ... "

J'ai effectué les tests suivants pour voir la différence de vitesse entre 1 connexion et 500 connexions. Comme nous pouvons le voir, c'est beaucoup plus lent quand il n'y a qu'une seule connexion. Mais je ne comprends pas pourquoi et comment le nombre de connexions affecte les performances de la vitesse Redis. Je suis nouveau à la mise en réseau informatique, toute aide serait appréciée!

$ redis-benchmark -c 500 -t ping 
====== PING_INLINE ====== 
    10000 requests completed in 0.10 seconds 
    500 parallel clients 
    3 bytes payload 
    keep alive: 1 

$ redis-benchmark -c 1 -t ping 
====== PING_INLINE ====== 
    10000 requests completed in 0.19 seconds 
    1 parallel clients 
    3 bytes payload 
    keep alive: 1 

Answer 1

Lorsque la latence> débit, vous avez besoin de multiples demandes en vol pour goulot d'étranglement sur le débit au lieu d'un temps de latence aller-retour.

par exemple. si le trajet aller-retour du réseau est de 10 ms, un client qui attend le résultat d'une requête avant d'en envoyer une autre est mathématiquement limité à 100 requêtes/s. Si votre serveur peut gérer plus que cela, vous ne pouvez pas le tester avec un seul client.

---

La logique est la même que pour un transfert de données régulier sur des réseaux, par ex. Tailles de fenêtre TCP. Cet article wiki (https://en.wikipedia.org/wiki/Bandwidth-delay_product) pourrait aider à clarifier le concept de devoir garder plusieurs paquets/opérations en vol. Pour une demande redis, la latence totale inclut le temps de traitement + l'heure du réseau. Si vous gâchez cela, vous ne serez pas près de maintenir le processeur (ou le réseau) du serveur à 100% occupé.

Notez que la réalisation de Instruction-Level Parallelism in a CPU est également le même concept. (Par exemple, pour additionner un tableau de flottants, vous devez utiliser au moins 3 accumulateurs si l'ajout de FP a une latence de 3 cycles et un débit par 1c, c'est-à-dire entièrement pipeliné).