KAGOYAのVPSである、KAGOYA CLOUD VPSを契約しMySQLのベンチマークをしてみました。
VPSによっては、1ヶ月単にで課金が必要だったり、最低利用期間があったりするのですが、KAGOYA CLOUD VPSは1日単で利用料金が計算されるため、少しの期間だけ使うなどができるのがメリットです。
一方で、 KAGOYA CLOUD VPSの性能に関する情報は少なかったため、自分で実際のサービスを契約しベンチマークをしてみました。
前回はCPU、メモリ、I/Oなどに関するベンチマークをしましたが、今回はMySQLについても確認してみました。
ベンチマークの準備と詳細（OSなど）
今回のベンチマークではメモリが4GBのプランで実施しています。
OSはUbuntu22.04をインストールし、ベンチマークツールとしてはsysbenchを利用しています。
詳細については、以下のとおりです。
- OS：Ubuntu22.04.05
- MySQL：
mysql Ver 8.0.39-0ubuntu0.22.04.1 for Linux on x86_64 ((Ubuntu)) - Sysbench：sysbench 1.0.20
ベンチマークでは、一つのインスタンスのみ起動し、そのインスタンス内にMySQLやsysbenchをそれぞれインストールしています。
つまり、MySQLの接続先としてはlocalhostとなります。
また、MySQLはインストール後にチューニングなどはしておらず、ほぼデフォルト設定で実施しています。
なお、前回KAGOYAのVPSをベンチマークした時と同様、今回はvirtioをONにした状況でベンチマークを実施しています。
ベンチマークのやり方ですが、以前WebARENA (Indigo)のプランを契約して実施したベンチマークの時と同様、MariaDBの公式サイトで実施したベンチマークを参考に実施しました。
※概ね同じコマンドでベンチマークを実施していますが、僕はベンチマークを行う時間などは変えて実施しています。
ベンチマークでは、100万個のレコード（=データ）が存在するテーブルを10個準備します。
1個のレコードは4つのカラムが存在し、int型のカラムが2つ、char(120)が1つ、char(60)が1つで構成されます。
そして上記データベースに対して、概ね10回に9回は読み込み、1回は書き込みを行うように設定します（設定はしますが、結果をみるとなぜか9:1になっていない・・・けととりあえずベンチマークを続けます）。
1回のベンチマークは60秒の間実施し、平均TPS（Transaction Per Second。1秒間にどれぐらいの数のトランザクションを処理したか）、平均QPS（Query Per Second。1秒間にどれぐらいの数のクエリを処理したか。）、レイテンシを確認しました。
各プランでは、負荷(threadsというオプションで、同時にどれぐらいの要求をするか)を変えながらベンチマークを実施しました。
4GBプランのベンチマーク結果
まずは8 Threadsでベンチマークを実行してみました。
ベンチマークを実施した最初の時間帯では、TPSが約1,200〜1,400とWebArenaの時よりも少し高い値が出ていたのですが、なぜか途中でガクンと下がり、TPSが約40、QPSが約450ぐらいになる区間がありました。
そのため、ベンチマークを60秒間実施した結果としては、TPSが約882、QPSが約10,000と、ベンチマーク開始直後の値よりは低い結果となりました。
もしかしたらThreadsが多いのが原因なのかなと思い、Threadを4にしてもう一度ベンチマークを実施してみたのですが、やはりTPSやQPSの数値がバラついていることがわかります（下の図）。
結局Threadを4にした際は、平均TPSが約1,006、QPSが12,081となり、なぜかThreadsが8の時よりも高い結果となりました。
さらに、Threadsを2にしてベンチマークを実施してみたのですが、Threadが4の時よりもさらに数値が上がり、TPSが約1,407、QPSが16,891という結果になりました。
なお、TPSやQPSのばらつきはThread2でも発生しています（下の図）。
まとめ
KAGOYAのVPSである、KAGOYA CLOUD VPSでMySQLのベンチマークを実施した結果、WebARENA (Indigo)で実施した際の結果とは異なり、Threadsが少ないほど平均のTPSとQPSが高くなりました。
ばらつきがもっと少なければいいのですが、なぜこのようにばらつくのかは正直わかりません。
コメント