Comment vérifier les paramètres de référence Redis-Redis-php.cn

Redis est livré avec un outil appelé redis-benchmark pour simuler N clients émettant M requêtes en même temps. (similaire au programme Apacheab). Utilisez la commande redis-benchmark -h pour afficher les paramètres de référence.

以下参数被支持：

    Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests> [-k <boolean>]

     -h <hostname>      Server hostname (default 127.0.0.1)
     -p <port>          Server port (default 6379)
     -s <socket>        Server socket (overrides host and port)
     -c <clients>       Number of parallel connections (default 50)
     -n <requests>      Total number of requests (default 10000)
     -d <size>          Data size of SET/GET value in bytes (default 2)
     -k <boolean>       1=keep alive 0=reconnect (default 1)
     -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
      Using this option the benchmark will get/set keys
      in the form mykey_rand:000000012456 instead of constant
      keys, the <keyspacelen> argument determines the max
      number of values for the random number. For instance
      if set to 10 only rand:000000000000 - rand:000000000009
      range will be allowed.
     -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
     -q                 Quiet. Just show query/sec values
     --csv              Output in CSV format
     -l                 Loop. Run the tests forever
     -t <tests>         Only run the comma separated list of tests. The test
                        names are the same as the ones produced as output.
     -I                 Idle mode. Just open N idle connections and wait.</tests></numreq></numreq></keyspacelen></keyspacelen></boolean></size></requests></clients></socket></port></hostname></boolean></requests></clients></port></host>

Copier après la connexion

Vous devez démarrer une instance Redis avant l'analyse comparative. Généralement, le test démarre comme ceci :

redis-benchmark -q -n 100000

Copier après la connexion

Cet outil est très pratique à utiliser et vous pouvez utiliser votre propre outil de test de référence. Cependant, lors du démarrage du test de référence, nous devons y prêter attention. quelques détails.

Exécutez uniquement un sous-ensemble de certains cas de test

Il n'est pas nécessaire d'exécuter tous les tests par défaut à chaque fois que vous exécutez redis-benchmark. Vous pouvez utiliser le paramètre "-t" pour spécifier les cas de test qui doivent être exécutés, comme dans l'exemple suivant :

$ redis-benchmark -t set,lpush -n 100000 -q
SET: 74239.05 requests per second
LPUSH: 79239.30 requests per second

Copier après la connexion

Dans le test ci-dessus, nous avons uniquement exécuté les commandes SET et LPUSH, et exécuté en mode silencieux (utilisez le paramètre -q).

Vous pouvez également spécifier directement la commande à exécuter directement, comme dans l'exemple suivant :

$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second

Copier après la connexion

Sélectionnez la taille de la plage de la clé de test

Par défaut, le test de base utilise une seule clé. Dans une base de données en mémoire, il n'y aura pas une énorme différence entre le test à clé unique et le monde réel. Bien entendu, l’élargissement de la plage de clés peut simuler des échecs de cache réels.

Pour le moment, nous pouvons utiliser la commande -r. Par exemple, si nous voulons effectuer 1 million d'opérations SET en continu, en utilisant 100 000 clés aléatoires à chaque fois, nous pouvons utiliser la commande suivante :

$ redis-cli flushall
OK

