質問

2011年11月13日 02時24分
  • IIS6+SQLServer2005構成のWebアプリケーションのボトルネック診断

情シスのオープンナレッジ『Syszo』サービス終了のお知らせ

質問

皆様、お疲れ様です。

Webアプリケーションのボトルネック診断の勘所みたいなものがあれば
ご教示いただきたいと思い投稿させていただきます。

詳しい設定などははあまり把握できていないのですが、

WebApサーバ・・・Windows2003Server + IIS6.0 + VB.NET
DBサーバ・・・SQLServer2005

という構成のWebアプリケーションを数ヶ月前にサービス開始しました。

このサービスの利用が本格化するにつれ、ユーザのアクセスが集中すると極端にレスポンスが
低下するという現象が発生するようになりました。

まずはネットワークトラフィックを疑ってみたのですが、
その影響を受けない環境でも現象が認められたため
ネットワーク環境に関しては問題ないと思われます。

とすると、IISかSQLServerにボトルネックになる要因が
隠されているのではないかと推測しているのですが、
ボトルネックの原因の発見方法及びパフォチューに関するアドバイスなど
あればいただけないでしょうか。

例えば WebLogic であれば、コネクションプールといったわかりやすい設定項目があって
然るべきログを見ればそれが適正かどうかがわかるのではなかったかと思うのですが、
(聞きかじりレベルの知識なので違うかもしれませんが)
IISに関してはいろいろ調べてはみたのですが、なかなかこれだという情報が得られない状況です。

情報が粗く、回答しづらい投稿かとは存じますが、なんらかのヒントが得られればと思っております。
よろしくお願いいたします。

3件の回答があります

回答

ネットワーク構成、機器構成が見えないので・・・ひとり言。

よくあるのは、WebAPサーバとDBサーバの間かな・・・
・複数CPUサーバを利用しているとギガでも不足するかも・・・
・アプリが考えなしにDBアクセスしているとなるかも・・・
あとは、DBサーバの処理能力不足。

ネットワーク、ハードウェア、OS(IISを含む)、アプリケーションをそれぞれ確認項目を上げて1つ1つ調査して可能性を潰すことが大切です。
大変な作業になりますが、頑張ってください。

蛇足ですが、過去にあった判りにくかった体験を・・・
※かなり単純化して名称なども変えてますが、でも落ちは一緒です。
同じようにレスポンス低下の問題があり全ての調査項目を潰しても原因不明のため、通信会社にネットワーク経路を調査して貰ったら以下のような調査結果になりました。
ネットワーク経路の調査結果PC
(2)事務棟にあるルータa
(3)事務棟にある認証サーバ
(4)事務棟にあるルータa
(5)工場にあるルータc
(6)工場にあるWebAPサーバ
(7)工場にあるルータc
(8)事務棟にあるルータa
(9)工場にあるルータc
(10)工場にあるDBサーバ
(11)PC
調査結果より何が原因かわかります?
(7)〜(9)が不要で、そのため「事務棟にあるルータa〜工場にあるルータc」の回線容量不足が発生していた。誰もが(6)の次は(10)と思っていて、関係者全員ビックリ!という笑い話でした。

回答

情報が粗く、回答しづらい投稿
ですね 

ユーザのアクセスが集中すると極端にレスポンスが低下する
そのアクセスは”画面の参照”だけでしょうか? あるいはデータをピックアップしてExcelにはき出す ということはやっていませんか? 以前に聞いた話で (クライアントのExcelではなく)サーバ上でSQLからExcelにはき出す というシステムでユーザが集中すると極端にレスポンスが落ちる という事がありました。  

2011年11月13日 16時23分

回答

パフォーマンスチューニングの基本は、先ずは
「アプリケーションチューニング」にあります。

そもそも、データベース設計やプログラムの書き方が悪ければ
レスポンスが低下して当たり前です。

そうも言ってられないのでAPやDBのチューニングをすませた後、
ハードウェアの性能向上に手を出し、それでダメなら次の
プロジェクトで努力(できればいいな)か作り直しかという
ケースが多いのではと思います。(実際それすらできないPJも
多いかもしれません。)

という訳で、先ずはAP(IIS)->DB(SQL Server)の順でチューニング
をいたします。

APチューニングの基本は1スレッド(プロセス)あたりのメモリ
使用量の調整とスレッド数(プロセス数)の調整及び、
コネクションの開放までの時間とコネクション数の調整あたりに
なるかと思います。

(アプリケーションチューニング後の) DBチューニングの基本は
やはり同上の様に適切なメモリの割り当てが中心となります。
データベースをデフォルトインストールで使用している様であれば
SORT等の一時データ記憶用のメモリ領域(temp_db)が小さいため、
これは早めに領域拡張する事をお勧めいたします。RAM上に構築
するという方法やSSD上に構築するというのも一手法です。

上記は先ずはタスクマネージャー等でおおざっぱにどの程度メモリを
利用しているか確認するだけでも参考にはなると思います。
詳細は「データベース・チューニング・アドバイザ」や「SQL
Serverプロファイラ」を使用して確認してみて下さい。

ところで・・・DBチューニングに関し
ORACLEでもそうですが、十数年前と比較した場合メモリを多めに
与えておけばチューニングの9割は自動でできてしまうように
なっているかと思います。パラメーターをマニュアルで調整
する場合は慎重に行った方がよろしいかと思います。

現物を見ておりませんのでヒントになるかわかりませんがご参考まで。

2011年11月20日 00時24分

あなたもコメントしましょう!