この資料では、Caché WebLink および CSP テクノロジーの問題点について説明しています。IIS/ISAPI (Internet Information Services/Internet Server application programming interface) の両方の製品で、接続オプションに問題があることが明らかになりました。分析結果と推測上の分析をあわせて記載しています。また、WebLink および CSP ソフトウェアでの改善措置についても説明しています。
この資料には、以下のセクションが含まれます。
テクノロジー概要
WebLink と CSP は、主要な Web サーバと Caché (アプリケーション開発環境とデータベース・サーバ機能) の接続を提供するソフトウェア製品です。
WebLink と CSP は、Web サーバを Caché に接続するために 2 つのメソッドを実装しています。どちらのメソッドを選択するかは、ホストの Web サーバがマルチスレッドのアプリケーション・プログラミング・インタフェース (API) を提供するか否かによって異なります。
WebLink (WL) および CSP の接続オプションは、以下の図の通りです。
CSP および WebLink の接続オプション
問題の説明
以下のような問題が発生します。
IIS を再開することにより Web サーバ環境を回復させることができる場合もあるようですが、完全にホスト・サーバを再起動する必要がある場合もよくあります。このような処理は、通常業務の妨げになってしまいます。
現在、インターシステムズ社のサポート・スタッフが努力しておりますが、残念ながら、テスト段階でこの問題を再現することができません。おそらく、Web ブラウザから Caché に大量のデータを書き込むことが、パフォーマンスの悪化の要因であると考えられます。実質的に Web サーバを使用していない場合でも問題が発生するので、Web サーバやアプリケーションの負荷は要因ではないようです。
調査と分析
原因を解明するために、まずオペレーティング・システムのイベント・ログに記録されたエラーのソースを特定することから始めました。エラーが Caché ISAPI DLL の機械的な欠陥から発生するものであるなら、簡単かつ迅速に解決できます。
WebLink と CSP は両方とも組み込みの例外処理を備えています。これらは、偽の Web (HTTP) 要求や変質した Web (HTTP) 要求の処理および対応を行ないます。実際、Caché ISAPI DLL は、異例ではあるけれど有効な HTTP 要求の処理に、潜在的に失敗することはあり得ることです。
このエラーを分析するために、複雑さや各関数が実行する演算の質に関わらず、DLL 内の各関数に厳密な例外処理を追加します。DLL のコンテキスト内で発生した例外は、うまくトラップされ記録できますが、オペレーティング・システムのイベント・ログに例外が現れるというケースもあります。このことから、このエラーは IIS とその ISAPI 拡張の間に共通のリソースに関与していることが分りました。
さらに詳細な調査により、プロセスのプライマリ・ヒープからメモリを要求した結果、例外が発生したことが分りました。メモリの割り当てを担うオペレーティング・システム関数 (具体的には HeapAlloc) が、内部的にエラーを起こしていました。この原因としては、主に以下の 3 つの可能性が考えられます。
これらの可能性を考慮すると、エラーの原因は、オペレーティング・システムのメモリ管理機能の深い部分で、ヒープの断片化により発生した、あるいは悪化した原因不明の問題であると考えられます。
改善措置
仮分析の結果、Caché ISAPI DLL のコアを書き直して、オペレーティング・システムのメモリ管理機能から圧力を取り除くことができます。以下のスキームが実装されています。
上記は、WebLink または CSP のパフォーマンスを低下させないように修正されました。実際、WebLink での初期段階のテストではパフォーマンスは向上しています。CSPでも、同様の修正が行なわれ、同様の改善が見られます。
WebLink ユーザへの注意事項
要求ごとに使用するメモリ容量を大幅に削減するために、WebLink は中間バッファを最小限に抑えて、Web サーバからの出力を、直接適切な Caché システムにストリーミングしようとします。これを行なうには、WebLink は大量の要求データを読み込まずに、できるだけ早く要求の送信先を知る必要があります。従来は、“MGW” (特に MGWLPN および MGWCHD) の接頭語を付けたフォーム/URI の予約変数を使用して、ターゲットの Caché サーバを指定していました。
HTTP GET メソッド (ハイパーリンク) に対する変数は、URI クエリ文字列の中にあります。完全なクエリ文字列は、理想的には常にホスト Web サーバ環境で利用できます。以下はその例です。
<A HREF="/scripts/mgwms32.dll?MGWLPN=LOCAL&formID=3">
HTTP POST メソッド (完全なフォームの送信) に対する変数は、フォームの “ACTION” 属性で指定された URI に送信されます。以下はその例です。
<FORM METHOD=POST ACTION="/scripts/mgwms32.dll?MGWLPN=LOCAL&formID=3">
Web サーバ環境で完全なクエリ文字列が常に利用できるため、これは理想的です。ターゲットの Caché システムは、Web サーバが受信したフォームのデータ・ストリームを読む前に決定されます。しかし、この技術は Opera Web ブラウザでは利用できない点に注意してください。Opera Web ブラウザは、“ACTION” 属性内の URI に付加されたクエリ文字列の送信に失敗します。
HTTP POST に対する別の方法として、フォームのデータ内の非表示フィールドとして MGW* 変数を含むという方法があります。以下はその例です。
<HTML>
<HEAD><TITLE>My Form</TITLE></HEAD>
<BODY>
<FORM METHOD=POST ACTION="/scripts/mgwms32.dll">
<INPUT TYPE=HIDDEN NAME="MGWLPN" VALUE="LOCAL">
.
.
.
</FORM>
</BODY>
</HTML>
変数がフォームの先頭に配置されている場合は、上記が成功します。WebLink は、受信フォームのデータの一部を読み込むだけで、ターゲットの Caché システムを決定することができます。
しかし、これらの変数がフォームの最後部に配置されている場合 (以下の例参照)、WebLink はターゲットの Caché システムを識別するのに、データ・ストリームをすべて読み込みバッファしなければなりません。
<HTML>
<HEAD><TITLE>My Form</TITLE></HEAD>
<BODY>
<FORM METHOD=POST ACTION="/scripts/mgwms32.dll">
.
.
.
<INPUT TYPE=HIDDEN NAME="MGWLPN" VALUE="LOCAL">
</FORM>
</BODY>
</HTML>
上記では、使用するメモリをできる限り少なくする対策を取っているので、常にフォームの先頭に MGW* 変数を配置する方がずっと効率的です。
実際、WebLink は、要求に対処する最適な方法として使用する場合は、データ・ストリーム内で MGW* 変数が最初に来ることを予期しています。最初の非 MGW* 変数を読み込むとすぐに、Caché に対し、受信したフォーム・データのストリーミングを直接開始します。しかし、これによりプロトコル内の不明確な点が明らかになります。
WebLink がデータの最初のセクションで MGW* 変数をひとつも読み込んでいない場合は、MGW* 変数が指定されているかどうか (この場合、既定の Caché サーバが示されます)、または MGW* 変数が送信の最後に本当にあるかどうかを判断する方法がありません。WebLink アプリケーションの多くは、MGW* 変数を指定せず、構成内に保持されている既定の設定に依存しています。これらのアプリケーションが、最適なメモリ/要求管理スキームの利点を利用するために、Optimise_Memory_Usage (TRUE または FALSE) という新しい構成パラメータが導入されました。
このパラメータが FALSE に設定されている場合 (既定)、WebLink は、クエリ文字列または受信したデータ・ストリームの先頭部分で MGW* 変数を読み込めなかった場合に、全要求データをバッファします。これにより、MGW* 変数をフォームの最後に指定することができます。
このパラメータが TRUE に設定されており、WebLink がクエリ文字列または受信したデータ・ストリームの先頭部分で MGW* 変数を読み込めない場合、既定の Caché サーバを使用するとみなします。インターシステムズは、このオペレーション・モードを強くお勧めしていますが、これはご使用のアプリケーションが MGW* 変数の配置に関する要件を満たす場合に限ります。WebLink Developer を使用して開発されたアプリケーションは、常にフォームの先頭部分に MGW* 変数を配置するため、このオペレーション・モードを安全に利用できます。
受信したデータ・ストリームの最後部を受けとった後も MGW* 変数が処理されない場合は、WebLink のイベント・ログに警告が書き込まれます。以下はその例です。
>>> Fri Sep 07 15:46:13 2001; Thread ID: 182