$ redis-benchmark -t set -r 100000 -n 1000000
====== SET ======
  1000000 requests completed in 13.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.76% `<h3>Utiliser le pipeline</h3><p>Par défaut, Chaque client envoie la requête suivante une fois qu'une requête est terminée (le test simulera 50 clients à moins qu'un nombre spécial ne soit spécifié avec -c), ce qui signifie que le serveur lit la commande de chaque client presque dans l'ordre. RTT est également payant.</p><p>Le monde réel sera plus compliqué. Redis prend en charge /topics/pipelining, ce qui permettra d'exécuter plusieurs commandes à la fois. Utilisez le pipeline Redis pour augmenter le taux de transactions par seconde de votre serveur. </p><p>Le cas suivant est un exemple test d'utilisation du pipeline pour organiser 16 commandes sur un Macbook air 11 : </p><pre class="brush:php;toolbar:false">$ redis-benchmark -n 1000000 -t set,get -P 16 -q
SET: 403063.28 requests per second
GET: 508388.41 requests per second

Copier après la connexion

N'oubliez pas d'utiliser le pipeline lorsque plusieurs commandes doivent être traitées. #🎜 🎜#

Pièges et malentendus

Le premier point est évident : la règle d'or du benchmarking est d'utiliser le même standard lors du test de différentes versions de Redis, et la même charge de travail peut être utilisée . Testez ou testez avec les mêmes paramètres Si vous testez Redis avec d'autres outils, vous devez faire attention aux différences dans les détails fonctionnels

Redis est un serveur : tous. les commandes incluent. La consommation réseau ou IPC. Cela signifie que cela n'a aucun sens de comparer avec SQLite, Berkeley DB, Tokyo/Kyoto Cabinet, etc., car la majeure partie de la consommation concerne le protocole réseau 🎜🎜#Les commandes les plus courantes dans Redis retournent. confirmation. Par exemple, l'opération d'écriture de MongoDB ne renvoie pas de confirmation, mais certains systèmes de stockage de données le font. Il n'est pas significatif de comparer Redis avec d'autres systèmes de stockage de commandes unidirectionnelles 🎜#
Redis est un service monothread Il n'est pas conçu pour être optimisé pour plusieurs processeurs. . Si vous souhaitez bénéficier des avantages du multicœur, envisagez d'activer plusieurs instances. Il est injuste de comparer Redis à instance unique avec des bases de données multithread. #Un malentendu courant est que redis-benchmark donne délibérément une meilleure apparence au test de référence et que les données affichées semblent artificielles, plutôt que sous le produit réel.
L'outil Redis-benchmark peut calculer rapidement et facilement le . paramètres de performances de la machine dans des conditions matérielles spécifiques. Cependant, ce n'est généralement pas le débit maximum que le serveur Redis peut atteindre en utilisant le pipeline et plus encore, les clients rapides (tels que Hiredis) peuvent atteindre un débit plus élevé. Par défaut, redis-benchmark utilise uniquement la concurrence pour améliorer le débit (créer plusieurs connexions). Il n'utilise pas de pipeline ou d'autres techniques de concurrence, il utilise simplement plusieurs connexions au lieu du multithreading.
Si vous souhaitez utiliser le mode pipeline pour les tests de référence (afin d'obtenir un débit plus élevé), vous pouvez utiliser le paramètre -P. De nombreuses applications utilisant Redis dans des environnements de production adoptent cette approche pour améliorer les performances.
Enfin, le test de référence doit utiliser les mêmes opérations et données à des fins de comparaison. Si celles-ci ne sont pas les mêmes, alors le test de référence n'a aucun sens.
Par exemple, Redis et memcached peuvent comparer les opérations GET/SET en mode monothread. Les deux sont des bases de données en mémoire et les protocoles sont fondamentalement les mêmes. Même la manière de fusionner plusieurs requêtes en une seule est similaire (pipelining). Cette comparaison est significative après avoir utilisé le même nombre de connexions.
Ce qui suit est un excellent exemple testé sur Redis (antirez) et memcached (dormando).

antirez 1 - Sur Redis, Memcached, Speed, Benchmarks et The Toilet

dormando - Redis VS Memcached (banc légèrement meilleur)

antirez 2 - Une mise à jour sur le benchmark Memcached/Redis

Vous pouvez trouver les résultats finaux ci-dessous pour les mêmes conditions. Il n'y a pas beaucoup de différence entre les deux. Veuillez noter qu'au moment des tests finaux, les deux étaient entièrement optimisés.

Enfin, lorsqu'un serveur particulièrement performant est comparé (comme Redis, memcached, etc.), il est difficile d'utiliser pleinement les performances du serveur. Habituellement, le goulot d'étranglement se situe du côté client plutôt que du côté serveur. Dans ce cas, le client (comme le programme de référence lui-même) doit être optimisé ou utiliser plusieurs instances pour atteindre un débit maximal.

Facteurs affectant les performances de Redis

Il existe plusieurs facteurs qui déterminent directement les performances de Redis. Ils peuvent modifier les résultats du benchmark, nous devons donc y prêter attention. Normalement, les paramètres par défaut de Redis sont suffisants pour fournir des performances efficaces, aucun réglage n'est donc requis.

La bande passante et la latence du réseau sont généralement les plus gros défauts. Je recommande d'utiliser la commande ping pour détecter la latence entre le serveur et le client avant l'analyse comparative. En fonction de la bande passante, le débit maximum peut être calculé. Par exemple, si une chaîne de 4 Ko est insérée dans Redis et que le débit est de 100 000 q/s, alors 3,2 Gbits/s de bande passante sont réellement requis, donc une connexion réseau de 10 Gbits/s n'est pas suffisante. . Dans de nombreux services en ligne, la bande passante du réseau devient souvent le facteur limitant du débit Redis avant le processeur. Afin d'atteindre un débit élevé et de dépasser les limitations TCP/IP, une carte réseau de 10 Gbits/s ou plusieurs cartes réseau de 1 Gbits/s sont finalement utilisées.
Le processeur est un autre facteur d'influence important puisqu'il s'agit d'un modèle monothread, Redis préfère un cache volumineux et un processeur rapide au lieu du multicœur. Dans ce scénario, le processeur Intel est plus recommandé. Les processeurs AMD sont probablement deux fois moins puissants que les processeurs Intel (par rapport aux plates-formes Nehalem EP/Westmere EP/Sandy). Si les autres conditions sont égales, le processeur constitue le goulot d'étranglement du benchmark Redis.
Lors de l'accès à de petits objets, la vitesse de la mémoire et la bande passante ne semblent pas être très importantes, mais pour les gros objets (> 10 Ko), cela devient important. De manière générale, les gens n'achètent pas de modules de mémoire plus performants pour optimiser Redis.
Redis sera lent sur la VM. La virtualisation entraînera une consommation supplémentaire sur les opérations normales, tandis que Redis n'aura pas beaucoup de surcharge sur les appels système et les terminaux réseau. Lorsque la latence est particulièrement préoccupante, il est recommandé de déployer Redis et de l'exécuter sur un serveur physique. Sur le périphérique de virtualisation le plus avancé (VMware), les résultats des tests de redis-benchmark sont deux fois plus lents que ceux de la machine physique, et une grande partie du temps CPU est consommée en appels système et en interruptions.
Si le serveur et le client s'exécutent sur la même machine, le bouclage TCP/IP et les sockets de domaine Unix peuvent être utilisés. Pour Linux, l'utilisation de sockets Unix peut être 50 % plus rapide que le bouclage TCP/IP. redis-benchmark utilise l'interface de bouclage TCP/IP par défaut.
Les avantages des sockets de domaine Unix deviennent moins importants lorsqu'un pipeline lourd est utilisé.
Lorsque vous utilisez une connexion réseau et que la taille du paquet Ethernet est inférieure à 1 500 octets, le regroupement de plusieurs commandes dans un pipeline peut améliorer considérablement l'efficacité. En fait, lors du traitement de requêtes de 10 octets, 100 octets et 1 000 octets, le débit est presque le même. Voir la figure ci-dessous pour plus de détails.

Comment vérifier les paramètres de référence Redis

Les performances de Redis sur les serveurs CPU multicœurs dépendent également de la configuration NUMA et de la position de liaison du processeur. L'impact le plus important de Redis-benchmark est qu'il utilise de manière aléatoire les cœurs de processeur. Afin d'obtenir des résultats précis, vous devez utiliser des outils de processeur fixes (sous Linux, vous pouvez utiliser tâcheset ou numactl). Le moyen le plus efficace consiste à séparer le client et le serveur en deux processeurs différents pour utiliser le cache de troisième niveau. Voici quelques benchmarks utilisant un SET de données de 4 Ko, utilisant différentes configurations pour trois processeurs (AMD Istanbul, Intel Nehalem EX et Intel Westmere). Veuillez noter qu'il ne s'agit pas d'un test spécifique au processeur.

Comment vérifier les paramètres de référence Redis

En configuration élevée, le nombre de connexions client est également un facteur important. La boucle d'événements de Redis bénéficie d'epoll/kqueue et est donc hautement évolutive. Redis a été évalué avec plus de 60 000 connexions et peut toujours maintenir 50 000 q/s. En règle générale, 30 000 connexions n’ont que la moitié du débit de 100 connexions. Vous trouverez ci-dessous un test sur le nombre de connexions et le débit.

Comment vérifier les paramètres de référence Redis

在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在thread。Jumbo frames 还可以在大对象使用时候获得更高性能。
在不同平台下面，Redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。若非编译自行进行的 Redis，可用 INFO 命令验证内存分配方式。请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异，只能通过生产环境下面的 Redis 实例来查看。

其他需要注意的点

任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。

一个好的实践是尽可能在隔离的硬件上面测试。需要检查基准测试是否受到其他服务器活动的影响，如果无法实现的话。
有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 CPU 分配策略。这种策略可以在 OS 层面配置。有些 CPU 型号相对其他能更好的调整 CPU 负载。为了达到可重现的测试结果，最好在做基准测试时候设定 CPU 到最高使用限制。
一个重要因素是配置尽可能大内存，千万不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的内存限制。
注意在执行基准测试时，如果使用了 RDB 或 AOF，请避免同时进行其他 I/O 操作。避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上的 EBS）。
将 Redis 日志级别设置到 warning 或者 notice。避免将日志放到远程文件系统。
避免使用检测工具，它们会影响基准测试结果。查看服务器状态可使用 INFO 命令，但使用 MONITOR 命令会严重影响测试准确性。

不同云主机和物理机器上的基准测试结果

这些测试模拟了 50 客户端和 200w 请求。
使用了 Redis 2.6.14。
使用了 loopback 网卡。
key 的范围是 100 w。
同时测试了有 pipelining 和没有的情况（16 条命令使用 pipelining）。

Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (with pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second

Copier après la connexion

Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (without pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second

Copier après la connexion

Linode 2048 instance (with pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -P 16
SET: 195503.42 requests per second
GET: 250187.64 requests per second
LPUSH: 230547.55 requests per second
LPOP: 250815.16 requests per second

Copier après la connexion

Linode 2048 instance (without pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 35001.75 requests per second
GET: 37481.26 requests per second
LPUSH: 36968.58 requests per second
LPOP: 35186.49 requests per second

Copier après la connexion

高性能硬件下面的基准测试

Redis2.4.2 。
默认连接数，数据包大小 256 bytes。
Linux 是SLES10 SP3 2.6.16.60-0.54.5-smp，CPU 是 2 xIntel X5670 @ 2.93 GHz。
固定 CPU，但是使用不同 CPU 内核。

使用 unix domain socket：

$ numactl -C 6 ./redis-benchmark -q -n 100000 -s /tmp/redis.sock -d 256
PING (inline): 200803.22 requests per second
PING: 200803.22 requests per second
MSET (10 keys): 78064.01 requests per second
SET: 198412.69 requests per second
GET: 198019.80 requests per second
INCR: 200400.80 requests per second
LPUSH: 200000.00 requests per second
LPOP: 198019.80 requests per second
SADD: 203665.98 requests per second
SPOP: 200803.22 requests per second
LPUSH (again, in order to bench LRANGE): 200000.00 requests per second
LRANGE (first 100 elements): 42123.00 requests per second
LRANGE (first 300 elements): 15015.02 requests per second
LRANGE (first 450 elements): 10159.50 requests per second
LRANGE (first 600 elements): 7548.31 requests per second

Copier après la connexion

使用 TCP loopback：

$ numactl -C 6 ./redis-benchmark -q -n 100000 -d 256
PING (inline): 145137.88 requests per second
PING: 144717.80 requests per second
MSET (10 keys): 65487.89 requests per second
SET: 142653.36 requests per second
GET: 142450.14 requests per second
INCR: 143061.52 requests per second
LPUSH: 144092.22 requests per second
LPOP: 142247.52 requests per second
SADD: 144717.80 requests per second
SPOP: 143678.17 requests per second
LPUSH (again, in order to bench LRANGE): 143061.52 requests per second
LRANGE (first 100 elements): 29577.05 requests per second
LRANGE (first 300 elements): 10431.88 requests per second
LRANGE (first 450 elements): 7010.66 requests per second
LRANGE (first 600 elements): 5296.61 requests per second

Copier après la connexion

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!