なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

HammerDBをCLIで使うなど(5):RedisにTPC-Cを実行してみる

基本的な流れ

流れはやっぱりおなじです。

Redisで業務的な意味でのトランザクションを扱うイメージあんまりないですが、ツールとして対応しているので、ためしておきたいなと。
単純性能みるだけなら、redisのパッケージにベンチマークツール「redis-benchmark」が付属していて、いろいろなデータ型、いろいろなサイズでベンチマーク取れるので、それ使えばいいんですけどね。


なお、RedisClusterには対応していないようです。少なくともhammerdbのオプションにClusterModeであることを渡すものがなかったです。
redis-cliならは「-c/--cluster」オプションつければリダイレクトしてくれますが、あくまでredis-cli(redis-cli.c)の中でMOVEDエラー(コマンドを投げたシャードにそのデータは居ない)をハンドリングしてリダイレクトする実装となっています。


このHammerDBのRedisクライアントはredis.tclで動いていて、tclを頑張って読んでみてもcluster-modeおよびredirect実装に相当する部分が見当たらなかったです。redis.tclの作者もredisの公式サイトで「Not really full featured nor designed to be used in the real world.」って言ってますし。


だれかこのへんチョイっといじってCluster対応してくれたら神ですね。


遠回りになりましたが、ベンチマークする対象はCluster Modeではないものを用意しましょう。

対象DBMSベンチマークの選択

hammerdb>dbset db redis
Database set to Redis

hammerdb>dbset bm TPC-C
Benchmark set to TPC-C for Redis

詳細パラメータの表示と設定

hammerdb>print dict
Dictionary Settings for Redis
connection {
 redis_host      = 127.0.0.1
 redis_port      = 6379
 redis_namespace = 1
}
tpcc       {
 redis_count_ware       = 1
 redis_num_vu           = 1
 redis_total_iterations = 1000000
 redis_raiseerror       = false
 redis_keyandthink      = false
 redis_driver           = test
 redis_rampup           = 2
 redis_duration         = 5
 redis_allwarehouse     = false
 redis_timeprofile      = false
}

パラメータ、少ないですね。
Connection側のパラメータ「redis_namespace」は、いわゆるredisのdb番号(通常、0~15)です。特に変える必要はないですね。

冒頭で触れたとおり、Redis Clusterにredis-cliから接続する際にリダイレクト対応させる「-c/--cluster」オプションに相当するパラメータがありません。
この先でbuildschemaを実行したら「MOVED」でコケました。。。




気を取り直して。

tpccパラメータの意味は以下のとおりです。

名称 説明 初期値
redis_count_ware シナリオに登場する「倉庫(warehouse)の数=データのサイズ(≒スケールファクタ)。 1
redis_num_vu 同時実行ユーザー数 1
redis_total_iterations トランザクションの実行回数。 1000000
redis_raiseerror エラーが起きても続ける(false)か、exitする(true)かのスイッチ。 false
redis_keyandthink 公式TPC-C要件により近づけるための「思考判断時間」のシミュレートを行うスイッチ。 false
redis_driver 環境整整備、動作検証までは「test」を、実計測時は「timed」を指定する。 test
redis_rampup いわゆるテスト開始~計測開始までの暖気処理時間。 2
redis_duration 複数ユーザーが時差を持ってアクセスするための遅延処理。 5
redis_allwarehouse シナリオに登場する倉庫(warehouse)に対し、ユーザーが利用する倉庫はデフォルトでは固定されるが、trueにするとランダムに倉庫を選択するようになる。 false
redis_timeprofile 応答時間プロファイル(etprof)の生成スイッチ。trueにすると、10秒間隔での応答時間パーセンタイル、完了時の累積値がレポートされる。 false


Redisにはユーザーという概念がないので、そのへんの認証にまつわるパラメータがありません。
その他Redisのシンプルなアーキテクチャがそのままパラメータの少なさに映し出されてる感じです。



今回も、driverとtimeprofileを変更して実行します。

hammerdb>diset tpcc redis_driver timed
Clearing Script, reload script to activate new setting
Script cleared
Changed tpcc:redis_driver from test to timed for Redis

hammerdb>diset tpcc redis_timeprofile true
Changed tpcc:redis_timeprofile from false to true for Redis

