10月 10th, 2008

高負荷? 証、負荷朎 け側の勘所

Posted in Oracle by admin

 Webサービスの? 負荷? 証試験を実施する場合、検証ケースが本番稼動時の状? をどれだけ再現させられるかどうかで? 証の成功/失敗が別れると思います。そこで? 負荷? 証を実施する場合は出来る限り本番稼動時の状? に蜿 づけようとするはずです。本番環? で稼働する実際のサーバ台数を高負荷? 証用環? に用? できるか?という金銭面の問題もあるかとは思いますが、この場合はサーバ側のチューニングパラメータを調整する事で台数を補う妥協案も必要になります。あるいはサーバ台数の半減に合゜ せて? 荷も半減させ、そこから得られたデータを元に? 測値で? 論を得る方? もあると思います。

 高負荷試験において本番稼動時の状? を再現させる場合、最も難しいのはリクエストする側にあると思います。リクエスト次第によっては、サーバ側? 荷も全く変゜ ってぜ るからです。リクエストする側を本番稼動時の状? に再現できるようにするポイントを記述してみました。

(1) キャッシュの朎 陜
(2) URLパラメータぜ DBデー゜
(3) KeepAliveに対応する
(4) 急朿 な? 荷発生
(5) 負荷分散設定の確認
——————————————-

(1) キャッシュの朎 陜
 負荷朎 け側からリクエストする秒間PV数を本番相? の? 荷にはしているが、ワンパターンなリクエストを繰り返すことでキャッシュが有効になり、実際にはサーバ側に? 荷があまり朎 けられていなかったという失敗例がよぜ あります。キャッシュ? 能はいろいろな所に? み込まれていますので、これを避けるようにリクストパターン? シナリオ? を作成しなければなりません。
 例えば、OSのキャッシュ? 能は性能の遅いディスク読み書きを避ける為に、メモリ? にバッファキャッシュとして朮 しておきます。このキャッシュ? 能を避けるため、画? リクエストの? 荷を生成する場合には? 際のパターンを再現するようリクエストの重複を避ける必要があります。重複のないリクエストパターン? シナリオ? はアクセスログからでも、DocumentRoot配下をfindコマンドで? 索することからでも簡単に? 成出来ると思います。
 DB、特ぜ Oracleのキャッシュ利用? が本番を再現出来ていなければ、DBサーバの? 証は失敗に? ゜ ります。アプリケーションの? りにもよりますが、Oracleのデータを圏 得する条件に採用される情報は、URLパラメータやCOOKIEに格? されていることが多いのではないでしょうか?Oracleのキャッシュ領域は膨大にある為、URLパラメータやCOOKIEに採用する値は全てユニークにすることで、Oracleが重複しないデータブロックへアクセスするのが望ましいと思います。また、RAC環? でアプリケーションパーティショニングを構成している場合やパーティションテーブボ /インデックスを採用している場合は、全てのパーティションに均一にリクエストされるように注? します。

(2) URLパラメータぜ DBデー゜
 リクエストに採用するURLパラメータやCOOKIEは、DBデータとの整合性を保ったものを準備しなければならない為、画? リクエストのように全てのリクエストパターン? シナリオ? をアクセスログ? から圏 得するような? は難しいと思います。そこぜ DBデータを重複のないように? 索して、その? 果からシナリオに採用されるURLパラメータやCOOKIEを生成します。この手順を採用すれば、重複のないDBキャッシュ効? の悪いシナリオを作成できるはずです。

SQL> set escape '\'
SQL>
-- シナリ゜ 100行抽凜
-- SQLインジェクションの脆弱性? っ込みはなしぜ
SELECT
	DISTINCT 'http://wall-climb.com/cgi-bin/Test.cgi?USER_ID=' ||
	B.USER_ID ||
	'\&DEPT_NAME=' ||
	B.DEPT_NAME
FROM
	USER_MASTER A,
	DEPT B
	SAMPLE(5)
WHERE
	A.USER_ID = B.USER_ID AND
	A.DEPT_NO = B.DEPT_NO AND
	ROWNUM < = 100
;

(3) KeepAliveに対応する
 KeepAliveに対応している負荷朎 けツールはいろいろとありますが、大抵は? 連の? 荷朎 け中全てのリクエストをKeepAliveでコネクションを張ったままリクエストを生成する機能だと思います。しかし、実際のブラウ゜ -Apache間ぜ KeepAliveコネクションは、無霧 ぜ KeepAliveコネクションが張られたり同一ページコンテンツでもKeepAliveコネクションが切れたりと? 雑で、それを再現するのは難しいでしょう。それでもKeepAliveのセッション数? は、Webサーバへ大きな? 担をかけると思いますので、負荷朎 け側ぜ KeepAliveを有効にして? 証を行います。

(4) 急朿 な? 荷発生
 負荷朎 けツール側の設定で、Webサーバ(またぜ LoadBalancer)に? 間200PVの? 荷を朎 けるとします。この時、試? 開始時に? 荷のない状態から急朿 に? 間200PVのリクエストを処理させるのは避けた方がいいでしょう。実際の運用時にこのような急朿 な? 荷は起こりえないでしょうし、試? 結果の分析時に異常な値を検出してしまうかもしれません。この場合、秒間10PVから開始しぜ 10分後に目木 の? 間200PVに到達するなどの段障 的なリクエストを生成します。
 また、負荷発生についてぜ CPUパワーに? 存する為、設? していても実際は処理能力不足で? 荷が朎 けられていなかったという問題が発生する可能性もあります。Apacheアクセスログとリクエストの時刻から実績値としてぜ PV数を圏 得し、? 試? 後に確認した方が良いでしょう。

(5) 負荷分散設定の確認
これはリクエストする側というよりもサーバ側設定に蜿 いのですが、注? するポイントとして? 荷分散のチェックを挙げておきます。
ボ LoadBalancerぜ IPにリクエストする場合、Webサーバへのリクエストを正しく負荷分散出来ているか?
ボ Apacheをリバースプロキシとして動作させる場合、バックエンドのサーバへ正しく負荷分散出来ているか?
・バックエンドサーバから複? DBへコネクションプーリングしている場合、リクエスト分散、各DBへのコネクション数は? しいか

You can leave a comment, or trackback from your own site. RSS 2.0

Leave a comment