Net.Data プログラミング・ガイド

第 8 章パフォーマンスの改善

パフォーマンスを向上させるには、次のようないくつかの方法があります。

ストアード・プロシージャー
慎重なコーディング
API の使用
ライブ接続の使用

通常 Net.Data のパフォーマンスを向上させる 2 つの方式は、ライブ接続の使用と、 Web サーバーのアプリケーション・プログラミング・インターフェース (API)、たとえば、ICAPI、ISAPI、および NSAPI などを使用することです。ご使用のプラットフォームで何がサポートされるかについては、 Net.Data 言語環境ガイドを参照してください。

ライブ接続

サーバーのなかには、ライブ接続を使用して永続的なデータベース接続を維持することで、パフォーマンスを向上させることができるものがあります。いくつかの Net.Data アクションは、長い始動時間を必要とします。たとえば、プロセスは、データベース照会を発行するまえに、自身を DBMS に対し識別し、データベースに接続しなければなりません。この時間は、データベースにアクセスする Net.Data マクロに必要な処理時間のかなりの部分となることがよくあります。時間がかかる始動の別の例としては、 Java アプリケーション (Java アプレットではなく) を実行するのに必要な、 Java 仮想計算機があります。 CGI プログラムの動作方法のため、これらの始動コストは、Web サーバーへの要求ごとに支払われることになります。

ライブ接続は、このような始動にかかるオーバーヘッドを除去して、パフォーマンスをめざましく向上させることができます。始動機能を実行する 1 つまたは複数のプロセスを連続的に実行させることから、コストの節減が生じます。それからこれらのプロセスは要求のサービスを待ちます。 Net.Data を CGI プログラムとして使用する場合は、ライブ接続を実行することができます。 Web サーバー API を使用する場合は、ライブ接続を使用しなければなりません。

ライブ接続は、接続マネージャーとクリエッツ（プロセスの一つ）から構成されます。 6 クリエッツは、接続マネージャーが開始し、サーバーの稼働中、活動状態であり続ける、単一スレッド・プロセスです。クリエッツは、データを処理し、初期設定ファイルの Net.Data 言語環境とキーワード CLIETTE によって通信します。特定のバックエンド機能を処理するために、各タイプのクリエッツが作成されます。たとえば、DB2 クリエッツは、 Net.Data マクロが Net.Data によって処理されるまえに、データベースに接続し、 SQL 呼出しを実行するための命令をセットアップします。この実行可能プログラムは、構成ファイル dtwcm.cnf で命名されます。

ライブ接続の利点

ライブ接続を使用する主な利点は、次の 3 点です。

パフォーマンスの向上
新しい接続を作成するよりも、接続を再使用する方が効率的です。接続時間のコストが処理時間全体と比較してどれくらいのコスト程度であるかを、判別しなければなりません。一般に、小さな SQL ステートメント (たとえば、 100,000 行未満のデータベースでの単純な照会) を要求する場合や、接続が困難である (たとえば、リモート・サーバー) 場合には、接続時間はかなりかかります。
複数のデータベース・アクセス
ライブ接続では、1 つの Net.Data マクロを同時に複数のデータベースに接続することができます。これはそれぞれのデータベースが固有のクリエッツを持つために可能なことであり、それにより Net.Data は複数のクリエッツと通信します。
順次表示
接続マネージャーには、 SELECT ステートメントを処理し、最初の N 行を廃棄する機能があります。これにより、大きなリストをナビゲートするための NEXT オプションと PREVIOUS オプションが利用可能なアプリケーションを使用することができます。変数 START_ROW_NUM を N に設定することで、大きな照会を分割して、管理可能な大きさのものが示されるようにすることができます。これにより、アプリケーション・ユーザーは、NEXT ボタンをクリックして、行の次のセットを取り出すことができます。

ライブ接続を使用すべきかどうかの判別

データベースとの通信に (CGI の代わりに) API を使用することにした場合は、ライブ接続を使用しなければなりません。ご使用のアプリケーションに次の要件がある場合、ライブ接続の使用が有益である可能性があります。

