11.14.1. 負荷試験実施の際の注意点¶

負荷試験の目的や性能の目標値（どのような環境でどのくらいの性能を出したいのか）をはじめに設定します。

本番環境と同等の検証環境で負荷試験を行う場合や、本番環境の何分の1かでの結果から本番環境での性能が類推比較できる環境であれば問題ありませんが、例えとして、ノートPCに環境を構築して負荷試験を行った場合、その負荷試験の結果を確認しても本番環境での性能値の参考にはなりません。

必ず負荷試験の目的や性能の目標値を明確にしてから、負荷試験環境やその実施内容を検討する必要があります。

どのような観点で何を調査したいのかを明確にする必要があります。観点の例としては以下があります。

また、一度の負荷検証で抽出した観点をすべて確認するということは、データを取得するだけでも時間を要します。

特にJMeterなどのオープンソース系の負荷試験ツールで負荷試験と、同時にサーバリソース状況を取得するのは困難です。

データ取得後のデータ解析には工数が掛かりますので、予め注意してください。

負荷試験のシナリオとしてよく見受けられるケースが、全リクエストを同時に実行させるようなシナリオを作成・実施するケースです。

このような負荷は、実際の運用ではまず発生しません。

上記シナリオで取得した数値をもとにサイジング等を実施したとしても、実際の運用ではオーバースペックのサーバ構成となったり、反対にレスポンスが出ないという問題が発生したりします。

シナリオを作成する場合は、多重アクセスの観点以外にも実際の運用に近い負荷を再現できるように、シンクタイム（思考時間遅延）等をシナリオに組み込んで作成・実施を行う検討が必要です。

Resin やintra-martのスレッド数等の各設定値を極端に大きく設定すれば良いという事はありません。

想定される利用者数等を考慮した上で値を設定することが重要です。

設定値は1回設定したら完了ということはなく、幾度も設定値を変更しながら負荷試験を実施し環境に応じた最適値を見つける必要があります。

G1GCを使用する、ConcurrentGCを使用する等、どの領域に何を置きたいのかを考えると、適切な値を見つけることは非常に難しい作業です。

特に、WebSphereならGCポリシーを変更するだけで大幅にメモリの使い方が変わります。

VisualVM等を利用して、プロファイリングやGCログでの精査が必要です。

「 intra-mart Accel Platform の設定ファイル 」-「 キャッシュ設定 」、および、 「 認可仕様書 」を基に適切な値を算出して設定してください。

メモリを考慮しない場合、キャッシュ容量ベースのLRUキャッシュより、数ベースのキャッシュのほうが効果的です。

Resin はFile/IO、Socket/IOの最適化の為に一部nativeな機能を利用しています。

Linux環境の場合、 「./configure –prefix=`pwd` && make && sudo make install」でのインストールを行ってください。

resin.properties にある「sendfile」や「tcp_cork」の設定は native 向けの設定です。

WEBサーバを構築して運用を行う場合、GZip圧縮の検討を行います。

なお負荷試験でGZip圧縮を行う場合、負荷をかけるクライアント側が送信するリクエストのヘッダに「Accept-Encoding:gzip, deflate」を入れてください。

Resin で静的ファイルの処理をさせることは可能ですが、処理を行わせると静的ファイル処理分のスレッドを消費し、本来必要となる処理が回せなくなる可能性もあります。

小規模サイトで無い限り、静的ファイルはWEBサーバに配置する事を推奨します。

WEBサーバは、Apache HTTP Server を推奨します。

データベース のチューニングは非常に重要です。必ず負荷試験を兼ねてチューニングを行う必要があります。

チューニングを実施しない場合（例. PostgreSQL を入れただけで shared_buffers がデフォルト設定のままである等）、月末等の処理集中時にパフォーマンス問題を引き起こす事例があります。

また、 Oracle Database Appliance(ODA) や SQL Server SSD Appliance などのアプライアンスサーバを導入する案もあります。

テナント環境セットアップ完了後であれば、適切な値を設定してください。

Resin のprepared-statement-cacheはLRUで管理していますので、ある程度大きく設定を行います。

GCのチューニング以外でも、CPUの使用時間、メソッドの呼び出し回数等について、VisualVM等を利用してのプロファイリングを行って確認を行います。

1回負荷試験を行っただけでは、レスポンスが期待する結果になる事は極めて低いと考えられます。

結果を基にレスポンス等を改善する方法を検討し、設定と負荷試験の再試行を繰り返し行う必要があります。

CPUの処理速度に依存したり、メモリやサイズだけではなくネットワークトラフィック等の影響も発生する事があります。

さらにディスクIOの影響などあらゆる要因があるため、さまざまな視点で検証・分析を実施することが重要です。