基本的な流れ
流れはやっぱりおなじです。
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
読み方はMySQL、PostgreSQL、OracleのTPC-Cのときと同じです。
しつこいですが、数字は前回のMySQLやPostgreSQLと比較しないでください。ベースとなるマシンのスペックが全然違いますので、何の比較にもなりません。
こんな感じで、Redisに対するTPC-Cが実行できました。
なお、Redisに対するTPC-Cトランザクションがどのように実行されているのかは、Virtual User=1にして、別セッションでRedisにつないでmonitorすると掴めるかと思います。
どうやらhmget/hmset/lpush/zaddあたりでぐるぐる回してるようです。
パッと見た感じ、「MULTI」「EXEC」も見当たらないので、いわゆるRedisトランザクションは使っていなさそう。
まとめ
一応、HammerDBの公式サイトにあるTest matrix見るとRedis4.0.6となっているので、Redis Clusterにも対応したクライアントで実装していてほしかった。。。
唯一Redisだけが、クライアントの別途セットアップが不要になっているのに、そこが機能不足とは。。。
- 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/24
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