複数のデータベースからのデータがアプリケーションに必要である。
ライブ接続を API とともに使用すると、多くのシステムでパフォーマンスが向上します。ただし、 Web サーバーへの (URL からの) 要求の送信時に新しいプロセスは作成されないので、システムの負荷と構成によってパフォーマンス向上の程度は異なります。しかし、接続マネージャーには追加のシステム管理が必要となります。最適な構成を決定するため、それぞれのシステムで試験してみる必要があります。

多くのアプリケーションでは、 ACTIVATE DATABASE または START DATABASE コマンドを使用して、データベース接続の確立時間を軽減させることにより、ライブ接続を使用せずにパフォーマンスを向上させることができます。データベースが使用するコマンドの詳細については、ご使用のデータベースの資料を参照してください。また、ご使用のプラットフォームの資料を参照して、パフォーマンス向上の援助となるそのほかのステップがあるか調べてください。

接続マネージャーの開始

接続マネージャーは、Net.Data とは別個の実行可能プログラムであり、 dtwcm という名前です。Web サーバーを開始するときに、接続マネージャーを開始しなければなりません。接続マネージャーを開始すると、接続マネージャーは構成ファイルを読み取り、データを処理するプロセスのグループを作成します。それぞれのプロセスで、接続マネージャーは特定のクリエッツの実行を開始します。

すべて (データベース、Web サーバー、および接続マネージャーを含む) が構成され、稼働すると、ライブ接続が使用可能になったときの Net.Data 処理には、一般に次のようなステップが含まれます。

Web サーバーが起動され、Net.Data を実行するため、 CGI プロセスか API スレッドが開始される。
Net.Data が Net.Data マクロの処理を開始する。
Net.Data は、ライブ接続を使用する関数呼出しを検出すると、どのタイプのクリエッツが必要であるか初期設定ファイルから判別する。 DB2 の場合、クリエッツ・タイプは、DB2 データベース名に基づく名前であることがほとんどです。この例では、クリエッツ名は、DTW_SQL:CELDIAL です。Net.Data は、そのタイプのクリエッツについて接続マネージャーに尋ねます。接続マネージャーは、利用可能なそのタイプのクリエッツを探します。利用可能なものがなければ、接続マネージャーはその要求を待ち行列に入れ、正しいクリエッツ・タイプが利用可能になったときにそれを処理します。クリエッツが利用可能になると、接続マネージャーは、 Net.Data に対してそのクリエッツとの通信方法を知らせます。
Net.Data が、クリエッツにその関数を処理するように依頼する。
このプロセスが、Net.Data マクロ処理が完了するまで、ステップ 3 から繰り返される。
すべてのクリエッツが解放される。

初期設定ファイルにクリエッツが指定されているものの、接続マネージャーが稼働していない場合は、 Net.Data は DLL をロードし、そのマクロを処理します。API を使用すると、おそらくエラーを受け取るので、接続マネージャーを開始しなければなりません。

ライブ接続の構成

ライブ接続は、構成ファイル dtwcm.cnf を使用して、どのクリエッツを開始する必要があるかを判別します。この例にはサンプル構成ファイルが示されており、このファイルには、次のブロックが含まれています。

管理情報
DB2 接続用の SQL クリエッツ情報
Java アプリケーションのクリエッツ情報

行は参照のため次のように番号付けられています。

 1  CONNECTION_MANAGER{
 2  MAIN_PORT=7100	
 3  ADMIN_PORT1=7101
 4  ADMIN_PORT2=7102
 5  }
 6 
 7  CLIETTE DTW_SQL:CELDIAL{
 8  MIN_PROCESS=1		
 9  MAX_PROCESS=5		
10  START_PRIVATE_PORT=7200		
11  START_PUBLIC_PORT=7210	
12  EXEC_NAME=./cltdb2
13  DATABASE=CELDIAL		
14  BINDFILE=/usr/... .../d2wsql.bnd
15  LOGIN=marshall		
16  PASSWORD=stlpwd		
17  }
18
19  CLIETTE DTW_APPLET{	
20  MIN_PROCESS=1	
21  MAX_PROCESS=5		
22  START_PRIVATE_PORT=7300	
23  START_PUBLIC_PORT=7310	
24  EXEC_NAME=./javaapp	
25  }

