IIS Insider

ISA サーバーの機能の 1 つに、リバース プロキシ サーバーとして機能できることがあります。クライアントが ISA に接続し、次に、この ISA は IIS サーバーからのコンテンツを取得し、キャッシュします。クライアントは ISA サーバーに直接的な接続を持たないため、セキュリティは向上します。ISA が IIS サーバーに接続する時にみられるように、IIS サーバーは IIS ログの ISA サーバーの IP アドレスを記録します。このため、この追加のセキュリティの代償として、IIS サーバーに接続する様々なクライアントを追跡する機能が失われます。この理由は、これらのクライアントは実際に IIS サーバーに接続しないためです。

この現在の構成で、ISA に IP アドレスをパス スルーさせる方法はありません。しかし、同じ情報のほとんどについて、ISA サーバーのログを分析することはできます。IIS 6 リソース キットの Log Parser Tool をご覧になり、また、2004 年夏にリリース予定となっている Log Parser 2.2 をお待ちになることを推奨します。Log Parser Tool を使用して、迅速に ISA ログを IISW3C ログ ファイルにフォーマットする、またはそれらを分析のために SQL サーバーにエクスポートすることができます。ISA 2000 から ISA Server 2004 にアップグレードする場合、https://www.microsoft.com/isaserver/prodinfo/previousversions/2004.mspx (英語) により、クライアントの IP アドレスのパス スルーを有効にすることができます。

これは、IIS および IIS が配布するアプリケーション (この場合、.asp) の対話を強調する重要な質問です。主に、開発者に焦点があてられた質問ですが、管理者に対するインパクトもあります。この理由は、メモリ消費を管理しないアプリケーションは、サーバーのすべてのアプリケーションのパフォーマンスを妨げる可能性があるためです。このため、IIS 管理者は、アプリケーションが IIS 上で信頼性があり、またセキュアに実行されるためにどのように書かれれば最善であるかについて、管理者とよりよく話し合いができるように、プログラミングの詳細を学ぶことを推奨します。

Asp およびそのほかのプログラミング言語では、レコードセットは、データベース クエリの結果を保持するためプログラムで使用される構成です。たとえば、asp スクリプトで、ユーザーが企業のすべての顧客を表示できる検索ページを持っているとします。ユーザーは Web アプリケーションにより提示されたフォームに記入し、コロラドにおける先月取引があったすべての顧客をレビューすることを依頼します。Asp アプリケーションはそのクエリを SQL サーバーに送り、その SQL サーバーは次に asp アプリケーションにその結果を返します。

ASP の内部では、結果はレコードのセット (すなわち recordset) に保存されており、これはプログラムがミニ データベースのように操作することができます。IIS 管理者の視点から、主にレコードセットのサイズ、レコードセットがメモリに存在する期間およびメモリに存在するレコードセットの数が懸念されます。

引き続き例を挙げると、クエリが名前、住所、購入品、販売担当者を含む 100 件の顧客の一覧を返した場合、レコードセットをホストするための IIS サーバーでのメモリ要件について心配することはないでしょう。しかし、同じクエリが米国内のすべての顧客について行われ、そのレコードセットが 100,000 ものメンバーを持つ場合、話はまったく違ってきます。

レコードセットはメモリの大部分を消費する可能性があるため、サーバーに負荷をかけ過ぎず、レコードセットが使用されていない場合、それを開放する信頼できるクエリをデザインすることはプログラマ次第です。

一般的に、レコードセットを作成するために使用されるページがスコープ外になる (asp ページが完全に解析される) 場合、そのレコードセットは破棄されます。もう使用されていないレコードセットが破棄される前に、このイベントの発生を待つことはよいと考えられていません。

いくつかの asp ページは非常に長いため、終了しない場合もあります。この結果として、そのページ内のすべてのクエリはページが実行されている長い間、メモリにとどまります。これは、同じページを実行している複数のユーザーにより起こり、これにより、レコードセットが開放されない結果、利用可能なメモリ量が使い果たされる可能性があります。別の状況として、ユーザーが単にそのページから一定の時間離れない場合もあります。最終的に、タイムアウトがメモリからページを開放しますが、なぜ、アプリケーションのメモリ管理をユーザーの習慣に任せておくのでしょうか?

これらの理由により、レコードセットを明示的に破棄する規則はレコードセットに Nothing を設定することです。(これは開発者以外には不思議に感じられると思いますが、事実です。) これを行わないと、メモリが効果的に使用されないという状況が発生する場合があります。

データの取得と関連して効果的なプログラミングについて知るべきことが多くあり、またこれらの詳細への注意を怠ると、IIS サーバーのパフォーマンスが影響を受ける可能性があります。実際、インターネットで “efficient ADO” と検索すると、多くの資料が結果として出てきます。

IIS 4 で htm を asp.dll にマップする技術があります。この技術を IIS 4 で使用すると .htm ファイルにスクリプトが記述されていなくてもスクリプトであるかのように実行されてしまう問題がありました。これは、IIS 5 の “scriptless asp” という機能で修正されました。IIS 5 では、ファイルに実際にスクリプトが含まれているかどうかがチェックされ、含まれていない場合は、ファイルは実行されることなく送信されます。

.htm (および使用を予定しているそのほかの拡張子) を aspnet_isapi.dll にマップすることにより、asp.net にも同じ操作ができます。さらに、web.config ファイルを変更し、その拡張子の http ハンドラを定義する必要があります。このプロセスのステップ バイ ステップの説明は https://support.microsoft.com/default.aspx?scid=kb;ja;815172&sd=tech をご覧下さい。