この資料では、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) を提供するか否かによって異なります。
-
マルチスレッドの API を提供する Web サーバ (Microsoft Internet Information Services (IIS)、Personal Web Server (PWS)、Netscape Enterprise、FastTrack サーバなど) は、専用の WebLink ライブラリを使用して、Caché 環境に直接接続します。Microsoft 社の ISAPI (Internet Server Application Programming Interface) や NSAPI (Netscape Server Application Programming Interface) と動作する WebLink/CSP ライブラリが提供されています。
-
マルチスレッド API を提供しない Web サーバ (Apache など) は、WebLink/CSP ネットワーク・サービス・デーモン (NSD) 経由で Caché と通信します。NSD は、Caché 環境の接続を管理します。Web サーバは、NSD とスモール CGI (Common Gateway Interface) モジュール経由で通信します。また、Apache の場合は、Apache コアにコンパイルされるモジュール経由で通信します。マイクロソフトの ISAPI と Netscape の NSAPI の Web サーバも、NSD 経由で Caché と通信しますが、専用のソリューションを使用したほうが、よりよいパフォーマンスを得ることができます。WebLink/CSP CGI-NSD 接続オプションは、CGI インタフェースをサポートするあらゆる Web サーバと使用できます。NSD は、Web サーバのホスト・マシンで稼動する必要はありません。
WebLink (WL) および CSP の接続オプションは、以下の図の通りです。
CSP および WebLink の接続オプション
-
標準オペレーションを実行した後、IIS のユーザ要求およびサービスの処理速度が低下します。ホスト・オペレーティング・システムの全体的なパフォーマンスに低下が見られます。
-
しばらく低速で動作した後、完全に IIS の反応がなくなり、オペレーティング・システムのモニタは IIS が CPU 時間の 100% を消費していることを示します。
-
時々、オペレーティング・システムのイベント・ログに例外が記録される場合があります。記録されたログには、ISAPI 拡張のプロセス中に処理されなかった例外について記述されています。WebLink/CSP ISAPI が明示的に問題の原因であると示される場合もあります。その他の場合は、IIS 環境全体に重大な問題があるとエラーが記録されます。しかし、これらのケースを調査した結果、ほとんどの場合、このようなエラーは (再起動を開始するなどにより) 直接 Web サーバを復活させようとした際に発生しています。
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 つの可能性が考えられます。
-
不正なヒープ IIS 環境全体の中の不正なオペレーションは、IIS のプライマリ・ヒープに悪影響を及ぼす可能性があります。
-
シリアル化されていないヒープへのアクセス IIS は、マルチスレッド化された環境なので、プロセスのプライマリ・ヒープへのアクセスは、各スレッドからの要求についてシリアル化される必要があります。しかし、プログラム的にシリアル化を停止して、メモリに対する各要求のパフォーマンスを改善することができます。もちろん、IIS のような環境で上記を実行するのは信頼性の低い方法ですが、除外することはできません。このような操作は、同時に、また潜在的にプライマリ・ヒープの要求と衝突を引き起こし、最終的に不正なヒープにつながります。
-
ヒープの断片化 Web 要求はさまざまな形状およびサイズで入るため、Web サーバ環境内のメモリへの要求は、各呼び出しで要求されたメモリ容量に関しては非常に雑多になります。これに、Web サーバをできるだけ効率化しようとする業界の圧力が加わり、オペレーティング・システムのメモリ管理機能にかかる負担がさらに増加します。その結果、Web サーバのプライマリ・ヒープが断片化されてしまう可能性があります。断片化により、メモリ管理システムにさらに負担がかかり、原因不明のバグによるエラーが発生しやすくなります。
これらの可能性を考慮すると、エラーの原因は、オペレーティング・システムのメモリ管理機能の深い部分で、ヒープの断片化により発生した、あるいは悪化した原因不明の問題であると考えられます。
仮分析の結果、Caché ISAPI DLL のコアを書き直して、オペレーティング・システムのメモリ管理機能から圧力を取り除くことができます。以下のスキームが実装されています。
-
別のヒープの使用 Microsoft 製品では、モジュール (特に DLL) を使用して、独自のヒープの生成および管理ができます。これにより、ホスト・プロセス (IIS) のプライマリ・ヒープからのメモリの要求を削除する必要が完全になくなるため、プライマリ・ヒープ内で発生する問題を回避できます (完全に排除できるわけではありません)。負荷を削減した結果、プライマリ・ヒープの整合性は維持されます。
-
-
上記は、WebLink または CSP のパフォーマンスを低下させないように修正されました。実際、WebLink での初期段階のテストではパフォーマンスは向上しています。CSPでも、同様の修正が行なわれ、同様の改善が見られます。
要求ごとに使用するメモリ容量を大幅に削減するために、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 オペレーションにおいて重要な役割を果たし続けていくでしょう。インターシステムズ社は、堅調な実装を提供するために、全力を尽くします。