Skip to main content

Microsoft インターネット･インフォメーション･サービス Web サーバ の考慮事項 (Windows)

ここでは、InterSystems Web ゲートウェイを Microsoft インターネット･インフォメーション･サービス (IIS) Web サーバと共に導入する際に考慮すべき、技術的な詳細について補足説明します。IIS の管理の詳細は、IIS のドキュメント (https://learn.microsoft.com/ja-jp/iis/get-started/introduction-to-iis/iis-web-server-overviewOpens in a new tab) を参照してください。

IIS の再起動

Web ゲートウェイの構成に対する変更を有効にするには、IIS を再起動する必要があります。この場合、インターネット・サービス・マネージャのコントロール・パネルではなく、メインの Windows サービスのコントロール・パネルまたは Windows のコマンド行から World Wide Web Publishing サービス全体を再起動する必要があります。"IIS の再起動" を参照してください。

IIS ワーカ・プロセスと Web ゲートウェイ

推奨される Web ゲートウェイ導入方法 (ネイティブ・モジュール CSPms.dll と CSPmsSys.dll を使用) では、永続リソース (InterSystems IRIS インスタンスへの接続など) を Web サーバ拡張自体の中で管理します。(これに対し、NSD ベースの Web ゲートウェイ導入では、リソースを IIS からは独立して、NSD 自体の中で管理します。)

このため、Web ゲートウェイ・ネイティブ・モジュール拡張のパフォーマンスは、IIS ワーカ・プロセスがアプリケーションの要求をどのように処理するかを決定する、次の IIS 構成アイテムに影響されます。

アプリケーション・プール

1 つ以上の IIS アプリケーションの要求を処理するために割り当てることのできる、IIS 内の指定された 1 つ以上のワーカ・プロセスのセット。

Web ガーデン

複数のワーカ・プロセスを含む IIS アプリケーション・プール。要求は、Web ガーデンでワーカ・プロセス間に分散されます。

各ワーカ・プロセスは、Web ゲートウェイ拡張のそれぞれのインスタンスを管理します。使用するワーカ・プロセスを 1 つのみとするように構成したアプリケーション・プールの場合、単一の Web アプリケーション・パス (/csp など) のコンテキスト内における Web ゲートウェイの動作に対して目に見える影響を及ぼしませんただし、Web ガーデン内では、要求は関係するワーカ・プロセスで管理される Web ゲートウェイ・インスタンス間で均等に分散されます。

このため、いくつかの制限事項に留意する必要があります。

Web ゲートウェイのシステム・ステータス

Web ゲートウェイのシステム・ステータス管理ページでは、Web ガーデン全体で Web アプリケーションが使用する接続を正確に監視できません。システム・ステータス・ページには、現在のワーカ・プロセス (つまり、Web ゲートウェイの要求を処理するワーカ・プロセス) にアタッチされている、Web ゲートウェイのインスタンスのステータスが、指定されたどの時点でも反映されています。

最小および最大接続数

各ワーカ・プロセスは Web ゲートウェイ・アプリケーションの独自のインスタンスを管理するため、InterSystems IRIS アプリケーション・サーバへの永続接続の独自のプールを維持します。InterSystems IRIS 接続の最小数と最大数を指定する Web ゲートウェイ構成パラメータは、アプリケーション・プール全体での総計としてはこれらの限度を指定しません。これらのパラメータが定義するのは、各ワーカ・プロセスの Web ゲートウェイ・インスタンスに許可される最小および最大接続数です。

ワーカ・プロセスのタイムアウトとワーカ・プロセスのリサイクル

アプリケーション・プール内のワーカ・プロセスを、定期的にリサイクルしたり、指定したアイドル時間の経過後に終了するよう構成できます。

アプリケーション・プール内のワーカ・プロセスが終了すると、プロセスが管理する Web ゲートウェイのインスタンスも終了し、Web ゲートウェイ・インスタンスが InterSystems IRIS で維持していた接続のプールも閉じられます。こうした状況では、ステートレス接続を Web アプリケーションのユーザに透過的な方法で置き換えることができます。ただし、ステート認識セッション (保持モード 1) は、ホスト接続が閉じられると終了します。

ビットネス ： 64 ビット・サーバでの 32 ビット・アプリケーションの実行

Note:

このセクションは、ホスト Web サーバのアドレス空間にロードされるモジュール、つまりネイティブ・モジュール (CSPms[Sys].dll と CSPcms.dll) および ISAPI 拡張に適用されます。CGI モジュールは、IIS から分離されたプロセスとして動作するため、影響を受けません。

IIS では、特定のアプリケーション・プールに対してビットネス (64 ビットまたは 32 ビット) を設定できます。単一の IIS インストールで、ネイティブ 64 ビット・アプリケーションに対応するアプリケーション・プールと、32 ビット・アプリケーションに対応する別のアプリケーション・プールを共存させることができます。[32 ビット アプリケーションの有効化] 設定を使用するには、IIS マネージャでアプリケーション・プールの [詳細設定] にアクセスします。

アプリケーション・プールがロードするネイティブ・モジュールまたは ISAPI 拡張は、アプリケーション・プールのビットネスと一致している必要があります。 例えば、ホストのアプリケーション・プールが 64 ビットの場合は、64 ビットのゲートウェイ・モジュール (CSPms[Sys].dll など) を使用する必要があります。 ホストのアプリケーション・プールが 32 ビットの場合は、32 ビットのゲートウェイ・モジュールを使用する必要があります。

個々のモジュールのビットネス・チェックは、モジュールの web.config ファイルの preCondition を通して行われます。 Web ゲートウェイの場合、このファイルは通常、次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="WebGateway_All" path="*" verb="*" modules="CSPms" resourceType="Unspecified" \
             preCondition="bitness64" />
        </handlers>
        <security>
            <requestFiltering>
                <hiddenSegments>
                    <remove segment="bin" />
                </hiddenSegments>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

precondition 節のビットネス設定に注意してください。 ここでは、ビットネスは bitness64 に設定されています。これは、IIS が、64 ビット・アプリケーション・プールで動作する 64 ビット・ゲートウェイ・モジュールをチェックすることを意味します。

32 ビット・アプリケーション・プールが使用されている場合は、32 ビット・ゲートウェイ・モジュールを使用し、preCondition を bitness32 に設定する必要があります。

インストールされたモジュール、precondition 節、またはホストのアプリケーション・プールが予期するものの間に不整合がある場合、IIS はエラーを返します。

FeedbackOpens in a new tab