システム自体のチューニングは、順序が大事

チューニングの際に、よく依頼者から言われることは、

• 「DATA BASEをチューニングして下さい」とか
• 「速くなるSQLの文法を教えて下さい」とか
• 「このSQLが遅いんですけど・・・」

が、結構多いのです。
しかし、依頼者には残念な事に、私の回答は一律下記なのです。

• 「まずは、調査が先です」

こて先のチューニングをしても不幸な結果になる事が多く、
又責任を転換される可能性も高いので、簡単に作業には入れません。

まずは、「計る事」
それから、実態を調査します。
※測定と実態調査は並行して行ってもOK

調査の時に重要な事項は、不具合（バグ）の収束率です。
不具合があるシステムは、いくらチューニングしても無意味です。
※チューニングする箇所に多くは不具合も集中するので・・・

チューニングの考え方の順序は、いたってシンプルです。

1. 計る
2. 実態の調査
3. 問題点の抽出
4. 課題の抽出
5. 課題消化の優先順位付け
6. 課題消化

NO３以降は、各機能毎やアプリケーション毎に抽出を行います。

つまり、やらなければいけない事を明確にする事が一番大切なのです。
結構、切羽詰まった時に思い出される事がチューニングですので、
目先の事に目が行くのは当然ですが、
まずは、「問題点を抽出する為に、システムを計り、現状を知る」
これに尽きます。

では、次回は、「問題点の抽出」について、考えてみます。