行 1 - 5 は、構成ファイルに必須です。行 7 - 12 および 17 は、すべての SQL クリエッツに必須です。DB2 データベースに接続する場合は、ユーザー ID やパスワードなどの追加情報を組み込むことができます。そのような追加の値は、行 13 - 16 に示されます。 Java アプレットを使用する場合、行 19 - 25 はすべて必須です。

LOGIN 変数および PASSWORD 変数にデフォルト値を使用するように、指定することができます。これは、 DB2 データベースに接続するために接続マネージャーを開始したものと同じユーザー ID を、 Net.Data が使用することを意味します。これにより、この情報を構成ファイルに入れずに済みます。たとえば、行 15 および 16 を、次の行で置き換えます。

LOGIN=*USE_DEFAULT
PASSWORD=*USE_DEFAULT

システムでどのポート番号を使用するか、判別しなければなりません。また、MIN_PROCESS および MAX_PROCESS の値を判別する必要もあります。接続マネージャーが開始されると、 MIN_PROCESS で指定された数のプロセスが開始されます。そのあと、同時プロセスが届くと、接続マネージャーは、 MAX に指定された値に達するまで、必要に応じて 1 つ追加し、さらにクリエッツを開始します。使用する値によってパフォーマンスに影響がありますが、値はあとで変更することができます。

ライブ接続を使用するには、Net.Data 初期設定ファイルに、 DTW_SQL (およびおそらく DTW_ODBC) の ENVIRONMENT ステートメントを組み込まなければなりません。詳細については、 Net.Data 言語環境ガイドを参照してください。

構成ファイルを変更するまえに、以下の点に留意してください。

接続マネージャーは、クリエッツのセットを固有に識別するためにクリエッツ名を使用します。
データベース・クリエッツの場合、アクセスする予定のそれぞれのデータベースごとにクリエッツの名前付きセットが 1 つ必要です。めったにアクセスしないデータベースの場合は、クリエッツの MIN 数と MAX 数を 1 に設定することができます。あるいは、 MIN を 0 に設定することもできます。0 の場合は、クリエッツに対して Net.Data 要求が行われるまで、プロセスが作成されないことを意味します。
クリエッツの NAME は、初期設定ファイル内の名前と一致しなければなりません。名前は、DTW_SQL 環境ステートメントを持つ行の終りにあります。このステートメントは、 CLIETTE "xxx" を読み取ります。xxx は、 Net.Data マクロ・ファイルで名前がどのように構築されるかを表します。これには、変数を含むことができ、また DB2 クリエッツの場合には、変数 $(DATABASE) を組み込まなければなりません。デフォルトは、 DTW_SQL:$(DATABASE) です。 SQL セクションが検出されると、$(DATABASE) は、 DATABASE の現行値と置換されます。このようにして、複数のデータベースにアクセスできるわけです。 Net.Data マクロでアクセスしたいデータベースが、3 つ (たとえば、 D1、D2、および D3) あり、初期設定ファイルに標準 CLIETTE "DTW_SQL:$(DATABASE)" 行があるとすれば、構成ファイルに次のような 3 つのセクションが必要です。
```
CLIETTE DTW_SQL:D1{ ...} 
CLIETTE DTW_SQL:D2{....} 
CLIETTE DTW_SQL:D3{....}
```
プロセスは開始されますが、停止されません。プロセスの MAX 数を M に設定し、いつでも M 個のプロセスが同時に使用される場合、ユーザーが接続マネージャーを遮断するまでそれらのプロセスは活動状態のままになるので、 MAX の設定値については、めったに使用しないプロセスを開始するのにすべてのシステム資源を使い尽くすほど高い値に設定したいとは思われないでしょう。したがって、MIN および MAX に別の値を設定してみて、どの値がシステムに最適であるかを調べることをお勧めします。接続マネージャーが、MAX に指定されたよりも多くの要求を受け取る場合、クリエッツが処理を完了するまで、最後の要求は待ち行列に入れられます。クリエッツが利用可能になると、要求は処理されます。これは、アプリケーション・ユーザーに透過的です。
矛盾しないポート番号を使用するよう注意してください。各クリエッツは、2 つのポートを使用します。ポートのセットを指定するときは、どのポートを使用するかを指定しなければなりません。最初の 2 つの値は、START_PUBLIC_PORT および START_PRIVATE_PORT です。最後の値は、Tクリエッツの MAX 数です。次の例は、どのポートが使用されるかを示しています。
```
START_PUB_PORT=1000
START_PRIV_PORT=1010
MAX_NUM_PROC=5
```
この例では次のポートを使用します。

