ホームページ > 記事 > データベース > Redisベンチマークパラメータを確認する方法

Redisベンチマークパラメータを確認する方法

PHPz転載: 2023-06-04 12:12:121543ブラウズ

Redis には、M 個のリクエストを同時に発行する N 個のクライアントをシミュレートする redis-benchmark というツールが付属しています。 (Apacheab プログラムに似ています)。コマンド redis-benchmark -h を使用して、ベンチマークパラメーターを表示します。

以下参数被支持：

    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>

ベンチマークを行う前に、Redis インスタンスを起動する必要があります。通常、テストは次のように開始されます:

redis-benchmark -q -n 100000

このツールは非常に使いやすく、独自のベンチマークテストツールを使用することもできますが、ベンチマークテストを開始する際には、いくつかの詳細に注意する必要があります。。

一部のテストケースのサブセットのみを実行する

redis-benchmark を実行するたびに、デフォルトですべてのテストを実行する必要はありません。パラメーター「-t」を使用して、次の例のように、実行する必要があるテストケースを指定できます。

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

上記のテストでは、SET および LPUSH コマンドのみを実行し、 Quiet モード (-q パラメーターを使用)。

次の例のように、実行するコマンドを直接指定することもできます。

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

テストキーの範囲サイズを選択します

デフォルトでは、ベンチマークテスト単一のキーを使用します。インメモリデータベースでは、単一キーのテストと現実世界の間に大きな違いはありません。もちろん、キー範囲を広げると、実際のキャッシュミスをシミュレートできます。

現時点では、-r コマンドを使用できます。たとえば、毎回 100,000 のランダムキーを使用して 100 万回の SET 操作を継続的に実行する場合、次のコマンドを使用できます。

$ 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>Use Pipelining</h3><p>デフォルトでは、各クライアントは次のリクエストは 1 つのリクエストが完了した後にのみ送信されます (-c で特別な数が指定されない限り、ベンチマークは 50 個のクライアントをシミュレートします)。これは、サーバーが各クライアントのコマンドをほぼ順番に読み取ることを意味します。また、RTT も有料です。</p><p>実際の世界はさらに複雑になります。Redis は /topics/pipelining をサポートしており、複数のコマンドを一度に実行することができます。 Redis パイプラインを使用して、サーバーの 1 秒あたりのトランザクション レートを向上させます。 </p><p>次のケースは、パイプラインを使用して Macbook air 11 インチで 16 個のコマンドを整理するテスト例です: </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

複数のコマンドを処理する必要がある場合は、必ずパイプラインを使用してください。

罠と誤解

最初のポイントは明白です: ベンチマークテストの黄金律は同じ標準を使用することです。異なるバージョンの Redis をテストするときは、同じワークロードでテストしたり、同じパラメーターを使用したりできます。 Redis を他のツールでテストする場合は、機能の詳細の違いに注意する必要があります。

Redis はサーバーです。すべてのコマンドにはネットワークまたは IPC の消費が含まれます。つまり、 SQLite、Berkeley DB、東京/京都キャビネットなどは、ほとんどの消費がネットワークプロトコル上にあるため、比較するのは無意味です。
Redis の一般的なコマンドのほとんどには、確認の戻り値があります。たとえば、MongoDB の書き込み操作は確認を返しませんが、一部のデータストレージシステムは返します。Redis を他の一方向呼び出しコマンドストレージシステムと比較することは意味がありません。
シンプルなループRedis の操作実際には、Redis をベンチマークする代わりに、ネットワーク (または IPC) 遅延をテストします。Redis を実際にテストするには、複数の接続 (redis-benchmark など) を使用するか、パイプラインを使用して複数のコマンドを集約する必要があります。
Redis はインメモリデータベースであり、オプションの永続化機能を提供します。永続化サーバー (MySQL、PostgreSQL など) と比較する場合は、その場合は、AOF と適切な fsync 戦略を有効にすることを検討する必要があります。
Redis はシングルスレッドサービスであり、複数の CPU 向けに最適化されるように設計されていません。複数のコアのメリットを得るには、複数のインスタンスを有効にすることを検討してください。単一インスタンスの Redis とマルチスレッドデータベースを比較するのは不公平です。

よくある誤解は、redis-benchmark が意図的に行っているということです。ベンチマークの見た目は良くなりましたまあ、表示されたデータは人工的に見えますが、実際の製品のデータではありません。

Redis ベンチマークツールは、特定のハードウェア条件下でマシンのパフォーマンスパラメーターを迅速かつ簡単に計算できます。これは、Redis サーバーが達成できる最大スループットではありません。パイプラインとより高速なクライアント (hiredis など) を使用すると、より高いスループットを達成できます。デフォルトでは、redis-benchmark はスループットを向上させるために同時実行のみを使用します (複数の接続を作成します)。パイプラインやその他の同時実行技術は使用せず、マルチスレッドの代わりに複数の接続を使用するだけです。

ベンチマークテストにパイプラインモードを使用する場合 (より高いスループットを実現するため)、-P パラメーターを使用できます。実稼働環境で Redis を使用する多くのアプリケーションは、パフォーマンスを向上させるためにこのアプローチを採用しています。

最後に、ベンチマークテストでは、同じ操作とデータを比較する必要があり、これらが同じでなければ、ベンチマークテストの意味がありません。

たとえば、Redis と memcached はシングルスレッドモードで GET/SET 操作を比較できます。どちらもインメモリデータベースであり、プロトコルは基本的に同じで、複数のリクエストを 1 つのリクエストにマージする方法 (パイプライン処理) も似ています。この比較は、同じ数の接続を使用した後に意味があります。

以下は、Redis (antirez) と memcached (dormando) でテストされた素晴らしい例です。

antirez 1 - Redis、Memcached、速度、ベンチマーク、およびトイレについて

