│ネットワークの明日を創る。前回までの設定でレプリケーションができるようになりました。それでは実際にレプリケーション別にベンチマークを実行して比較してみたいと思います。pg_benchの準備まずベンチマークツールを準備します。PostgreSQLのベンチマークで有名なpg_benchの準備を行います。install次にベンチマーク用のデータベースを作成し初期化します。今回はベンチマーク用に「bench_db」というデータベース作成し使用することにしました。bench_dbベンチマークの実施方法ベンチマークの実施には以下のコマンドを使用しました。bench_db同時接続数10で1接続あたり1000回の更新や参照のトランザクションを行うという内容です。実際にコマンドを実行すると以下のような結果が得られます。establishing)10行目、11行目のtpsとして表示されているのが、1秒間あたりに実行できたトランザクション数となります。数値が大きいほど多くのトランザクションを実行できたことになります。establishing」は接続時間を含まない結果となっています。establishing」の値をベンチマーク結果として使用することにしました。10からmax_connections初期値の100まで上げていき、各レプリケーション構成によってどの程度パフォーマンスの違いが出るのかを計測し結果を次の表にまとめましたのでご覧ください。bench_db各レプリケーション構成の通常時とマスターベンチマーク時に、上記コマンドをスレーブにて実行して5回の平均を取得してみました。通常時(マスターに負荷をかけていない状態)のスレーブの参照ベンチマーク結果synchronous_commitonremote_writelocaloff1回目7019.7113497111.7685557057.5614717903.0142102回目7044.5355548565.6039618463.5306468257.6383153回目7443.7993157816.6525977058.3585087174.0128564回目7475.2941538078.1969467374.7400408268.2894565回目8080.2857198723.5675908621.2842267314.432839平均7412.7252188059.1579307715.0949787783.477535マスターベンチマーク実行時のスレーブの参照ベンチマーク結果synchronous_commitonremote_writelocaloff1回目8274.9946218195.6464738521.9525507877.7375142回目7896.5239507063.6434277814.0872367732.3971983回目7670.1233368536.9393378309.9270397727.0198434回目8038.9729418493.5788548488.8202247447.9019265回目8202.9071107849.4167887588.4049177835.762420平均8016.7043928027.8449768144.6383937724.163780実際にはマスターのベンチマーク実行時に手動でスレーブにコマンドを流しているため、検証方法に一貫性がなくあくまで参考値でしかありません。この結果によってマスターの負荷の有無やレプリケーション構成の違いによって、スレーブの参照性能は大きく変化しないことが分かりました。いう結果になりました。今回の環境下での結果ですが、remote_writeはonの約1.2倍、localはonの約1.5倍、offに至っては桁違いという大きな違いが発生しましたので、レプリケーションを行う場合にはパフォーマンスを重視するのか、データの保全性を重視するのかをきちんと見極める必要がありそうです。スレーブの参照をうまく使えれば負荷分散となり速度向上が期待できるスレーブ側はマスター側の負荷に関わらずある一定の参照性能が発揮できることが分かりました。このためストリーミングレプリケーションでは、うまくスレーブ側に参照クエリを渡すことによって、マスター側の負荷を下げ、結果として速度を向上させることができるといえます。チューニングでパフォーマンスは向上する?」をお送りいたします。今回の検証はレプリケーション設定以外のパラメータは初期の状態ですので、次回ではこれをチューニングしてどの程度パフォーマンスが上がるのかを検証したいと思います。