1000 1010
1001 1011
1002 1012
1003 1013
1004 1014

一般的なエラーとして挙げられることは、2 つのセットのクリエッツで、使用されるポートがオーバーラップするエラーです。使用する予定のポートが使用可能であるか、システム管理者に確認してください。プラットフォームの readme ファイルには、オペレーティング・システムにどのポートが有効であるかに関する一般的なガイドラインが示されています。
別の名前が付いているセクションに、同じタイプのクリエッツを使用することができます。たとえば、構成ファイルのすべての DB2 データベース・セクションで、同じクリエッツ・タイプを使用します。同じ名前のセクションを 2 つ持つことはできません。

CGI を使用し、かつ一部のデータベースでだけライブ接続を使用したい場合には、必要なデータベースを構成ファイルにリストするだけで済みます。 Net.Data は、Net.Data マクロの処理中に、 SQL セクションを検出すると、接続マネージャーに特定のクリエッツについて尋ねます。接続マネージャーは、そのタイプのクリエッツを持っていない場合、 NO_CLIETTE_AVAIL メッセージで応答します。 Net.Data は、代わりに DLL バージョンでその要求を処理します。

ICAPI の使用

インターネット接続 API は、CGI 処理を行わないので、パフォーマンスを向上させます。インターネット接続の、 Web Programming Guide で詳細を参照してください。

http://www.ics.raleigh.ibm.com/pub/icswpg.htm

システムで使用できる ICAPI および追加情報に関する詳細は、 README ファイルに示されています。サーバーで ICAPI と稼働するように Net.Data を構成するためのステップは、以下のとおりです。

DLL または共用ライブラリーが、サーバーの CGI-BIN ディレクトリーになければなりません。たとえば、次のとおりです。
```
WWW\CGI-BIN\
```
その他の Net.Data DLL または共用ライブラリーは、サーバーの DLL または共用ライブラリーのディレクトリーになければなりません。
Web サーバーの構成ファイル (httpd.conf または httpd.cnf) に、 API を呼び出すためのサービス・ステートメントを追加しなければなりません。たとえば、次のとおりです。
```
Service /cgi-bin/db2www*   c:\www\cgi-bin/dtwicapi:dtw_icapi*
```
ICAPI には、既存のアプリケーションをサポートするための完全な互換性があります。 URL、フォーム、またはアンカーの起動は、 CGI を起動する場合と同じです。

ISAPI の使用

システムで使用できる ISAPI および追加情報に関する詳細は、 README ファイルに示されていますサーバーで ISAPI と稼働するように Net.Data を構成するためのステップは、以下のとおりです。

Net.Data は、ISAPI と使用するための DLL とともに配布されます。この DLL は、サーバーのサブディレクトリーにあります。たとえば、次のとおりです。

/inetsrv/scripts/dtwisapi.dll

ISAPI は CGI 処理を迂回するので、 Net.Data に対する CGI 呼出しを持つ Web ページおよび Web マクロを変更しなければなりません。フォームおよびアンカー参照の URL の cgi-bin/db2www/ 部分を除去し、それを dtwisapi.dll に置き換えてください。たとえば、この URL は、Net.Data を CGI プログラムとして起動する例です。

