RedisPubSubの性能評価

RedisPubSubの性能を評価するため、通信のオーバーヘッドを見積もり、データサイズに対する転送スピードの相関を評価した。そして、RedisPubSubの利用に役立てるための情報を提供する。

性能評価のための計算機構成

下記のように構成した。

PublisherMlf on
For nGEM, DELL PowerEdge R620    Intel Xeon E5-2650 0 2.00GHz
For PSD,  VT64 Server9500 X-1S            Intel Xeon X5690 3.47GHz 

Redis Server, Publisher and Subscriber on
DELL PowerEdge R710        Intel Xeon X5560 2.80GHz

Ethernet:Gigabitを利用した。

Redisサーバの設定パラメータ

デフォルトで決まっている値はここでは触れず、変更したパラメータのみ示す。/etc/redis.confの変更は下記の通り。

bind 0.0.0.0
#save 900 1
#save 300 10
#save 60 10000
client-output-buffer-limit pubsub 100gb 100gb 60

性能評価に使用したPublisher/Subscriberプログラムとその評価結果

使用したプログラムは大変シンプルなもので下記の通り。

Publisherは、単に指定された長さのデータを送るだけのプログラム(C++)
Subscriberは、単にデータを読み込んでスピードを計算させるだけのプログラム（C++)

比較のために、クライアント・サーバモデルでの簡単なTCPソケット通信プログラムも作成した。そのプログラムは、Publisher/Subscriber同様に単に指定された長さのデータを可能な限り速やかに送るだけのプログラム(C++)と単にデータを読み込んでスピードを計算させるだけのプログラム(C++)である。

下記は、その結果を数値で表したものである。

転送スピードの比較

結果から、転送バイト数が短い場合はRedisのオーバーヘッドのために転送レートは一定であり、約10kHz程度の性能となっている。しかし、転送バイト数が増加するに連れて徐々に転送スピードを上げ、ネットワーク最大性能に近づいている。

上記のテーブルのデータをグラフ化したものを下記に示す。縦軸が転送スピード(Mbits/sec)で、横軸は転送バイト数で、共にログスケールで表示されている。

転送スピードの比較図

見てわかるように、TCPソケット通信のオーバーヘッドはRedisPubSubのオーバーヘッドと比べて大変小さい。 Redisの場合、様々な機能を実現させているためオーバーヘッドが大きいものの、転送バイト数が大きくなるとネットワーク最大性能に近づいてるのが見て取れる。

以上の結果から、Redisは小さなデータ長の場合約10kHzの転送性能を持っているものの、できるだけ大きな長さでデータを転送することでネットワーク最大限のスピードに近づくことが示された。

DAQMWコンポーネント、PublisherMlfを利用したケーススタディー１

Redisサーバが受け取るデータ長の分布を表示するSubscriberを使って、DAQMWコンポーネント間を流れるデータ長を調べた。

BL21での結果は下記の図の通り。PSDとnGEMの場合について調べた。縦軸はイベントの数で、横軸はデータ長である。 PSD(読み出しモジュールはNeuNET)の場合、比較的小さなサイズのデータが多い。nGEMは一定長のデータであった。

NeuNETのデータ長

nGEMのデータ長

DAQMWコンポーネント、PublisherMlfを利用したケーススタディー2

単に読み込んでスピードを計算させるだけのSubscriber（BL21のPSDとnGEM読み込み）で実際にどれだけのスピードでデータが流れているかを知る。

nGEM（nGEM:１台）
speed = 13.241 Mbits/sec.（1.6MB/sec)
データ長：1.5kB ->データレート：1kHz@300kW
PSD(NeuNET:２２枚）
speed = 18.811 Mbits/sec.(2.3MB/sec)
データ長：~680B? ->データレート： 3.3kHz? @300kW

Redisサーバのバッファメモリ使用量

Redisサーバでは、Publisherから送られてくるデータがメモリに格納され、全てのSubscriberが読み終えるとメモリから消える。ケーススタディー２のような簡単なSubscriberであれば、Redisサーバ上のデータはすぐに処理されるためメモリ使用量は小さい。 Subscriberがsubscribeしてから読み続けるとき、仮に読み込みが遅れるとデータはRedisサーバ上に保持されるため増加する。一例が下記の図である。Subscriberの処理が間に合わずRedisサーバ上にデータが増え続けている様子をZabbixと呼ばれる監視ツールで監視した結果である。当然の事ながら、これを放置し続けると、計算機のメモリは使い尽くされ、データは失われることになる。

Redisサーバのバッファメモリ使用量

従って、Subscriberの性能に応じRedisサーバのメモリ使用量は大きく依存するので、Zabbix等のツールで監視し、Redisサーバの構成を決める。必要ならRedisサーバを増やして負荷分散させる。