11.14.1. 負荷試験実施の際の注意点¶
- intra-mart Accel Platform で行う負荷試験についての観点、注意点が以下の通りです。
項目
11.14.1.1. 負荷試験の目的・性能の目標値の設定¶
負荷試験の目的や性能の目標値(どのような環境でどのくらいの性能を出したいのか)をはじめに設定します。本番環境と同等の検証環境で負荷試験を行う場合や、本番環境の何分の1かでの結果から本番環境での性能が類推比較できる環境であれば問題ありませんが、例えとして、ノートPCに環境を構築して負荷試験を行った場合、その負荷試験の結果を確認しても本番環境での性能値の参考にはなりません。必ず負荷試験の目的や性能の目標値を明確にしてから、負荷試験環境やその実施内容を検討する必要があります。
11.14.1.2. 負荷試験を実施する観点¶
どのような観点で何を調査したいのかを明確にする必要があります。観点の例としては以下があります。
- サーバサイドでのレスポンス
- クライアントサイドでのレスポンス
- サーバサイドでのメモリ消費状況
- 自作アプリケーションのパフォーマンス
- データベースにかかる負荷状況
また、一度の負荷検証で抽出した観点をすべて確認するということは、データを取得するだけでも時間を要します。特にJMeterなどのオープンソース系の負荷試験ツールで負荷試験と、同時にサーバリソース状況を取得するのは困難です。データ取得後のデータ解析には工数が掛かりますので、予め注意してください。
11.14.1.3. 多重アクセスのシナリオ¶
負荷試験のシナリオとしてよく見受けられるケースが、全リクエストを同時に実行させるようなシナリオを作成・実施するケースです。このような負荷は、実際の運用ではまず発生しません。上記シナリオで取得した数値をもとにサイジング等を実施したとしても、実際の運用ではオーバースペックのサーバ構成となったり、反対にレスポンスが出ないという問題が発生したりします。シナリオを作成する場合は、多重アクセスの観点以外にも実際の運用に近い負荷を再現できるように、シンクタイム(思考時間遅延)等をシナリオに組み込んで作成・実施を行う検討が必要です。
11.14.1.4. スレッド数等の各設定値¶
Resin やintra-martのスレッド数等の各設定値を極端に大きく設定すれば良いという事はありません。想定される利用者数等を考慮した上で値を設定することが重要です。設定値は1回設定したら完了ということはなく、幾度も設定値を変更しながら負荷試験を実施し環境に応じた最適値を見つける必要があります。
11.14.1.5. GCのチューニング¶
G1GCを使用する、ConcurrentGCを使用する等、どの領域に何を置きたいのかを考えると、適切な値を見つけることは非常に難しい作業です。特に、WebSphereならGCポリシーを変更するだけで大幅にメモリの使い方が変わります。VisualVM等を利用して、プロファイリングやGCログでの精査が必要です。
11.14.1.6. キャッシュの設定¶
メモリを考慮しない場合、キャッシュ容量ベースのLRUキャッシュより、数ベースのキャッシュのほうが効果的です。
11.14.1.7. Resin のnative機能のコンパイル¶
Resin はFile/IO、Socket/IOの最適化の為に一部nativeな機能を利用しています。Linux環境の場合、 「./configure –prefix=`pwd` && make && sudo make install」でのインストールを行ってください。resin.properties にある「sendfile」や「tcp_cork」の設定は native 向けの設定です。
11.14.1.8. GZip圧縮の検討¶
WEBサーバを構築して運用を行う場合、GZip圧縮の検討を行います。なお負荷試験でGZip圧縮を行う場合、負荷をかけるクライアント側が送信するリクエストのヘッダに「Accept-Encoding:gzip, deflate」を入れてください。
11.14.1.9. 静的ファイルはAPサーバではなくWEBサーバに配置¶
Resin で静的ファイルの処理をさせることは可能ですが、処理を行わせると静的ファイル処理分のスレッドを消費し、本来必要となる処理が回せなくなる可能性もあります。小規模サイトで無い限り、静的ファイルはWEBサーバに配置する事を推奨します。WEBサーバは、Apache HTTP Server を推奨します。
11.14.1.10. データベース 側のチューニング¶
データベース のチューニングは非常に重要です。必ず負荷試験を兼ねてチューニングを行う必要があります。チューニングを実施しない場合(例. PostgreSQL を入れただけで shared_buffers がデフォルト設定のままである等)、月末等の処理集中時にパフォーマンス問題を引き起こす事例があります。また、 Oracle Database Appliance(ODA) や SQL Server SSD Appliance などのアプライアンスサーバを導入する案もあります。
11.14.1.11. PreparedStatementCache¶
テナント環境セットアップ完了後であれば、適切な値を設定してください。Resin のprepared-statement-cacheはLRUで管理していますので、ある程度大きく設定を行います。
11.14.1.12. VisualVM等を利用してのプロファイリング¶
GCのチューニング以外でも、CPUの使用時間、メソッドの呼び出し回数等について、VisualVM等を利用してのプロファイリングを行って確認を行います。
11.14.1.13. 負荷試験の繰り返し実施¶
1回負荷試験を行っただけでは、レスポンスが期待する結果になる事は極めて低いと考えられます。結果を基にレスポンス等を改善する方法を検討し、設定と負荷試験の再試行を繰り返し行う必要があります。CPUの処理速度に依存したり、メモリやサイズだけではなくネットワークトラフィック等の影響も発生する事があります。さらにディスクIOの影響などあらゆる要因があるため、さまざまな視点で検証・分析を実施することが重要です。
コラム
以上に関しては、弊社のコンサルティングサービスをご利用頂く事も可能です。詳細は担当営業までお問い合わせください。