プロが教える負荷テストの方法とは？ボトルネックの見つけ方を詳しく紹介！

Hedgehogでは様々なWebシステムの負荷テストを行っておりますが、お客様の目標としている数値に到達できないことがよくあり、その際ボトルネックの調査をお手伝いすることがあります。

この記事では、負荷テストを実施した際にWebシステムのボトルネックを調査して得られた知見や、よくある質問・問題についてご紹介したいと思います。


目次

• リソース状況の確認
• レスポンスタイムを記録・確認
• アプリケーションサーバのログを確認

リソース状況の確認

狙った性能が出ない場合はまずリソースの利用状況を確認しましょう。
特にウェブサーバ・アプリケーションサーバは、メモリ・CPUにボトルネックがあることが多いです。
リソース監視ツール（Nagios、Munin、CloudWatch、New Relic、Mackerel、etc）で代用する方もいますが、これらは情報の取得間隔が長い（1～5分間隔が多い）ため、リアルタイムでの状況把握には適していません。
秒間隔でリソース状況を取得できるコマンドベースのものを選びましょう。
ほとんどのサーバにはデフォルトでインストールされていることを考えるとtopコマンドが使いやすいと思います。

＊利用方法は検索すると見つかるのでそちらを参照してください。


topコマンドを起動したら試験を開始しましょう。
試験中はCPU・メモリを使い切っていないかを目視で確認しておきます。
目標値に到達しなかった場合に、CPUまたはメモリを使い切っていれば、原因の調査・対策（アプリケーション改修・設定変更・スペックアップ等）を実施します。
使い切っていなければCPU・メモリ以外がボトルネックになっていると考えられます。別の原因を調査しましょう。

レスポンスタイムを記録・確認

特定のエンドポイントのみレスポンスに時間がかかり、全体の性能が引きずられる場合があります。
これを検知するにはウェブサーバ（Nginx, Apache等）のアクセスログにレスポンスタイムを追加するのが有効です。

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" $request_time';

    access_log  /var/log/nginx/access.log  main;

※nginxでレスポンスタイムをログに追加する例。$request_timeがレスポンスを返すまでにかかった時間。


試験中に吐かれたログのレスポンスタイムに特に遅いものがないかを確認します。
もし遅いものが見つかればそのアクセスで実行される処理に絞って調査を進めましょう。
根本の原因は、SQLが遅いケース、同時実行でデータベースのロックが発生しているケース、Web APIなどの外部との通信が遅いケースがよく見られます。

アプリケーションサーバのログを確認

アプリケーションサーバの待機プロセス・スレッドをすべて使い切ってしまい、レスポンスが途中から遅くなることがあります。
これは大抵のサーバではログに出力してくれるので、ログを確認しましょう。
CPU・メモリに余裕がなければスケールアップ・スケールアウトを実施すれば良いですが、リソースに余裕があるのにその選択をしてしまうケースもあります。
余裕がある場合はより多くのプロセス・スレッドを起動させるように設定変更し、効率的にサーバを使いましょう。また、設定変更後はリソース状況も改めて確認しましょう。