dormando - Redis VS Memcached (わずかに優れたベンチ)

antirez 2 - Memcached/Redis ベンチマークの最新情報

同じ条件下での最終結果に大きな違いがないことがわかります。最終テストの時点では、両方とも完全に最適化されていたことに注意してください。

最後に、特に高性能のサーバー (Redis、memcached など) をベンチマークする場合、サーバーのパフォーマンスを最大限に活用することは難しく、通常はサーバーではなくクライアントがボトルネックになります。この場合、最大のスループットを達成するには、クライアント (ベンチマークプログラム自体など) を最適化するか、複数のインスタンスを使用する必要があります。

Redis のパフォーマンスに影響する要因

Redis のパフォーマンスを直接決定する要因がいくつかあります。これらはベンチマークの結果を変える可能性があるため、注意を払う必要があります。通常、Redis のデフォルトのパラメーターは効率的なパフォーマンスを提供するのに十分であるため、チューニングは必要ありません。

ネットワーク帯域幅と遅延は通常、最大の欠点です。ベンチマークを行う前に、ping コマンドを使用してサーバーとクライアント間の遅延を検出することをお勧めします。帯域幅に基づいて、最大スループットを計算できます。たとえば、4 KB 文字列が Redis に挿入され、スループットが 100,000 q/s の場合、実際には 3.2 Gbits/s の帯域幅が必要となるため、10 GBits/s のネットワーク接続が必要です。1 Gbits/s では十分ではありません。。多くのオンラインサービスでは、CPU よりも早くネットワーク帯域幅が Redis スループットの制限要因になることがよくあります。高スループットを実現し、TCP/IP の制限を突破するために、最終的には 10 Gbit/s ネットワークカード、または複数の 1 Gbit/s ネットワークカードが使用されます。
CPU はもう 1 つの重要な影響要因であり、Redis はシングルスレッドモデルであるため、複数のコアよりも大規模なキャッシュと高速な CPU を好みます。このシナリオでは、Intel CPU の方が推奨されます。 AMD CPU はおそらく Intel CPU の半分しか強力ではありません (Nehalem EP/Westmere EP/Sandy プラットフォームと比較して)。他の条件が等しい場合、CPU が redis-benchmark のボトルネックになります。
小さなオブジェクトにアクセスする場合、メモリ速度と帯域幅はそれほど重要ではないようですが、大きなオブジェクト (> 10 KB) の場合は重要になります。一般に、Redis を最適化するために、より高性能のメモリモジュールを購入する人はいません。
Redis は VM 上で遅くなる可能性があります。仮想化では通常の操作で追加の消費量が発生しますが、Redis ではシステムコールやネットワーク端末に大きなオーバーヘッドがありません。遅延が特に懸念される場合は、Redis をデプロイして物理サーバー上で実行することをお勧めします。最先端の仮想化デバイス (VMware) では、redis-benchmark のテスト結果は物理マシンのテスト結果の 2 倍遅くなり、システムコールと割り込みで多くの CPU 時間が消費されます。
サーバーとクライアントの両方が同じマシン上で実行されている場合は、TCP/IP ループバックと UNIX ドメインソケットの両方を使用できます。 Linux の場合、UNIX ソケットを使用すると、TCP/IP ループバックより 50% 高速になる可能性があります。 redis-benchmark は、デフォルトで TCP/IP ループバックインターフェイスを使用します。
Unix ドメインソケットの利点は、大規模なパイプラインが使用されるとあまり重要ではなくなります。
ネットワーク接続を使用しており、イーサネットデータパケットが 1500 バイト未満である場合、複数のコマンドをパイプラインにパッケージ化すると効率が大幅に向上します。実際、10バイト、100バイト、1000バイトのリクエストを処理した場合のスループットはほぼ同じです（詳細は下図を参照）。

Redisベンチマークパラメータを確認する方法

マルチコア CPU サーバー上の Redis のパフォーマンスは、NUMA 構成とプロセッサバインド位置にも依存します。 Redis ベンチマークの最も大きな影響は、CPU コアがランダムに使用されることです。正確な結果を得るには、固定プロセッサツールを使用する必要があります (Linux では、taskset または numactl を使用できます)。最も効果的な方法は、クライアントとサーバーを 2 つの異なる CPU に分離して、3 次キャッシュを使用することです。以下は、3 つの CPU (AMD Istanbul、Intel Nehalem EX、および Intel Westmere) の異なる構成を使用した 4 KB データセットを使用したベンチマークです。これは CPU 固有のテストではないことに注意してください。

Redisベンチマークパラメータを確認する方法

#高度な構成では、クライアント接続の数も重要な要素です。 Redis のイベントループは epoll/kqueue の恩恵を受けているため、拡張性が高くなります。 Redis は 60,000 を超える接続でベンチマークされており、依然として 50,000 q/s を維持できます。経験則として、30,000 接続のスループットは 100 接続の半分しかありません。以下は接続数とスループットに関するテストです。

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

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

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

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

以上がRedisベンチマークパラメータを確認する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

mysql 字符串循环接口线程多线程 Thread 并发对象事件 sqlite redis mongodb memcached postgresql 数据库 linux unix 虚拟化负载均衡

声明：

この記事はyisu.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。

前の記事：Redis のイベント駆動モデルとは何ですか?次の記事：Redis のイベント駆動モデルとは何ですか?

続きを見る

Redisベンチマークパラメータを確認する方法

一部のテスト ケースのサブセットのみを実行する

テスト キーの範囲サイズを選択します

罠と誤解

Redis のパフォーマンスに影響する要因

其他需要注意的点

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

更多使用 pipeline 的测试

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

関連記事

一部のテストケースのサブセットのみを実行する

テストキーの範囲サイズを選択します