Web の制限 <webLimits>
概要
<webLimits>
要素には、TCP/IP 接続と帯域幅の制限を指定します。
ワーカー プロセスによって、60 秒ごとにアイドル状態である期間がチェックされます。 現在のアイドル時間が Windows Process Activation Service (WAS) によって指定されたアイドル タイムアウト値より大きい場合、ワーカー プロセスによってシャットダウンが開始されます。 dynamicIdleThreshold 属性にゼロ以外の値を指定すると、WAS により、使われる RAM の量に応じて、このアイドル タイムアウトが動的に短縮されます。
dynamicIdleThreshold 属性は、コミットされた物理 RAM の量を表します。 たとえば、サーバーに 2 ギガバイト (GB) の物理メモリがインストールされている場合に dynamicIdleThreshold 属性の値を 200 に設定すると、200% (4 GB) の物理 RAM が使用のためにコミットされます。 次の表によると、4 GB の 80% (つまり物理 RAM の 160% (3.2 GB)) が割り当てられると、WAS はすべてのワーカー プロセスのアイドル時間を 50% 短縮し始めます。
次の表は、dynamicIdleThreshold 値の定義済みのパーセンテージで発生するアイドル タイムアウトの短縮の一覧です。
Dynamic idle threshold percentage reached |
Dynamic idle time-out reduction |
---|---|
75 以下 | WAS は、元のアイドル タイムアウト設定を使用します。 |
80 | WAS は、アイドル タイムアウトが構成されているすべてのワーカー プロセスについて、アイドル タイムアウトを元の値の半分に設定します。 |
85 | WAS は、アイドル タイムアウトが構成されているすべてのワーカー プロセスについて、アイドル タイムアウトを元の値の 4 分の 1 に設定します。 |
90 | WAS は、アイドル タイムアウトが構成されているすべてのワーカー プロセスについて、アイドル タイムアウトを元の値の 8 分の 1 に設定します。 |
95 | WAS は、アイドル タイムアウトが構成されているすべてのワーカー プロセスについて、アイドル タイムアウトを元の値の 16 分の 1 に設定します。 |
100 | WAS は、アイドル タイムアウトが構成されているすべてのワーカー プロセスについて、アイドル タイムアウトを元の値の 32 分の 1 に設定します。 |
動的サイトのアクティブ化
動的サイトのアクティブ化は、IIS が Web サイトのアクティブ化を延期できるようにすることで、スケーラビリティの問題を解決するのに役立ちます。 Web サイト数が制限を超えると、IIS はサービスの開始時にどのサイトもアクティブ化しません。 IIS 8.0 以前で行われていたように、スタートアップ時に構成されたサイトごとにキューとバインディングは作成されません。 代わりに、すべてのサイトの要求をリッスンし、1 つのバインディングがある 1 つのキューが作成されます。 WAS により、サイト、そのバインディング、そのアプリケーション、そのアプリケーション プール、そのアプリケーション プール設定の一覧が読み込まれます。 サイトに対する要求が到着すると、IIS はその一覧を使ってキューを作成し、サイトのバインドを登録します。 その時点で、HTTP.sys は要求をキューに格納し、WAS はワーカー プロセスを開始し、要求は処理されます。
サイトを動的にアクティブ化すると、IIS サービスの起動が速くなり、メモリ消費量が少なくなる可能性があります。 また、IIS は、登録されているすべてのキューと HTTP のバインドを解放する必要がないため、再起動にかかる時間が大幅に短縮されます。 このコンテキストにおけるアクティブ化とは、IIS が HTTP プロトコル スタック (HTTP.sys) にサイトを登録するプロセスを指します。 このアクティブ化は、サイトに対する要求を受信したときにのみ発生するワーカー プロセスの作成とは異なります。
動的サイトのアクティブ化は、サーバーによって処理されるサイト数が事前に設定された制限を超えると有効になります。 既定では、この制限は 100 です。 この値を変更しない場合、100 を超えるサイトをホストするサーバー上では、サイトは動的にアクティブ化にされます。 一方、サイトが 100 以下の場合は、スタートアップ時にすべてのサイトがアクティブ化されます。 この制限は、dynamicRegistrationThreshold 属性を変更することで変更できます。 サイト数が少ないサーバーのパフォーマンスの向上は、サイト数が大幅に多い場合よりも小さくなることに注意してください。
Note
動的サイトのアクティブ化が有効な場合、ユーザーは IP アドレスを使って Web 要求を送信できません。 たとえば、ユーザーが HTTP://127.0.0.1 を参照しようとすると、400 Bad Request Error を受け取ります。
互換性
バージョン | メモ |
---|---|
IIS 10.0 | <webLimits> 要素は、IIS 10.0 では変更されませんでした。 |
IIS 8.5 | dynamicRegistrationThreshold 属性は IIS 8.5 で追加されました。 |
IIS 8.0 | <webLimits> 要素は IIS 8.0 では変更されませんでした。 |
IIS 7.5 | <webLimits> 要素は、IIS 7.5 では変更されませんでした。 |
IIS 7.0 | <webLimits> 要素が IIS 7.0 で導入されました。 |
IIS 6.0 | <webLimits> 要素は、次の IIS 6.0 メタベース設定を置き換えます。
|
段取り
<webLimits>
要素は IIS 7 以降の既定のインストールに含まれています。
操作方法
動的サイトアクティブ化の下限を構成する方法
インターネット インフォメーション サービス (IIS) マネージャーを開きます。
Windows Server 2012 R2 を使用している場合:
- タスク バーで、[サーバー マネージャー] をクリックし、[ツール]、[インターネット インフォメーション サービス (IIS) マネージャー] の順にクリックします。
Windows 8.1 を使用している場合:
- Windows キーを押しながら文字 X を押し、[コントロール パネル] をクリックします。
- [管理ツール] をクリックし、次に [インターネット インフォメーション サービス (IIS) マネージャー] をダブルクリックします。
[接続] ペインでサーバーを選んでから、[管理] 領域の [構成エディター] をダブルクリックします。
構成エディターの [セクション] で
system.applicationHost
を展開し、次に webLimits を選びます。dynamicRegistrationThreshold の値を入力します。
[操作] ペインで [適用] をクリックします。
構成
属性
属性 | 説明 |
---|---|
connectionTimeout |
省略可能な timeSpan 属性。 非アクティブであると見なされた接続を切断するまで IIS が待機する時間を指定します。 既定値は 00:02:00 です。 |
demandStartThreshold |
省略可能な uint 属性。 Web サーバー上で同時に実行できるワーカー プロセスの最大数を指定します。 このプロパティを使用すると、ワーカー プロセスが多すぎるときに IIS サーバーが応答しなくなるのを防ぐことができます。 既定値は 2147483647 です。 |
dynamicIdleThreshold |
省略可能な uint 属性。 コミットされた物理 RAM の割合を指定します。 有効な整数の範囲は 0 から 10000 です。 WAS は、このしきい値を使って、ワーカー プロセスのアイドル タイムアウトを動的に短縮します。 詳細については、「解説」を参照してください。 既定値は 0 です。 |
dynamicRegistrationThreshold |
省略可能な uint 属性。 動的サイト アクティブ化の下限を指定します。 サーバー上に構成されている Web サイト数がこの属性の値を超えると、サービスの開始時にすべてのサイトがアクティブ化されません。 代わりに、IIS がサイトの最初の要求を受信したときに、各サイトがアクティブ化されます。 構成されたサイト数がこの数以下の場合、サービスの開始時に構成されているすべての Web サイトがアクティブ化されます。 サイトを個別にアクティブ化すると、特にアクセス頻度が低いサイトが多数の場合、IIS で必要なシステム リソースの量が少なくなります。 サイトに対する最初の要求は、サイトがアクティブ化されるため、時間がかかりますが、後続のアクセスは正常に応答します。 既定値は 100 です。 |
headerWaitTimeout |
省略可能な timeSpan 属性。 サーバーが、クライアントを切断する前に、要求のすべての HTTP ヘッダーを受信するまで待機する時間を指定します。 この属性の目的は、接続制限を最大限に活用して接続を維持しようとするサービス拒否 (DoS) 攻撃の一般的なバリアントを防ぐことです。 既定値は 00:00:00 です。 |
maxGlobalBandWidth |
省略可能な uint 属性。 サーバーの最大合計帯域幅を指定します。 値を 0 に設定すると、サーバーの帯域幅は無制限になります。 既定値は 4294967295 です。 |
minBytesPerSecond |
省略可能な uint 属性。 HTTP.sys がクライアントに応答を送信するときに適用する最小スループット レートをバイト単位で指定します。 minBytesPerSecond 属性は、最小限のデータで接続を開いたままにすることで、悪意のあるソフトウェア クライアントや誤動作しているソフトウェア クライアントによるリソースの使用を防ぎます。 スループット レートが minBytesPerSecond 設定より低い場合、接続は終了します。 現在の実装では、最小帯域幅転送レートで接続中のクライアントに応答全体をストリーミングするのにかかる時間が経過した後にのみ、接続が終了します。 転送レートが短時間だけ minBytesPerSecond で指定された値を下回っても、全体の転送レートが高い場合、接続は終了されません。 既定値は 240 です。 |
子要素
なし。
構成サンプル
次の構成サンプルでは、接続タイムアウトを 1 分、コミットされた物理 RAM の割合を 150、ヘッダー待機タイムアウトを 30 秒、最小許容スループット レートを 500 バイト/秒に設定します。
<configuration>
<system.applicationHost>
<webLimits connectionTimeout="00:01:00"
dynamicIdleThreshold="150"
headerWaitTimeout="00:00:30"
minBytesPerSecond="500"
/>
</system.applicationHost>
</configuration>
サンプル コード
次のコード サンプルでは、接続タイムアウトを 1 分、コミットされた物理 RAM の割合を 150、ヘッダー待機タイムアウトを 30 秒、最小許容スループット レートを 500 バイト/秒に設定します。
AppCmd.exe
appcmd.exe set config -section:system.applicationHost/webLimits /connectionTimeout:"00:01:00" /commit:apphost
appcmd.exe set config -section:system.applicationHost/webLimits /dynamicIdleThreshold:"150" /commit:apphost
appcmd.exe set config -section:system.applicationHost/webLimits /headerWaitTimeout:"00:00:30" /commit:apphost
appcmd.exe set config -section:system.applicationHost/webLimits /minBytesPerSecond:"500" /commit:apphost
Note
AppCmd.exe を使用してこれらの設定を構成するときは、commit パラメーターを必ず apphost
に設定する必要があります。 これで、ApplicationHost.config ファイルの適切な場所セクションに構成設定がコミットされます。
C#
using System;
using System.Text;
using Microsoft.Web.Administration;
internal static class Sample
{
private static void Main()
{
using (ServerManager serverManager = new ServerManager())
{
Configuration config = serverManager.GetApplicationHostConfiguration();
ConfigurationSection webLimitsSection = config.GetSection("system.applicationHost/webLimits");
webLimitsSection["connectionTimeout"] = TimeSpan.Parse("00:01:00");
webLimitsSection["dynamicIdleThreshold"] = 150;
webLimitsSection["headerWaitTimeout"] = TimeSpan.Parse("00:00:30");
webLimitsSection["minBytesPerSecond"] = 500;
serverManager.CommitChanges();
}
}
}
VB.NET
Imports System
Imports System.Text
Imports Microsoft.Web.Administration
Module Sample
Sub Main()
Dim serverManager As ServerManager = New ServerManager
Dim config As Configuration = serverManager.GetApplicationHostConfiguration
Dim webLimitsSection As ConfigurationSection = config.GetSection("system.applicationHost/webLimits")
webLimitsSection("connectionTimeout") = TimeSpan.Parse("00:01:00")
webLimitsSection("dynamicIdleThreshold") = 150
webLimitsSection("headerWaitTimeout") = TimeSpan.Parse("00:00:30")
webLimitsSection("minBytesPerSecond") = 500
serverManager.CommitChanges()
End Sub
End Module
JavaScript
var adminManager = new ActiveXObject('Microsoft.ApplicationHost.WritableAdminManager');
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST";
var webLimitsSection = adminManager.GetAdminSection("system.applicationHost/webLimits", "MACHINE/WEBROOT/APPHOST");
webLimitsSection.Properties.Item("connectionTimeout").Value = "00:01:00";
webLimitsSection.Properties.Item("dynamicIdleThreshold").Value = 150;
webLimitsSection.Properties.Item("headerWaitTimeout").Value = "00:00:30";
webLimitsSection.Properties.Item("minBytesPerSecond").Value = 500;
adminManager.CommitChanges();
VBScript
Set adminManager = WScript.CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST"
Set webLimitsSection = adminManager.GetAdminSection("system.applicationHost/webLimits", "MACHINE/WEBROOT/APPHOST")
webLimitsSection.Properties.Item("connectionTimeout").Value = "00:01:00"
webLimitsSection.Properties.Item("dynamicIdleThreshold").Value = 150
webLimitsSection.Properties.Item("headerWaitTimeout").Value = "00:00:30"
webLimitsSection.Properties.Item("minBytesPerSecond").Value = 500
adminManager.CommitChanges()