| 2003年11月13日
『どっとねっとと雑多な日々 15』
このところ、本業が忙しく研究がまったくできなくて困っています。
＃私の本業は火消し役？のようです。
困ったことにまだまだ火の手が上がっているので、収束にはしばらく時間がかかりそうです。
さて、こんな状況なので、私がかかわっている問題について書いてみたいと思います。
皆さんはシステム開発を行う場合、仕様を決めた上で開発するか XP モデルのようにスパイラルに開発を行うかどちらかになると思います。
開発者は、機能的な仕様にフィックスするの頭がいっぱいになり勝ちで、レスポンスについては後回しであることがよくあることだと思います。
後回しにして、痛い目に合うケースはよくご存知のとおりです。
私のかかわっている問題はまさしくこのケースです。
機能的な仕様は満たしているが、レスポンス要件が不明確のまま本番カットオーバを迎えたため、壊滅的な状況に陥ってしまったという感じであります。
ここでの教訓は、ユーザからの要求を呑む場合、それがいかなる影響がでるかを調査して、レスポンスが悪化する可能性がある場合は明示的に伝える必要があるという点と、レスポンス要件は明確にしておくべきという点であります。
＃その前にシステム開発するのにハードが先行して決定してしまったという敗因もありますが。
それでは、レスポンス問題が発生した場合にはどう乗り切るのかをデータベース周りで考えてみたいと思います。
1.ConnectionPooling が利用できる場合は利用を検討する。
2.非効率な SQL を SQL プロファイラで洗い出す。
※プロファイルで SQL を収集してクエリアナライザーで解析する。
3.Index が使われていない場合は、適切に Index を指定する。
4.Cursor が足を引っ張っている場合は一時テーブルを利用した SQL などに置き換える。
5.可能であれば StoredProcedure に切り替える。
などができると思います。
これを見て、皆さんあれ？とおもうことがあると思います。
SQL Server 自体はチューニングしないの？という点だと思います。
SQL Server をチューニングしても劇的に改善するには短時間では難しいし、効果も顕著にでない場合もあるので、よほどのことがない限りこちらには手を入れません。
※私の場合ですが。
また、ハードを換えるのは金銭的に難しいケースもあるので、こちらも最後の切り札として温存しておきます。
データベース周りをチューニングしても、アプリケーションのつくりそのものが悪ければ、何をやっても無駄なケースもあります。
そんなときは、腹をくくってスクラッチ＆ビルドという博打を打つこともあります。
そして最悪ごめんなさいというシナリオに行き着くかも知れません。
私の問題は根が深いので、もしかすると本当に玉砕する可能性があります。
最悪なケースにならないようにがんばって、リリースできればいいなぁと思っていますので、皆さん影ながら応援してくださいね。
＃成功の確率は 10% 程度。。。
また、皆さんが私のような問題に巻き込まれないことを祈っています。
それでは、また修羅場に戻ります。
|
