この記事は、intra-mart Advent Calendar 2013 第24日の記事です。
クリスマス・イブですね。なんか微妙に浮かれ気分になってしまう感じな日ですが、Advent Calendar 2013の最後の2日分は、皆様の関心が高い、負荷試験について紹介させていただきます。
で、本日は、負荷試験についての観点、注意点をご紹介させていただきたいと思います。ちょっとキツメに書いていますが、実際に日々私達が直面して感じている内容で、非常に重要なことなので、今後、年度末にかけてリリースするシステムなどで、負荷試験をご検討の方はぜひご一読頂きたいと思います。
1. 負荷試験の目的、目標は明確に
負荷試験はどういう目的で何を目標にするのか明確にしないと徒労に終わることが多いです。本番環境と同等の検証サーバで負荷試験を行うという場合や本番環境の何分の1で、結果から本番環境での性能が類推比較できる環境であれば問題ありませんが、その辺に転がっているような適当なノートPCに環境作って限界を見たい、みたいな事言われてもそんなものの負荷試験結果には何の意味も無いんじゃないか? っていうのが実際にありました。
あと目的だけじゃなくて、ある程度の目標も事前に設定しておく必要があります。
2. 観点
上記の点と同じですが、どの観点で何を見たいの? ってのを明確にしてから実施してください。サーバレスポンスをみたいのか?クライアントサイドでのレスポンスをみたいのか?
それだけではなく、裏側でどれ位メモリを消費してるのか?とか、作りこんだアプリケーションのパフォーマンスがみたいとか、その先のDBにかかる負荷が見たいとか色々あると思います。また一度で全部見るというのはかなりデータ取得だけで厳しい作業になります。特にJMeterなどのオープンソース系の負荷試験ツールで負荷試験と同時にサーバリソース状況を取得するのは大変で、かつデータ取得後のデータ解析にかなりの工数が掛かりますので、覚悟してください。弊社では、その工数を削減するために、Oracle Application Testing Suiteを利用しています。
3. 多重アクセスのシナリオ
とりあえず負荷試験をやればいいと思っている方が多く、よくあるのが、JMeterでシナリオ取得して、同時いくつかで、全リクエストをせーのでドン! みたいな多重の負荷を掛ける方がよく見られます。
そんな負荷は、実際の運用では、まず掛かりません。で、この数値でサイジングなどを実施して、実際の運用ではかなりオーバースペックなサーバ構成になったり、そもそもレスポンスが出てないと問題になっていることが多く見受けられます。
実際の運用に近い負荷を再現できるようにシンクタイム(思考時間遅延)をシナリオに組み込んで下さい。
4. スレッド数などの各設定値
Resinやintra-martのスレッド数などの各設定値など増やせば良いってものはありません。想定される利用者数とかからきちんと考えて値を設定する必要が重要です。また、設定値は、一発で設定できることはなく、何度も負荷試験を実施して最適値を見つけていくことが普通なのですが、
負荷試験かけるからチューニングしてくれ。
↓
前提条件聞いてとりあえず設定する。
↓
これで試したいですけど・・・。
↓
就業時間中は動かせんから、就業時間後に1発で負荷試験本番でよろしく。
というのは意味がありません。
5. GCのチューニング
これ地味に大事です。
G1GC使うとか、ConcurrentGC使うとか、どの領域に何を置きたいのか考えると適切な値見つけるのは非常に難しい作業です。
特に、WebSphereならGCポリシを変えるだけで大幅にメモリの使い方が変わります。VirualVM等を利用してプロファイリングや地道にGCログでの精査が必要です。
6. キャッシュの設定
マニュアルを元に適切な値算出して設定してください、メモリ多かったら多めに突っ込むと幸せになります。
メモリを気にしなくて良いならキャッシュ容量ベースのLRUキャッシュより、数ベースのキャッシュのほうが早いです。
7. Resinのnative機能のコンパイル
Resinは、圧縮ファイルを展開するとそのまま動作するように見えます(実際動作します)が、ResinはFile/IO, Socket/IOの最適化の為に一部nativeな機能を利用しています。
そのために、マニュアルに記載のとおり、*nix系なら ./configure --prefix=pwd && make && sudo make install でのインストールをしてください。
resin.propertiesにあるsendfileとかtcp_corkな設定はnative向けの設定です。多少パフォーマンス変わります。
8. GZip圧縮の検討
Webサーバ立ててるならGZip圧縮の検討を。
あと、負荷試験で、GZip圧縮の恩恵を受けたいなら負荷かけるクライアント側が送信するリクエストのヘッダにAccept-Encoding:gzip, deflate 入れとかないと意味ないので注意してください。
9. 静的ファイルはAPサーバで捌かない
Resinで静的ファイルの処理をさせることは可能ですが、静的ファイル処理分のスレッドを消費し、肝心の処理に回せなくなる可能性もありますので、よっぽどの小規模サイトで無い限り、静的ファイルは、Webサーバに置いください。
また、Webサーバは、Windowsサーバ(64bitOSでも)でもIISでなく、Apacheを強く推奨します。
10. DB側のチューニング
最近は、OracleやSQLServer自体でかなりチューニングされるようになりましたが、それでも、当たり前なのですが、DB自体のチューニングは非常に重要です。
特に最近多い、PostgreSQLで、PostgreSQLを入れただけでshared_buffersがそのままとかは絶対にやめてください。
OracleやSQLServerのチューニングがわからない、そんな技術者も工数がないというのであれば、Oracle Database Appliance(ODA)やSQL Server SSD Applianceなどのアプライアンスサーバを手配することを強く推奨します。
11. PreparedStatementCache
テナント環境セットアップ完了後であれば、適切な値を設定してください。
Resinのprepared-statement-cacheはLRUで管理されてるのである程度大きくしないと恩恵すら受けることが出来できません。
12. VisualVM等を利用してプロファイリングを行いましょう。
上記に記載した、GCのチューニングは基本ですが、それ以外でも、CPUの使用時間、メソッドの呼び出し回数とか諸々確認してください。
13. 負荷試験も繰り返しましょう
1回しただけでレスポンスでない!と憤慨されることが多いですが、当たり前です。結果を元に、改善する方法を想定し、設定して試してを繰り返さないと良い結果は出ません。
似たような環境に見えても、CPUの処理速度に依存したりメモリもサイズだけじゃなくのバンド幅も影響ありますし、ディスクのIOとかは結構影響が多いので、いろいろと試すことが重要です。
14. コンサルティングサービスを利用しましょう。
これを読んで、理解できない、無理と思った場合は、諦めて負荷試験をしないのではなく、弊社のコンサルティングサービスをご利用ください。
明日、AdventCalendar最終回は、実際にAccel Platformで、負荷試験を実施する際に変更すべき内容をご紹介する予定です。