WARNING: Reserved Variable 'MGWLPN' was not processed because it was not found amongst the first fields in the submitted data.

/scripts/mgwms32.dll?FormID=1
Note:
このセクションの情報は、PDQWeb 互換モードで動作している WebLink にも適用されます。WebLink の MGW* 変数に対し、PDQWeb モードでは重要な予約変数は EP です。
まとめ
フィールドのテストを実行するようにしてください。新しい DLL を使用すると、エラーは報告されていません。
このドキュメントに記載されているソフトウェアの変更は、弊社の DLL およびオペレーティング・システムにより生成されたイベント・ログおよび状況分析に基づいています。正確な分析を行なうことが理想ですが、テスト状況下では同じエラーを再現することができないため、これは不可能です。同様の理由で、Microsoft から修正方法や回避方法を得ることもできません。Microsoft も、再現できる問題にしか対処できないためです。
インターシステムズ社は、長期的には代替の接続オプション、すなわち テクノロジー概要 のセクションの図にある NSD ベースのオプションを提供する予定です。これらのオプションの主な特徴は、WebLink/CSP のコアの機能が Web サーバ環境から切り離された点です。これ自体が、ISAPI などのオープン・インタフェースに関するリスクを削減し、高性能の Web オペレーションに対し、さらに安定した操作しやすいプラットフォームを提供します。しかし、一体型の ISAPI 接続ソリューションも、小~中規模の Web オペレーションにおいて重要な役割を果たし続けていくでしょう。インターシステムズ社は、堅調な実装を提供するために、全力を尽くします。