MySQL 5.7 + Transactd スループット117万QPSを記録
ようやく24コアのマシンでTransactdのベンチマークを取ることができました。
Xeon E5-2697 V2 2.7GHz 24コア48スレッドの物理マシンです。32または36コアでできれば良かったのですが、お借りできたこのマシン*1でベンチマークを行いました。
結果はタイトルの通りで、パフォーマンスの改善されたMySQL 5.7.7にて驚きの117万QPSを記録しました。
以下はその結果グラフです。横軸がクライアント数、縦軸が1秒間に処理したクエリー（読み取りレコード）数です。
memcached-pluginなどと基本的な考え方は同じですので、100万QPSを出すには48コア位は必要かと思っていましたが、24コアでこの値には少し驚いています。
MySQL 5.6.20でも87万QPSを出しました。5.7の結果が良いので5.6が少なく見えますが、24コアで87万QPSは好結果です。
48コアマシンだったら、MySQL 5.7とTransactd 2.4で200万QPSも可能ではないかと思います。
このテストのポイントについていくつか説明しておきます。
テスト環境
| Machine | Fujitsu RX300 S8 |
|---|---|
| CPU | Xeon E5-2697 V2 2.7GHz 24Core |
| Hyper-Threading | ON |
| memory | 24GB |
| OS | Windows Server 2012 R2 |
| Transactd Version | 2.4(Not yet release) |
| Network | Local pipe (shared memory) |
テスト方法
ベンチマークプログラム
ベンチマークプログラムは、シングルプロセスで2～48個のスレッドにてランダムなidのプライマリーキー値でサーバーにアクセスします。それぞれのスレッドは無限ループでアクセスを開始し、5秒間の計測シグナルがONの間にアクセスできた数を返すようになっています。
OSに制御を返す時間がほとんどない連続アクセスのため、論理コア数以下でスループットの劣化が始まります。
（ときどき、数百クライアントまでスケールする結果があったりしますが、それはサーバーの処理スレッドがOSに制御を返す空き時間が多い処理（通信）方法によるもので、空き時間がなければ論理コア以上にスケールすることはありません。）
ネットワーク
他のMySQL用のNoSQLプラグインでもベンチマークはローカルマシン内で行っています。これはネットワークレイテンシと負荷を軽減するためです。Transactdのパケットは数十バイト程度の小さなものが多く、1Gbpsのネットワークでも1Gbpsのスループットを出すことはできません。ネットワークのレイテンシによって、10～30万パケット程度で頭打ち*2になってしまいます。また、ネットワーク処理の負荷も問題になるため、今回のテストも他と同様にサーバーとクライアントは同一マシンで行っています。*3
OSはWindowsで行いました。TransactdのWindows版は共有メモリとイベント送受信を使ったプロセス間通信を行うことができます。これで通信のレイテンシと負荷を最小限にすることができます。
この方法はTCPのレイヤーを一切介さず、非常に高速に通信します。
TCPでの接続においても、ネットワーク処理を除いたデータアクセスに24コアが割り当てできれば、Linux/Windowsともにほぼ同様な結果がでると思います。それには、低負荷で高速なネットワークカードが必要です。逆に言えば今回の結果はそれを示していると言えます。
Transactdの高速性を真に発揮するには高速なネットワークカードも併せて利用していただけたらと思います。
MySQL 5.7
MySQL 5.7はスループットの改善が顕著でした。Transactdのコードは5.6と5.7のインタ-ーフェースの差異を吸収するだけの違いしかなく、基本的に同じものです。それにもかかわらず大きな性能差が出ています。特に、クライアント数が物理コア数を超えたあたりからの差が大きく、Hyper -Threadingによる論理コアをうまく使えているようです。InnoDBの改善が進んでいるのがわかります。
これだけの差があると、スループットをすぐにでも上げたい場合5.7はお勧めです。
5.7は既にRC版で、間もなくGA版になるかと思います。早期の導入には不安もありますが、TransactdはMySQLのhandlerインターフェース以下の層しか使わないので、潜在的なバグもSQLでのアクセスより少なくなります。また、TransactdのAPIは十分にテストされますのでチェックも2重に働いています。
まとめ
Transactd APIにて、性能劣化を起こすことなくInnoDBのパフォーマンスを引き出せていることが数字で確認できました。
今回のテストはidによる読み取りなのでkey-valueアクセスです。このようなkey-valueアクセス用途はもちろんですが、Transactdはフル機能のAPIを備えています。複雑な集計やトランザクションもすべて高速に行えます。
みなさんも、Transactdで最高パフォーマンスのWebアプリケーションを作ってみてください。今回のテストは開発中のVersion2.4で行いましたが、パフォーマンスに関しては2.3も同様です。
共有メモリを使用したWindowsローカルでの処理は非常に高速です。BizStationでは、大きなデータで時間のかかるデータのマイグレーションなどの際に、RAMディスクと併用して極端に短時間で処理するなどに利用しています。
また、MySQL 5.7の読み取りスループットの改善は本当に大きく、リリースされたらBizStationでも積極的に使っていこうと思います。
MySQL 5.7 + Transactdのこのスピードはちょっとわくわくします。
