9.6.4 アプリケーションの検証
アプリケーション設計は,SQL Serverを使用したシステムを構築した場合にシステムの性能を決定するうえで重要な要素となる。サーバーはクライアントアプリケーションからの要求に基づいてSQL Serverにアクセスし,SQL Serverの処理を決定する。すなわち,アプリケーションのプログラムロジック(アルゴリズム),実装方法(コーディング上の技法),使用する命令に応じて,SQL Serverの性能が左右されることになる。
アプリケーションの性能を検証するためには,プログラムのどの部分が実行されたときに,どの程度の実行時間がかかったのかを知る必要がある。Microsoft社製の開発ツール群であるVisual Studioには,アプリケーションの性能を評価するためにいくつかのツールが用意されている。たとえば,Visual Studio Enterprise EditionにはApplication Performance Explorer*1やVisual Studio Analyzer*2が添付されているし,Visual C++にはコードプロファイラ*3(PREP,PROFILE,PLIST)が添付されている。
そのほかにも,サードパーティから各種の評価ツールが提供されている。たとえばTransact-SQLステートメントを評価するのであれば,Database Architechs社から販売されている「SQL Scope*4」を利用することができる。また,C言語やC++で開発したソースコードを評価するのであれば,Intel社が販売している「Vtune*5」も利用できる。必要であれば,ユーザー自身がアプリケーションに時刻計測ロジックを埋め込んで調査することも可能だろう。
一般的に,アプリケーションは効率よくコーディングしなければならない。したがって,アプリケーションを設計するとき,あるいはコーディングするときに,次のような点に注意する必要がある。アプリケーションが適切に設計されているか否かを調査する場合にも,これらの点について検証する必要がある。
○動的ステップ数を最小限にする
アプリケーションプログラムは多くの命令コードのステップから構成されている。しかし,すべての命令コードが実行されるわけではない。処理を遂行するために実際にプロセッサで解釈され実行された命令コードの数を,「動的ステップ数(走行ステップ数)」と呼ぶ。動的ステップ数が多ければ,当然ながら処理に時間がかかる。動的ステップ数を最小限にとどめるため,重複したステップや不要なステップを削除することが必要になる。エラー処理も,実際にエラーが発生したときにのみ実行するようにしなければならない。
○最適な命令を選択する
アプリケーションの任意の機能を実現するために利用可能な命令とその組み合わせには,さまざまなものがある。そのうちのどれを採用するかによって,実現する機能と処理性能,あるいは実現する機能と保守性などの点でトレードオフとなる。多少機能的に不足があっても,処理性能や保守性を最優先にすべき場合もあるだろう。
○アプリケーションのサイズを小さくする
アプリケーションのサイズも重要である。昨今はメモリの価格も安くなり,容易に追加できるようになった。しかし,だからといってアプリケーションのサイズが無制限になるわけではない。Windows
NTの場合,Enterprise Edition以外では最大2Gバイトのアプリケーションしか利用できない。しかも,実際にコンピュータに搭載されている物理メモリを超過するようなサイズのアプリケーションを動作させようとすると,アプリケーションの一部がディスク上のページファイルに待避され,アプリケーションが呼び出されるたびにWindows
NTがディスクI/Oを処理してメモリ上にロードすることになる。当然ながら,このような処理を実行するとプロセッサとディスクのI/Oリソースを消費することになり,アプリケーションの性能に重大な影響を及ぼす。コンピュータに搭載された物理メモリは,通常のPCサーバーでは128M〜512Mバイト程度,クライアントPCであれば32M〜64Mバイト程度が一般的であろう。サーバー上で複数のアプリケーションを同時に動作させるのであれば,プロセッサおよびディスクに負担をかけないためにも,できるだけ効率的で小さなサイズのアプリケーションを作成することが重要となる。場合によっては,アプリケーションプログラムのワーキングセットを調整することも必要であろう。
○処理に必要なデータのみを取得する。
大きな結果セットをデータベースから読み込み,クライアントアプリケーションで処理すると,プロセッサとネットワークに過大な負荷をかけるおそれがある。クライアントとサーバーとのあいだを結んでいるネットワークは,たかだか100Mbpsの速度であり,WANを利用する場合はさらに低速であることがほとんどだろう。ネットワークの転送能力は,システムを構成するほかのリソースと比較して低いものである。このようなネットワークを利用してクライアントとサーバーとのあいだでデータをやり取りする場合,できるだけ転送するデータ量を低減したり,やり取り自体を少なくしたりして,ネットワークの負荷を軽減することが必要になる。
一般的にPCクライアントのハードウェア性能はPCサーバーのそれと比較すると低い。サーバーからデータを取得して処理する場合は,大量のデータ処理をできるだけサーバー側に任せ,クライアント側では必要最小限のデータ処理のみを実施するのが妥当だろう。そのためには,クライアントアプリケーションで不要な行や列を取得しないように,結果セットを小さくする必要がある。具体的には,クエリの探索条件に適切なインデックスの定義されている列を指定し,抽出行数を少なくすることが有効となるだろう。
○クエリタイムアウトあるいはロックタイムアウトを設定する
SQL Serverの負荷が大きいためにクエリの処理が長時間に及び応答時間がかかる,あるいはサーバーやネットワークなどの予期せぬ障害によってクエリの結果が返ってこない,クエリが無限ループに陥っている,などということもある。そのような場合には,ほかのアプリケーションにシステムリソースを解放することができないことも考えられる。
このように,予想以上に応答が遅くなるときは,要求をキャンセルして再実行できるようにする必要がある。このとき,適切なAPIを呼び出して適当なクエリタイムアウト時間を設定し,その時間を超過した場合には,クエリの処理をロールバックしてロックを解放し,アプリケーションを終了させることが必要となる。
また,クエリタイムアウトやロックタイムアウトをTransact-SQLステートメントレベルで明示的に制御できるアプリケーション開発ツールを使用すべきである。たとえば,VBSQL(Visual
Basic Library for SQL Server),RDO(Remote
Data Objects),ADO(ActiveX Data Objects)などを利用すればよい。
タイムアウト値は,アプリケーション開発時やシステム評価時に得られたデータを元に,その2〜3倍の時間を設定する。ODBC
APIを利用している場合にはSQLSetStmtOption関数で,OLE
DB APIを利用している場合にはSetOptions関数で,それぞれタイムアウト値を設定できる。
ここでは,開発言語ごとに,アプリケーション設計およびコーディングに問題がないかどうかを調べるときのチェックポイントおよびチューニングポイントについて説明する。
-
Application Performance Explorer(APE) は,分散システムにおけるアプリケーション設計をモデリングし,予測される性能をテストすることができる。テストは自動化することもできるので,最大のネットワークトラフィックやスループットを記録する特定の時刻に自動的に評価させることもできる。
-
Visual Studio Analyzerは,分散アプリケーションの構造,性能,アプリケーションを構成するコンポーネントの相互作用について,アプリケーションレベルで評価・分析・デバッグするためのツールである。複数の言語を使用している場合や,複数のプロセスとシステムにまたがっている場合でも,性能を評価したり,デバッグしたり,分析したりすることができる。通常,コードプロファイルツール(Microsoft Source Profilerなど)は,コンポーネントまたは1つのプロセスのどこで最も実行時間がかかっているかを正確に把握するために使用され,特定の関数や特定のコード行での所要時間をパーセント単位で通知する。それに対して,Visual Studio Analyzerの性能分析は,アプリケーション情報の流れに基づいて,どこで時間を消費しているのかを大まかに把握するために使用される。関数レベルやコード行レベルではなく,イベントレベルで性能情報を表示する点が特徴といえる。
-
Visual C++のProfessional EditionとEnterprise Editionだけの限定機能である。
-
詳細は,http://www.intel.co.jp/jp/developer/vtune/index.htmで参照できる。また,無料評価版がhttp://www.intel. co.jp/jp/developer/vtune/analyzer/demo2.htmからダウンロードできる。
| Chapter 9 16/46 |
