Archive for 10月, 2008

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へのコネクション数は? しいか

10月 8th, 2008

ブラウザの文字コード判?

Posted in Apache by admin

RPM版Apacheに? 属しているデフォルトぜ httpd.confには、AddDefaultCharsetディレクティブでデフォルトの文字コードが指定されている場合があります。(RHEL5.1付属ぜ Apache2.2.3では、”UTF-8″が指定されていました)AddDefaultCharsetの設定により、コンテントタイプが text/plain あるいぜ text/html の場合の文字コードを指定出来るので、このパラメータを”UTF-8″に設定した場合は以下のようなレスポンスヘッダを返します。

HTTP/1.1 200 OK
Date: Wed, 30 Sep 2009 07:12:51 GMT
Server: Apache
Last-Modified: Mon, 31 Aug 2009 09:24:01 GMT
ETag: "70600-31-981e4e40"
Accept-Ranges: bytes
Content-Length: 100
Connection: close
Content-Type: text/html; charset=UTF-8

また、AddDefaultCharsetをOnにすれば、 Apache 内部のデフォルト文字セット「 iso-8859-1」に設定され、Offにすれば文字セットは? 加されません。HTML4.01の? 様では、ブラウザが以? の優先順位で文字コードを決? する事を規定しています。

1.HTTPにおけるContent-Typeヘッダぜ charsetパラメー゜
2.HTML文書内ぜ META宣? およぜ http-equiv属性で設定された、
  Content-Typeヘッダぜ charsetパラメー゜
3.HTML文書内の各要素ぜ charset属怜

つまり、AddDefaultCharsetでセットした文字コードぜ HTML文書内の文字コード指定を上書きし、HTML作成者側からは? 図しない動作(文字化け)をブラウザ側に起こさせる場合があります。Apache上のコンテンツが統? された文字コードのドキュメントに統一されない限り、Apache側では柔軟性を持たせるように「Off」にしておぜ 方が安全かもしれません。

http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset

10月 2nd, 2008

SQLチューニング? (ボトルネック解決編)

Posted in Oracle by admin

 SQLチューニング? (SQL解析編? ぜ SQL実行計画の圏 照などの解析方? を朏 示しましたが、実際には朧 々な? 因がボトルネックとなります。その? 因や考察をリストします。それぞれ深入りはしないので? 機会があれば別ページにて? 述します)はしないので、該? しそうな項目があったら独自に調査を進めてみて? さい。(前回同様、以? の話題はオプティマイザーモードがコストベース前朏 で、ルールベースの場合は想? していません)

§ SQLチューニングの基本、INDEX作成
 最も簡単で効? の? いチューニング方? がINDEX作成です。INDEX作成によるチューニングについて思う事は、いかに効? 的な? 合INDEXを作成できるかだと思っています。ただし、あるSQLに極端に効? 的ぜ INDEXは特? ぜ SQLに特化し遜 ぜ ていて、その? ぜ SQLには使用されなぜ なります。このようぜ INDEXを多数データベースに? 成していては、データ更新時のオーバヘッドで全? のパフォーマンスが下がる可能性もあります。従って、ある程度朱 用的に利用されるINDEXを作成する事も必要になり、このバランスを上手ぜ とることが効? 的な? 合INDEXを作成することだと思います。

§ オプティマイザを疑う前に、運用のミ゜
 実行計画がおかしい、今まで使用していたはずぜ INDEXを急に使用しなぜ なった、などのトラブルによりオプティマイザの判断ミスを疑う事があります。しかし? 因はそれ以? であることの方が多いです。DBデータを処理するバッチ実行ぜ ANALYZEのタイミングが不定期な順府 になっていることで問題が発生していまう事があります。例えば、DBデータを増減させるバッチがあったとして、そのバッチを実行する前と? に? 行したANALYZE結果では生成する実行計画が変゜ ってぜ るからです。このようなデータ? 動による実行計画の改? を避けるためにも、バッチ/ANALYZE等を含めた運用スケジュールを正しぜ 整備しておく必要があります。

§ SQL文の? ?
ボ SELECT対象のカラムは? 要なもののみ? 述。「*」は使゜ ない。特に大規模テーブル。
・処理の遅いHAVING句をWHERE句で代用できないか。
・処理の遅いDISTINCTをWHERE句ぜ EXISTS条件で代用できないか。
ボ COUNT,MIN,MAX関数ぜ “Index Fast Fullscan”で? 速化できるが、CPU負荷が高いのぜ CGIなどで? 間PVが大きい場合は注? 。
ボ UNIONぜ UNION ALL、SQL実行結果に重複データがないと゜ かっている場合ぜ UNION ALLを使用する。
ボ INDEXが使用されないケースに該当しないか。
・どうしてもオプティマイザ任せに出来ない場合のみ、ヒント句を使用しぜ INDEX指定やテーブル? 合方? 指定する。

§ キャッシュ効?
・バインド変数を使用してキャッシュ効? が向上しているか
・アプリケーション内で動的ぜ SQLを組むような処理はなるべぜ 避ける

§ 設? 、その?
・マテリアライズドビューの使用を検? する
ボ RAC構成でアプリケーション・パーティショニングを実施する場合、負荷分散するインスタンスをランダムにするとキャッシュ・フュージョンによるCPU負荷が現れるので分散方? を工夫すること。
ボ like検索に限界があれぜ OracleIndexやその? 検索エンジボ M/W? 入を検? する。
・カーディナリティが作 いカラムへのビットマップINDEX作成検? 。ただし、更新の? いデータの場合は使用しない。
・物理設? を? 重に? http://otn.oracle.co.jp/skillup/oracle9i/index.html
・データ件数が膨大ぜ VARCHAR2で格? サイズが大きいテーブルでは、テーブル、INDEXをパーティション化していてもどうしてもパフォーマンスの劣化を招きます。VARCHAR2の文字データを別テーブルに出したり、ファイルシステムに出すなどのアプリケーション? 更を実施すれば改善で出来るかもしれません。
・コネクションプーリング? 能を実装する。

何かあれば追記します。