RDSがt2インスタンスでどのくらい速くなったか試してみた

RDSがt2インスタンスでどのくらい速くなったか試してみた

Clock Icon2014.08.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日RDSでt2インスタンスタイプが選択可能になりました。 旧世代と現行世代でどの程度のパフォーマンス差があるのか気になったので、ベンチマークしてみました。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。 ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

使用データは以下のコマンドでロードしています。

java JR scripts\tpcc_load.js -nAgents 8 -param0 100
"-param0"に100を指定しているので、データ件数は以下になります。
Table Records
warehouse 100
district 1000
customer 3,000,000
history 3,000,000
item 10,000,000
stock 10,000,000
orders 3,000,000
new_orders 900,000
order_line 30,000,000 (approx.)

ベンチマーク対象

ベンチマーク対象は以下の3タイプです。全てCPU数が1のインスタンスです。参考としてdb.m3.mediumも計測しました。

インスタンスタイプ DB Engine Version vCPU メモリ (GiB) ネットワーク 時間あたりの料金 On Demand(Tokyo) 2014年8月21日時点
db.m1.small MySQL 5.6.13 1 1.7 $0.075
db.t2.small MySQL 5.6.13 1 2 低から中 $0.052
(参考)db.m3.medium MySQL 5.6.13 1 3.75 $0.120

MySQLの場合は、t2インスタンスがMySQL5.6以降で使用可能になります。MySQL5.5では使用できないのでご注意下さい。

Tiny TPC-Cを実行するインスタンスは、c3.xlargeのWindows Server 2012 R2を使用しています。なお、Tiny TPC-C実行インスタンスと各RDSは同じAZでベンチマークを取得しています。

結果

計測は、多重度を1、6、16、64に変化させスループット、最大CPU使用率を計測しました。 各々のスループットとレスポンスタイムは以下の様になりました。なお、レスポンスタイムは90パーセンタイルを表示しています。

db.m1.small

Throughput

多重度 Throughput(tps)
New-Order Payment Order-Status Delivery Stock-Level
1 2.9 2.9 0.3 0.3 0.3
4 7.9 7.9 0.8 0.8 0.8
16 10.9 10.9 1.1 1.1 1.1
64 12.3 12.3 1.2 1.2 1.2

Response Time

多重度 Response Time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level
1 247 ms 105 ms 81 ms 734 ms 1112 ms
4 378 ms 157 ms 144 ms 832 ms 1940 ms
16 1022 ms 546 ms 386 ms 2937 ms 4007 ms
64 4524 ms 1713 ms 1118 ms 9455 ms 9673 ms

 

db.t2.small

Throughput

多重度 Throughput
New-Order Payment Order-Status Delivery Stock-Level
1 4.1 4.1 0.4 0.4 0.4
4 11.7 11.7 1.2 1.2 1.2
16 17.3 17.3 1.7 1.7 1.7
64 15.8 15.8 1.6 1.6 1.6

Response Time

多重度 Response Time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level
1 185 ms 84 ms 56 ms 452 ms 827 ms
4 252 ms 118 ms 95 ms 425 ms 1324 ms
16 657 ms 363 ms 249 ms 1281 ms 2518 ms
64 3210 ms 1698 ms 930 ms 5384 ms 8844 ms

 

(参考)db.m3.medium

Throughput

多重度 Throughput
New-Order Payment Order-Status Delivery Stock-Level
1 16.0 16.0 1.6 1.6 1.6
4  26.8 26.8 2.7 2.7 2.7
16 45.8 45.8 4.6 4.6 4.6
64 50.5 50.5 5.0 5.0 5.0

Response Time

多重度 Response Time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level
1 59 ms 39 ms 2 ms 83 ms 2 ms
4 165 ms 104 ms 4 ms 251 ms 3 ms
16 318 ms 218 ms 27 ms 445 ms 30 ms
64 988 ms 1258 ms 92 ms 1328 ms 101 ms

まとめ

計測時のRDSのメトリクスは以下になります。メトリクスは計測中の最大値を表示しています。

インスタンスタイプ 多重度 Total Throughput (Tran/Sec) CPU使用率 DiskQueueDepth (Count) ReadIOPS (Count/Sec) WriteIOPS (Count/Sec)
db.m1.small 1 6.74 28.81 % 23.02 180.54 548.39
4 18.24 58.33 % 29.65 305.48 561.20
16 25.08 68.67 % 25.53 364.42 532.85
64 28.22 88.14 % 37.40 353.48 559.94
db.t2.small 1 12.97 8.33 % 29.81 202.63 651.33
4 26.96 19.33 % 28.75 368.18 778.32
16 39.86 26.27 % 25.92 476.67 742.92
64 36.25 24.83 % 45.05 414.86 493.34
(参考) db.m3.medium 1 36.9 40.33 % 3.76 1.1 440.40
4 61.54 72.67 % 7.59 1.1 682.76
16 105.33 96.33 % 10.83 1.1 793.45
64 116.07 99.33 % 9.20 1.1 687.69

メトリクスの結果を見ると以下のことが言えます。

  • db.t2.smallはdb.m1.smallに比べて、1.3〜1.9倍程度高速である。
  • db.t2.smallはdb.m1.smallに比べて、CPU使用率が3分の1程度である。
  • ReadIOPSが大量に有るので、メモリに収まらないデータ量で計測していると考えられる。

db.m3.mediumはReadIOPSがほとんど無いので、データがメモリに乗っていたと考えられます。

最後に

今回の計測では、db.t2.smallのCPUを使い切れませんでした。多数のDisk I/OによりI/O Waitが頻発したためと思われます。CPU使用率の差が大きいため、データサイズが小規模でデータがメモリに載る場合は、もっと性能差が発生したのではないかと思います。

db.m1.smallよりdb.t2.smallの方が低価格ですが、高性能であることが確認できました。MySQLで5.6を使用できる場合は、こちらを使用する方がよいでしょう。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.