管理コンソールで HTTP リスナー設定を変更するには、「設定」>「config-name」>「HTTP サービス」>「HTTP リスナー」>「listener-name」を選択します。
ネットワークインタフェースカード (NIC) が 1 枚だけ装備されたマシンでは、ネットワークアドレスをそのマシンの IP アドレス (デフォルトの 0.0.0.0 ではなく 192.18.80.23 など) に設定してください。0.0.0.0 以外の IP アドレスを指定すると、サーバーが接続ごとに行うシステムコールの数が、1 つだけ少なくなります。実現可能な最高のパフォーマンスが得られるよう、0.0.0.0 以外の IP アドレスを指定してください。サーバーに複数の NIC カードが搭載されている場合には、NIC ごとに異なるリスナーを作成してください。
「アクセプタスレッド」設定は、1 つの待機ソケット上で常にいくつのスレッドを受け付けモードにしておく必要があるかを指定します。システムの CPU 数に等しいかそれより小さい値にこれを設定するのは、良い方法です。
Application Server では、HTTP リスナー上のアクセプタスレッドが接続を受け付け、それらを接続キューに入れます。次に、セッションスレッドがキューから接続を取り出し、その要求を処理します。サーバーは、要求の終了時に必要に応じてセッションスレッドを追加します。
新しいスレッドの追加ポリシーは、接続キューの状態に基づいています。
新しい接続が返されるたびに、キュー内で待機している接続の数 (接続のバックログ) が、すでに作成されたセッションスレッドの数と比較されます。その数がスレッド数よりも大きい場合、次回の要求完了時にスレッドを追加するスケジュールが作成されます。
直前のバックログが追跡され、次のいずれかが真になるまで n 個のスレッドが追加されます (n は「HTTP サービス」の「スレッドの増分」パラメータ)。
スレッド数が時間とともに増加する。
増分が n より大きい。
セッションスレッド数からバックログを引いたものが、n より小さい。
ベンチマーク負荷の開始時など、バックログが急激に増加する際にスレッドを作成しすぎないように、サーバーは、スレッドを追加する必要があるかどうかの判断を、すでに存在しているセッションスレッドの数に基づいて、16 個または 32 個の接続ごとに一度だけ下します。
Grizzly は Java の NIO テクノロジを利用した HTTP リスナーであり、そのすべてが Java で実装されています。この再利用可能な NIO ベースのフレームワークを使えば、任意の HTTP 関連操作 (HTTP リスナー/コネクタ) だけでなく非 HTTP 操作も行えるため、スケーラビリティーの高い任意のタイプのマルチスレッドサーバーを作成できます。Grizzly HTTP リスナーは Java プラットフォームの NIO Selector クラス群に基づくキープアライブシステムを使用しますが、このクラス群は接続の監視をサポートしており、サービス拒否攻撃を防ぐのに役立ちます。サービス拒否システムは、リソースの枯渇または「氾濫」攻撃を予測できるよう、IP 検証、IP ごとの完了トランザクション数の追跡、アクティブでない接続の検出などに対する基本的なサポートを追加します。これらすべてのサービスが、キープアライブシステムと組み合わせて実行されます。Grizzly コネクタは静的リソース要求と動的リソース要求の両方をサーブレットコンテナに転送し、サーブレットコンテナはコンテナによって提供される専用のサーブレット (org.apache.catalina.servlets.DefaultServlet) を使って静的リソース要求を処理します。
Grizzly の詳細については、http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html の Weblog を参照してください。
Grizzly は、Application Server Enterprise Edition 8.2 に含まれる NSAPI/WebCore の代替として利用可能になっています。Application Server には、Grizzly の設定をサポートするための特殊なプロパティーがいくつか用意されています。Grizzly を有効にするには、次のプロパティーを追加します。
Dcom.sun.enterprise.web.httpservice.ee=false。
Grizzly の実装は現在のところ、Application Server Enterprise Edition の、動的設定以外のすべての機能をサポートしています。
Grizzly の設定を制御するプロパティーは、次のとおりです。
-Dcom.sun.enterprise.web.connector.grizzly.keepAliveTimeoutInSeconds=30
-Dcom.sun.enterprise.web.connector.grizzly.maxHttpHeaderSize=4096
-Dcom.sun.enterprise.web.connector.grizzly.ssBackLog=4096
-Dcom.sun.enterprise.web.connector.grizzly.queueSizeInBytes=-1
-Dcom.sun.enterprise.web.connector.grizzly.maxKeepAliveRequests=250
-Dcom.sun.enterprise.web.connector.grizzly.fileCache.isEnabled=false
-Dcom.sun.enterprise.web.connector.grizzly.fileCache.maxEntrySize=1024
-Dcom.sun.enterprise.web.connector.grizzly.fileCache.maxLargeFileCacheSize= 10485760
Grizzly も、Sun Java System Application Server 8.2 のその他のすべての設定と同じく、非同期起動メカニズムを無効にするとパフォーマンスが向上します。これを無効にするには次のプロパティーを使用します。-Dcom.sun.enterprise.server.ss.ASQuickStartup=false
次の表に、Grizzly プロパティーと production web container (PWC) プロパティーとの対応関係を示します。
表 3–3 Grizzly プロパティーと PWC プロパティーとの対応関係
Grizzly のプロパティー名 |
デフォルト値 |
説明 |
本番 Web コンテナの対応する設定 |
---|---|---|---|
maxAcceptWorkerThread |
0 |
OP_ACCEPT (socket.accept()) の処理に使用されるスレッドの数。 |
HTTP リスナーのアクセプタスレッドの数 |
selector.timeout |
60000 |
Selector.select() でタイムアウトが発生するまでの、ミリ秒単位の時間。 |
要求処理タイムアウト |
minWorkerThreads |
5 |
すべてのスレッドプールが作成時に使用する最小スレッド数。 |
要求処理の初期スレッド数 |
fileCache.isEnabled |
false |
ファイルキャッシュが有効かどうかを示します。 |
ファイルキャッシュが有効 |
fileCache.minEntrySize |
小ファイルで可能な最小サイズ。 |
小ファイルのサイズ制限 |
|
fileCache.maxEntrySize |
1024 |
中ファイルで可能な最大サイズ。 |
中ファイルのサイズ制限 |
fileCache.maxLargeFileCacheSize |
10485760 |
中ファイル用のキャッシュ領域。 |
ファイルサイズ (中) |
fileCache.maxSmallFileCacheSize |
小ファイル用のキャッシュ領域。 |
ファイルサイズ (小) |
|
fileCache.maxCacheEntries |
キャッシュエントリの最大数。 |
最大ファイル数 |
|
keepAliveTimeoutInSeconds |
30 |
キープアライブのタイムアウト |
|
maxKeepAliveRequests |
250 |
キープアライブの最大接続数 |
|
InitialRuleCount |
128 |
Keep-Alive サブシステムによって作成される KeepAliveRule の初期数。 | |
useNioNonBlocking |
true |
NIO ブロックモードを使用するかどうかを示します。 | |
displayConfiguration |
false |
Grizzly の内部設定を表示するかどうかを示します。 | |
useDirectByteBuffer |
true |
Grizzly バッファーの作成時に ByteBuffer.allocateDirect() を使用するかどうかを示します。 | |
pipelineClass |
com.sun.enterprise.web.connector.grizzly.LinkedListPipeline |
Grizzly がデフォルトで使用するパイプライン (スレッドプールラッパー)。 | |
maxSelectorReadThread |
1 |
OP_READ 操作を処理するためのセレクタスレッドの数。 | |
useByteBufferView |
false |
1 つの大きな ByteBuffer を使用し、それを Grizzly バッファー間で分割するかどうかを指定します。 | |
algorithmClassName |
com.sun.enterprise.web.connector.grizzly.algorithms.NoParsingAlgorithm |
ByteBuffer からのバイトの読み取りに使用される、要求バイト解析アルゴリズム。 | |
buffersize |
4096 |
Grizzly によって作成される ByteBuffer のサイズ。 | |
factoryTimeout |
30 |
ソケット上での読み書き操作が失敗するまでの時間。 | |
maxReadWorkerThread |
0 |
ソケットからの要求バイトの読み取りに使用されるスレッドの数。 |