http://server1.stl.ibm.com/cgi-bin/db2www/test1.mac/report

この URL は、Net.Data を ISAPI アプリケーションとして使用します。

http://server1.stl.ibm.com/scripts/dtwisapi.dll/test1.mac/report

いくつかのディレクトリーに Net.Data マクロを保つ場合には、 DLL 名のうしろにそのディレクトリー名を指定します。たとえば、この URL は、 /orders/ ディレクトリーに格納されている Net.Data マクロを呼び出します。

http://server1.stl.ibm.com/cgi-bin/db2www/orders/test1.mac/report

次のように、更新された URL にそのディレクトリー名が保たれています。

http://server1.stl.ibm.com/scripts/dtwisapi.dll/orders/test1.mac/report

NSAPI の使用

Web サーバーは、すべての言語環境で、 NSAPI を使用するにはライブ接続を使用しなければなりません。 NSAPI を使用すると、NSAPI では CGI 処理が行われないので、パフォーマンスを向上させることができます。次の Netscape サーバー API ページで詳細を参照してください。

http://home.netscape.com/newsref/std/server_api.html

システムで使用できる NSAPI および追加情報に関する詳細は、 README ファイルに示されていますサーバーで NSAPI と稼働するように Net.Data を構成するためのステップは、以下のとおりです。

Net.Data は、NSAPI と使用するための DLL とともに配布されます。この DLL は、サーバー・ディレクトリーにあります。たとえば、次のとおりです。
```
/netscape/server/bin/httpd/dtwnsapi.dll
```

NSAPI を使用するまえに、サーバー構成に変更を加えなければなりません。次のファイルに変更が必要です。

obj.conf	ファイルの先頭に以下を追加します。 Init fn="load-modules" shlib="dtwnsapi.dll" funcs=dtw_nsapi
obj.conf	Service ディレクティブに追加します。 Service fn="dtw_nsapi" method=(GET\|HEAD\|POST) type="magnus-internal/d2w"
mime.types	このタイプを追加します。 type=magnum-internal/dtw exts=mac

Net.Data マクロ・ファイルを、netdata/macro から、サーバーのメイン文書ディレクトリーに移動します。
```
/netscape/server/docs/
```
初期設定ファイルで、MACRO_PATH を、ここで複写したNet.Data マクロを指すようにメイン文書ディレクトリーに変更します。これにより、どこでファイルを探すかを Net.Data に伝えます。
NSAPI は CGI 処理を迂回するので、 Net.Data に対する CGI 呼出しを持つ Web ページおよび Web マクロを変更しなければなりません。フォームおよびアンカー参照の URL の cgi-bin/db2www/ 部分を除去してください。ユーザーが Netscape 構成ファイルを変更したときにそのように定義したので、サーバーは、MAC サフィックスを持つファイルが Net.Data マクロであることを認識します。たとえば、この URL は、Net.Data を CGI プログラムとして起動する例です。
```
http://server1.stl.ibm.com/cgi-bin/db2www/test1.mac/report
```
この URL は、Net.Data を NSAPI アプリケーションとして使用します。
```
http://server1.stl.ibm.com/test1.mac/report
```

いくつかのディレクトリーに Net.Data マクロを保つ場合には、一部のステップが若干変わります。

ディレクトリーを、それらが含んでいる Net.Data マクロと一緒に、サーバーの文書ディレクトリーに移動します。
初期設定ファイルの MACRO_PATH 変数を更新します。
これらの Net.Data マクロを指すアンカー参照およびフォームを、それらのディレクトリー名は保ったまま、変更します。たとえば、この URL は、 /orders/ ディレクトリーに格納されている Net.Data マクロを呼び出します。
```
http://server1.stl.ibm.com/cgi-bin/db2www/orders/test1.mac/report
```
更新された URL は短くなりますが、ディレクトリー名は保たれます。
```
http://server1.stl.ibm.com/orders/test1.mac/report
```

[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]

1000	1010
1001	1011
1002	1012
1003	1013
1004	1014