So überprüfen Sie die Redis-Benchmark-Parameter
- PHPznach vorne
- 2023-06-04 12:12:121539Durchsuche
Redis verfügt über ein Tool namens Redis-Benchmark, um N Clients zu simulieren, die M Anfragen gleichzeitig stellen. (ähnlich dem Apacheab-Programm). Verwenden Sie den Befehl redis-benchmark -h, um die Benchmark-Parameter anzuzeigen.
以下参数被支持： 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>
Sie müssen vor dem Benchmarking eine Redis-Instanz starten. Im Allgemeinen wird der Test wie folgt gestartet:
redis-benchmark -q -n 100000
Dieses Tool ist sehr bequem zu verwenden und Sie können Ihr eigenes Benchmark-Testtool verwenden. Beim Starten des Benchmark-Tests müssen wir jedoch darauf achten einige Details.
Führen Sie nur eine Teilmenge einiger Testfälle aus.
Es ist nicht notwendig, jedes Mal, wenn Sie redis-benchmark ausführen, standardmäßig alle Tests auszuführen. Sie können den Parameter „-t“ verwenden, um die Testfälle anzugeben, die ausgeführt werden müssen, wie zum Beispiel das folgende Beispiel:
$ redis-benchmark -t set,lpush -n 100000 -q SET: 74239.05 requests per second LPUSH: 79239.30 requests per second
Im obigen Test haben wir nur die Befehle SET und LPUSH ausgeführt und lief im stillen Modus (verwenden Sie den Parameter -q).
Sie können den Befehl, der direkt ausgeführt werden soll, auch direkt angeben, wie im folgenden Beispiel:
$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second
Wählen Sie die Bereichsgröße des Testschlüssels aus
Standardmäßig verwendet der Basistest einen einzelnen Schlüssel. In einer In-Memory-Datenbank wird es keinen großen Unterschied zwischen dem Einzelschlüsseltest und der realen Welt geben. Natürlich kann die Erweiterung des Schlüsselbereichs reale Cache-Fehler simulieren.
Zu diesem Zeitpunkt können wir den Befehl -r verwenden. Wenn wir beispielsweise kontinuierlich 1 Million SET-Operationen mit jeweils 100.000 Zufallsschlüsseln ausführen möchten, können wir den folgenden Befehl verwenden:
$ 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>Pipelining verwenden</h3><p>Standardmäßig Jeder Client sendet die nächste Anfrage, nachdem eine Anfrage abgeschlossen ist (der Benchmark simuliert 50 Clients, es sei denn, mit -c wird eine spezielle Zahl angegeben), was bedeutet, dass der Server die Befehle jedes Clients fast nacheinander liest. Auch RTT wird bezahlt.</p><p>Die reale Welt wird komplizierter sein, da Redis /topics/pipelining unterstützt und es somit möglich ist, mehrere Befehle gleichzeitig auszuführen. Verwenden Sie Redis-Pipelining, um die Transaktionsrate Ihres Servers pro Sekunde zu erhöhen. </p><p>Der folgende Fall ist ein Testbeispiel für die Verwendung von Pipelining zum Organisieren von 16 Befehlen auf einem 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
Denken Sie daran, Pipelining zu verwenden, wenn mehrere Befehle verarbeitet werden müssen. #🎜 🎜#
Fallen und MissverständnisseDer erste Punkt liegt auf der Hand: Die goldene Regel des Benchmarkings besteht darin, beim Testen verschiedener Redis-Versionen denselben Standard zu verwenden und die gleiche Arbeitslast zu verwenden . Wenn Sie Redis mit anderen Tools testen, müssen Sie auf die Unterschiede in den Funktionsdetails achten- Redis ist ein Server: alle Zu den Befehlen gehören Netzwerk- oder IPC-Verbrauch. Dies bedeutet, dass ein Vergleich mit SQLite, Berkeley DB, Tokyo/Kyoto Cabinet usw. sinnlos ist, da der Großteil des Verbrauchs auf dem Netzwerkprotokoll beruht Beispielsweise gibt der Schreibvorgang von MongoDB keine Bestätigung zurück, einige Datenspeichersysteme jedoch. Es ist nicht sinnvoll, Redis mit anderen Einweg-Befehlsspeichersystemen zu vergleichen. Der einfache Schleifenbetrieb von Redis ist eigentlich kein Benchmark-Test von Redis, sondern ein Test der Latenz Ihres Netzwerks (oder IPCs). Um Redis wirklich zu testen, müssen Sie mehrere Verbindungen (z. B. Redis-Benchmark) verwenden Fassen Sie mehrere Befehle zusammen, und Sie können auch Multithreading oder Multiprozess verwenden Zum Vergleich mit einem Persistenzserver (MySQL, PostgreSQL usw.) müssen Sie die Aktivierung von AOF und der entsprechenden fsync-Strategie in Betracht ziehen.
Redis ist ein Single-Thread-Dienst. Er ist nicht für die Optimierung für mehrere CPUs konzipiert . Wenn Sie die Vorteile von Multi-Core nutzen möchten, sollten Sie die Aktivierung mehrerer Instanzen in Betracht ziehen. Es ist unfair, Redis mit mehreren Threads zu vergleichen #Ein häufiges Missverständnis ist, dass Redis-Benchmark den Benchmark-Test absichtlich besser aussehen lässt und die angezeigten Daten künstlich erscheinen, anstatt dass das Redis-Benchmark-Tool schnell und einfach berechnen kann Leistungsparameter der Maschine unter bestimmten Hardwarebedingungen. Dies ist jedoch normalerweise nicht der maximale Durchsatz, den der Redis-Server mithilfe von Pipelining erreichen kann, und schnelle Clients (z. B. Hiredis) können einen höheren Durchsatz erzielen. Standardmäßig verwendet redis-benchmark nur Parallelität, um den Durchsatz zu verbessern (mehrere Verbindungen erstellen). Es verwendet kein Pipelining oder andere Parallelitätstechniken, sondern lediglich mehrere Verbindungen anstelle von Multithreading.
Wenn Sie den Pipelining-Modus für Benchmark-Tests verwenden möchten (um einen höheren Durchsatz zu erreichen), können Sie den Parameter -P verwenden. Viele Anwendungen, die Redis in Produktionsumgebungen verwenden, verwenden diesen Ansatz, um die Leistung zu verbessern. Schließlich muss der Benchmark-Test dieselben Operationen und Daten zum Vergleich verwenden. Wenn diese nicht identisch sind, ist der Benchmark-Test bedeutungslos.
Zum Beispiel können Redis und Memcached GET/SET-Vorgänge im Single-Threaded-Modus vergleichen. Bei beiden handelt es sich um In-Memory-Datenbanken, und die Protokolle sind grundsätzlich gleich. Auch die Art und Weise, mehrere Anfragen zu einer Anfrage zusammenzuführen, ist ähnlich. Dieser Vergleich ist sinnvoll, wenn die gleiche Anzahl von Verbindungen verwendet wird. -
Das Folgende ist ein großartiges Beispiel, das auf Redis (antirez) und memcached (dormando) getestet wurde.
antirez 1 – Über Redis, Memcached, Geschwindigkeit, Benchmarks und The Toilet
dormando – Redis VS Memcached (etwas bessere Bank)
antirez 2 – Ein Update zum Memcached/Redis-Benchmark
Die Endergebnisse finden Sie unten für die gleichen Bedingungen Es gibt keinen großen Unterschied zwischen den beiden. Bitte beachten Sie, dass beide zum Zeitpunkt des Endtests vollständig optimiert waren.
Wenn ein besonders leistungsstarker Server bewertet wird (z. B. Redis, Memcached usw.), ist es schwierig, die Serverleistung voll auszunutzen. Normalerweise liegt der Engpass eher auf der Clientseite als auf der Serverseite. In diesem Fall muss der Client (z. B. das Benchmark-Programm selbst) optimiert werden oder mehrere Instanzen verwenden, um den maximalen Durchsatz zu erreichen.
Faktoren, die die Leistung von Redis beeinflussen
Es gibt mehrere Faktoren, die die Leistung von Redis direkt beeinflussen. Sie können die Ergebnisse des Benchmarks verändern, daher müssen wir ihnen Aufmerksamkeit schenken. Normalerweise reichen die Standardparameter von Redis aus, um eine effiziente Leistung bereitzustellen, sodass keine Optimierung erforderlich ist.
Netzwerkbandbreite und Latenz sind normalerweise die größten Mängel. Ich empfehle, vor dem Benchmarking den Ping-Befehl zu verwenden, um die Latenz zwischen Server und Client zu erkennen. Anhand der Bandbreite lässt sich der maximale Durchsatz berechnen. Wenn beispielsweise ein 4-KB-String in Redis eingefügt wird und der Durchsatz 100.000 q/s beträgt, sind tatsächlich 3,2 Gbit/s Bandbreite erforderlich, sodass eine Netzwerkverbindung mit 10 Gbit/s nicht ausreicht . Bei vielen Onlinediensten wird die Netzwerkbandbreite oft früher zum limitierenden Faktor für den Redis-Durchsatz als die CPU. Um einen hohen Durchsatz zu erreichen und TCP/IP-Beschränkungen zu durchbrechen, kommen schließlich eine 10-Gbit/s-Netzwerkkarte oder mehrere 1-Gbit/s-Netzwerkkarten zum Einsatz.
CPU ist ein weiterer wichtiger Einflussfaktor. Da es sich um ein Single-Threaded-Modell handelt, bevorzugt Redis einen großen Cache und eine schnelle CPU anstelle von Multi-Core. In diesem Szenario wird eher eine Intel-CPU empfohlen. AMD-CPUs sind wahrscheinlich nur halb so leistungsstark wie Intel-CPUs (im Vergleich zu Nehalem EP/Westmere EP/Sandy-Plattformen). Wenn andere Bedingungen gleich sind, ist die CPU der Flaschenhals des Redis-Benchmarks.
Beim Zugriff auf kleine Objekte scheinen Speichergeschwindigkeit und Bandbreite nicht sehr wichtig zu sein, bei großen Objekten (> 10 KB) werden sie jedoch wichtig. Im Allgemeinen kaufen Menschen keine leistungsstärkeren Speichermodule, um Redis zu optimieren.
Redis wird auf VM langsam sein. Die Virtualisierung verursacht im Normalbetrieb zusätzlichen Verbrauch, während Redis bei Systemaufrufen und Netzwerkterminals keinen großen Overhead verursacht. Wenn die Latenz ein besonderes Problem darstellt, wird empfohlen, Redis bereitzustellen und auf einem physischen Server auszuführen. Auf dem fortschrittlichsten Virtualisierungsgerät (VMware) sind die Testergebnisse von Redis-Benchmark doppelt so langsam wie die auf der physischen Maschine, und Systemaufrufe und Interrupts verbrauchen viel CPU-Zeit.
Wenn sowohl Server als auch Client auf demselben Computer laufen, können sowohl TCP/IP-Loopback als auch Unix-Domänen-Sockets verwendet werden. Unter Linux kann die Verwendung von Unix-Sockets 50 % schneller sein als TCP/IP-Loopback. redis-benchmark verwendet standardmäßig die TCP/IP-Loopback-Schnittstelle.
Die Vorteile von Unix-Domain-Sockets verlieren an Bedeutung, wenn starkes Pipelining verwendet wird.
Wenn Sie eine Netzwerkverbindung verwenden und die Ethernet-Paketgröße weniger als 1500 Byte beträgt, kann das Packen mehrerer Befehle in Pipelining die Effizienz erheblich verbessern. Tatsächlich ist der Durchsatz bei der Verarbeitung von 10-Byte-, 100-Byte- und 1000-Byte-Anfragen nahezu gleich. Einzelheiten finden Sie in der folgenden Abbildung.
Die Redis-Leistung auf Multi-Core-CPU-Servern hängt auch von der NUMA-Konfiguration und der Prozessorbindungsposition ab. Die bedeutendste Auswirkung des Redis-Benchmarks besteht darin, dass CPU-Kerne zufällig verwendet werden. Um genaue Ergebnisse zu erhalten, müssen Sie feste Prozessortools verwenden (unter Linux können Sie tasket oder numactl verwenden). Der effektivste Weg besteht darin, Client und Server in zwei verschiedene CPUs aufzuteilen, um den Cache der dritten Ebene zu verwenden. Hier sind einige Benchmarks mit 4-KB-Datensatz und unterschiedlichen Konfigurationen für drei CPUs (AMD Istanbul, Intel Nehalem EX und Intel Westmere). Bitte beachten Sie, dass es sich hierbei nicht um einen CPU-spezifischen Test handelt.
Bei hoher Konfiguration ist auch die Anzahl der Clientverbindungen ein wichtiger Faktor. Die Ereignisschleife von Redis profitiert von epoll/kqueue und ist daher hoch skalierbar. Redis wurde mit mehr als 60.000 Verbindungen getestet und kann immer noch 50.000 q/s aufrechterhalten. Als Faustregel gilt, dass 30.000 Verbindungen nur die Hälfte des Durchsatzes von 100 Verbindungen haben. Nachfolgend finden Sie einen Test zur Anzahl der Verbindungen und zum Durchsatz.
在高配置下面，可以通过调优 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
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
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
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
更多使用 pipeline 的测试
$ redis-benchmark -n 100000 ====== SET ====== 100007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50% <p>注意：包大小从 256 到 1024 或者 4096 bytes 不会改变结果的量级 （但是到 1024 bytes 后，GETs 操作会变慢）。同样的，50 到 256 客户端的测试结果相同。当使用10个客户端时，总吞吐量无法达到最大吞吐量。</p><p>不同机器可以获的不一样的结果，下面是Intel T5500 1.66 GHz 在 Linux 2.6下面的结果：</p><pre class="brush:php;toolbar:false">$ ./redis-benchmark -q -n 100000 SET: 53684.38 requests per second GET: 45497.73 requests per second INCR: 39370.47 requests per second LPUSH: 34803.41 requests per second LPOP: 37367.20 requests per second
另外一个是 64 位 Xeon L5420 2.5 GHz 的结果：
$ ./redis-benchmark -q -n 100000 PING: 111731.84 requests per second SET: 108114.59 requests per second GET: 98717.67 requests per second INCR: 95241.91 requests per second LPUSH: 104712.05 requests per second LPOP: 93722.59 requests per second
高性能硬件下面的基准测试
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
使用 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
Das obige ist der detaillierte Inhalt vonSo überprüfen Sie die Redis-Benchmark-Parameter. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!