 | ||||||||||||||
| ||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
| ||||||||||||||
| 設定ファイルの作成 | ||||||||||||||
次に「~/share/select-key.smack」を編集し、先ほどMySQLサーバ側で指定した内容と呼応するように設定を変更します。
表3：変更する項目 | ||||||||||||||
| super-smackコマンドの実行 | ||||||||||||||
それでは実際に負荷をかけてみましょう。super-smackコマンドを使用しますが、オプションは「設定ファイル」「スレッド数」「1スレッドごとのクエリ数」の順に指定します。  図3：負荷テストを実行 （画像をクリックすると別ウィンドウに拡大図を表示します） super-smackの処理が完了すると、MySQLサーバの性能に関する情報が表示されます。もっとも端的にMySQLサーバの性能をあらわすのは「q_per_s（Queries Per Second）」です。上記の場合「1秒当たり1419.10件のクエリを処理できる」となります。 | ||||||||||||||
| デフォルト状態での負荷テスト | ||||||||||||||
まずはデフォルト状態での負荷テストを行います。今回は、以下のようなテストを実施しました。
表4：テストの実施要綱 super-smackのコマンドとしては以下のように実行しました。 「super-smack ~/share/select-key.smack 10 100」で3回測定 「super-smack ~/share/select-key.smack 20 100」で3回測定 … 「super-smack ~/share/select-key.smack 400 100」で3回測定 測定の際には、他の要因を排除するため、MySQLサーバでは、MySQLの処理に関係無いサービスはすべて停止しました。また、測定中は収集スクリプトを多少改造して、10秒間のsleepを挟んで連続的に実行させ、show statusの情報を収集しました。 | ||||||||||||||
| テスト結果をグラフ化 | ||||||||||||||
以下の通り、測定結果をグラフ化しました。  図4：MySQLがデフォルト状態の測定結果 （画像をクリックすると別ウィンドウに拡大図を表示します） 各軸は以下の通りです。
表5：グラフの軸の項目 max_connectionsの推移を見ると、途中で100に達してしまい、同時接続数400まで測定できませんでした。 グラフに縦線を引きましたが、これはQueries_per_secが安定しているかどうか、の境界線をあらわしています。境界線手前では良好な応答速度で処理できており、境界線以降はばらつきが大きく、数値も低下しています。 そうしてみると、Queries_per_secは同時接続数が少ない間は1200程度を中心値として安定していますが、緑色の線を引いたあたりの測定以降、明らかに低下傾向にあります。また、Query_per_secが低下する直前のmax_connectionsは94でした。 | ||||||||||||||
| 次回は | ||||||||||||||
今回はデフォルト状態での負荷テストを実施しました。次回以降はこれを基本データとして、チューニングによってどのようにパフォーマンスが変化するか、を検証してゆきます。 | ||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
| ||||||||||||||
| ||||||||||||||
| ||||||||||||||
| ||||||||||||||
| ||||||||||||||
| ||||||||||||||
| ||||||||||||||
-
人気記事ランキング
-
-
連載