スキーマ作成

テストで流す前に必要なスキーマ作成、及び、テストデータの投入を実行します。


MySQLと同様、num_vuで指定した数だけクライアントが立ち上がり、並列実行でテストデータを投入します。

hammerdb>buildschema
....
ALL VIRTUAL USERS COMPLETE

処理が完了しても、データ生成のために立ち上がったクライアントプロセスは起動したままになります。
次の処理の前に、スキーマ作成用のユーザーセッションが完了しているか確認するコマンドを投げて確認し、完了ステータスになっていたら、そのセッションは一度破棄しておきます。

hammerdb>vustatus
1 = FINISH SUCCESS

hammerdb>vudestroy
Destroying Virtual Users
Virtual Users Destroyed
vudestroy success

hammerdb>vustatus
No Virtual Users found

テストスクリプトのロード

ここから先はMySQLと同じですので、さらっと流します。

hammerdb>loadscript
Script loaded, Type "print script" to view

テスト実行用クライアント(Virtual User)の設定

ワークロードを実行するために接続する同時実行ユーザー数を確認・調整します。

hammerdb>print vuconf
Virtual Users = 1
User Delay(ms) = 500
Repeat Delay(ms) = 500
Iterations = 1
Show Output = 1
Log Output = 0
Unique Log Name = 0
No Log Buffer = 0
Log Timestamps = 0

hammerdb>vuset
Usage: vuset [vu|delay|repeat|iterations|showoutput|logtotemp|unique|nobuff|timestamps] value

hammerdb>vuset vu 4

hammerdb>vuset logtotemp 1

hammerdb>vuset unique 1

hammerdb>vuset timestamps 1

hammerdb>print vuconf
Virtual Users = 4
User Delay(ms) = 500
Repeat Delay(ms) = 500
Iterations = 1
Show Output = 1
Log Output = 1
Unique Log Name = 1
No Log Buffer = 0
Log Timestamps = 1

テスト実行用クライアント(Virtual user)の起動

設定に従ってクライアント(Virtual user)を起動します

hammerdb>vucreate
Vuser 1 created MONITOR - WAIT IDLE
Vuser 2 created - WAIT IDLE
Vuser 3 created - WAIT IDLE
Vuser 4 created - WAIT IDLE
Vuser 5 created - WAIT IDLE
Logging activated
to /tmp/hammerdb_5D65D5AF591203E203037363.log
5 Virtual Users Created with Monitor VU

hammerdb>vustatus
1 = WAIT IDLE
2 = WAIT IDLE
3 = WAIT IDLE
4 = WAIT IDLE
5 = WAIT IDLE

テストの実行

hammerdb>vurun

で実行し、終わるまで待ちます。

実行結果の出力例

大量に出力されますが、スコアを見るのはこの1行ですね。

Vuser 1:TEST RESULT : System achieved 1740740 Redis TPM at 14821 NOPM

読み方はMySQLPostgreSQLOracleTPC-Cのときと同じです。
しつこいですが、数字は前回のMySQLPostgreSQLと比較しないでください。ベースとなるマシンのスペックが全然違いますので、何の比較にもなりません。


こんな感じで、Redisに対するTPC-Cが実行できました。


なお、Redisに対するTPC-Cトランザクションがどのように実行されているのかは、Virtual User=1にして、別セッションでRedisにつないでmonitorすると掴めるかと思います。
どうやらhmget/hmset/lpush/zaddあたりでぐるぐる回してるようです。
パッと見た感じ、「MULTI」「EXEC」も見当たらないので、いわゆるRedisトランザクションは使っていなさそう。


まとめ

  • Redis用のTPC-Cはパラメータが圧倒的に少ない。
  • Redisトランザクションは使用していなさそう。
  • Redis Cluster(リダイレクト)に対応していない。

一応、HammerDBの公式サイトにあるTest matrix見るとRedis4.0.6となっているので、Redis Clusterにも対応したクライアントで実装していてほしかった。。。
唯一Redisだけが、クライアントの別途セットアップが不要になっているのに、そこが機能不足とは。。。


WEB+DB PRESS Vol.112

WEB+DB PRESS Vol.112

  • 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/08/24
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る
って、さすがにRDBMS比較特集なのでRedisの話は載ってないや。