初負荷テストで、得られた知見


仕事で、人生初のWEBアプリケーションのスループット云々系の負荷テストを実施しました。
負荷テスト実施で得られた知見?を何の役に立つのかはわかりませんが、晒します。
何か思い出したら、追記をしていこうかと思います。

まず、状況、背景的なところから、


負荷テスト対象のアプリケーション構成

  • HTTPサーバー
    Apache

  • JAVA APサーバー
    Glassfish

  • DBサーバー
    AWS RDS


評価対象のモジュール

  • 共通処理(どの画面からも必ずcallされる)

負荷テスト対象サービスの状況

  • 既にリリース済。それなりに安定稼働している。

  • 過去負荷テストの実施記録はない。(やってたのかもしれないが記録が残っていない。

  • やろうと試みた実施手順書類などはある。


自分の立場

  • ざっくり計画と評価をし、且つ、サーバー側のメトリクスを取る人

負荷テストで確認したかったこと

  • リリース対象のモジュール(機能)がパフォーマンス面で、安定稼働に悪影響しないこと。
    軽い処理だが、至る所からcallされるため、CPUが高負荷にならないこと

知見

1. 当たり前だが、事前に計画はすべき

想定負荷はどれくらいか?
はメトリクスが事前に収集可能であれば取得すべきだと思いました。
闇雲に負荷をかけてもパフォーマンスが出なかったり、
負荷が低すぎてあらいい感じでさばけていると思ったら本番サーバーで全然ダメ
っていうのはあるかと思います。

2. 適当に負荷をかけても得られる情報はある

  1. の裏返しだが、適当な負荷テストでも得られるものはあると思いました。
    とりあえずやってみて、メトリクスを収集してでもわかることはありました。
    時間はかかりますが。。

3. Javaのメモリー使用量は、linux の top コマンドではわからない。

VMオプションによるかもしれませんが、top コマンドのmemoryサマリーでは、
memory使用量の変化はありませんでした。
-Xms-Xmx が同じ値だったからだと思います。
jstatコマンド 等で、
Javaのメトリクスは別途取得する必要があるとわかりました。

4. Jmeterのresponse time 計測で、ざっくり良い悪いはすぐわかる。

平均負荷と、最大負荷をモデリングした後で、response time 計測で、
悪いとなった時の原因は個別で実施していかないといけないですが、
内部ロジックがブラックボックスの状況での評価[良い/悪い]はresponse time で、感覚的に把握できます。

5. スループットが要求される処理では、ホワイトボックスなチューニングも必要

計測で下手にスループットが出てしまい、問題が潜在化するケース。
ものすごいアクセス数が多い処理だと、無駄にサーバーリソースを消費することになるため、
ホワイトボックスでのレビュー、チューニングは別途必要です。
いやこれは重要です。

以上です。

コメント