test

Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド

HTTP サービスの設定

クライアント要求を処理する HTTP サーバーインスタンスの監視とチューニングは、Application Server のピーク時のパフォーマンスを確保するうえで重要となります。

HTTP サービスの監視

HTTP サービスの監視統計を有効にするには、管理コンソール、asadmin のいずれかを使用します。管理コンソールの場合、監視レベル (「低」または「高」) は HTTP サービスの監視に何の効果も持ちません。

asadmin の場合、利用可能な監視パラメータを一覧表示するには、次のコマンドを使用します。

list --user admin --port 4848
 -m server-instance-name.http-service.*

ここで、server-instance-name はサーバーインスタンスの名前です。

値を取得するには、次のコマンドを使用します。

get --user admin --port 4848 -m server.http-service.parameter-name.*

ここで、parameter-name は監視するパラメータの名前です。

統計の収集はデフォルトで有効になっています。これを無効にするには、次のプロパティーを domain.xml に追加し、サーバーを再起動します。

<property name="statsProfilingEnabled" value="false" />

統計の収集を無効にするとパフォーマンスが向上します。

管理コンソールでも監視統計を表示できます。この情報は次のカテゴリに分けられます。

一般的な HTTP 統計 (http-service)

管理コンソールが提供するパフォーマンス関連の HTTP 統計は、次のとおりです。

DNS キャッシュ情報 (dns)

DNS キャッシュでは、IP アドレスと DNS 名がキャッシュされます。サーバーの DNS キャッシュはデフォルトで無効になっています。Web ベースの管理インタフェースの「監視」の下にある「プロセス ID すべての DNS 統計」ページでは、次の統計が表示されます。

Enabled

DNS キャッシュが無効になっていると、この節の残りの部分は表示されません。

デフォルトで、DNS キャッシュは無効になっています。管理コンソールで DNS キャッシュを有効にするには、DNS の値を「サーバーにアクセスするクライアントに対して DNS 検索を実行する」に設定します。

CacheEntries (CurrentCacheEntries / MaxCacheEntries)

キャッシュエントリの現在の数と最大数。単一のキャッシュエントリは、単一の IP アドレスまたは単一の DNS 名の検索を表します。キャッシュのサイズは、Web サイトに同時にアクセスするクライアントの最大数を格納できるだけの大きさにしてください。キャッシュサイズの設定値が大きすぎるとメモリーが無駄に消費され、パフォーマンスが劣化します。

DNS キャッシュの最大サイズを設定するには、「パフォーマンスチューニング」ページの「DNS キャッシュのサイズ」フィールドの値を入力または変更します。

HitRatio

ヒット率は、キャッシュヒット数をキャッシュ検索数で割ったものです。

この設定はチューニング不可能です。

注 –

サーバー上で DNS 検索を無効にすると、ホスト名の制限が正常に機能しなくなるほか、ログファイル内でホスト名の代わりに IP アドレスが表示されます。

DNS エントリのキャッシュへの書き込み

DNS エントリをキャッシュに書き込むかどうかを指定することもできます。DNS キャッシュが有効になっていると、サーバーは、ホスト名の情報を受信したあと、その情報を格納することができます。その後、サーバー上でそのクライアントの情報が必要になった場合、その情報はキャッシュ内に存在しているため、再度クエリーを実行しなくてもその情報を利用できます。DNS キャッシュのサイズと DNS キャッシュエントリの有効期間を指定します。DNS キャッシュには 32 件から 32768 件までのエントリを格納できます。デフォルト値は 1024 です。キャッシュエントリが期限切れになるまでの時間の値は、1 秒から 1 年までの範囲で秒単位で指定できます。デフォルト値は 1200 秒 (20 分) です。

DNS 検索を非同期に制限する

DNS 検索はリソース集約型であるため、サーバープロセス内では使用しないでください。DNS 検索を含める必要がある場合には、検索を非同期にしてください。

Enabled

非同期 DNS が無効になっていると、この節の残りの部分は表示されません。

NameLookups

サーバー起動後に実行された名前検索 (DNS 名から IP アドレス) の数。この設定はチューニング不可能です。

AddrLookups

サーバー起動後に実行されたアドレス検索 (IP アドレスから DNS 名) の数。この設定はチューニング不可能です。

LookupsInProgress

現在実行中の検索の数。

接続キュー

ファイルキャッシュ情報 (file-cache)

ファイルキャッシュには静的コンテンツが格納されるため、サーバーは静的コンテンツに対する要求をすばやく処理できます。file-cache セクションは、ファイルキャッシュの使用状況に関する統計を提供します。

ファイルキャッシュのチューニング方法の詳細については、「HTTP ファイルキャッシュ」を参照してください。

キープアライブ (keep-alive)

管理コンソールが提供するパフォーマンス関連のキープアライブ統計は、次のとおりです。

スレッドプール (pwc-thread-pool)

管理コンソールが提供するスレッドプール統計は、次のとおりです。

HTTP サービスのチューニング

管理コンソールでは、HTTP サービスの設定は次のカテゴリに分けられています。

アクセスログ

ベンチマーク実行時にはアクセスロギングを無効にします。アクセスロギングはデフォルトで有効になっています。これを無効にするには、「HTTP サービス」で「プロパティーを追加」をクリックし、次のプロパティーを追加します。

設定可能なアクセスログのプロパティーは、次のとおりです。

要求処理

「HTTP サービス」ページの「要求処理」タブで、次の HTTP 要求処理設定を調整します。

スレッド数

「スレッド数」パラメータは、サーバーが処理できる同時要求の最大数を指定します。デフォルト値は 128 です。サーバーは、この要求スレッドの制限に達すると、アクティブ要求数がこの最大数を下回るまで、新しい要求の処理を遅らせます。この値を増やすと、HTTP 応答の待ち時間が短縮されます。

実際には、クライアントがサーバーに接続したあと、要求を完了しないことが頻繁に発生します。それらの場合、サーバーは、「要求タイムアウト」パラメータに指定された時間だけ待ちます。

また、一部のサイトでは、完了までに数分かかる高負荷のトランザクションが実行されます。これらの要因はどちらも、必要とされる最大同時要求数を押し上げます。多くの秒数のかかる要求を多数処理するサイトでは、最大同時要求数を増やさなければいけない可能性があります。

負荷と平均的な要求の処理時間に基づいて、スレッド数の値を調整します。一般に、アイドル CPU 時間と保留中の要求が存在している場合はこの数値を増やし、CPU が過負荷状態になっている場合はこの数値を減らします。HTTP 1.0 クライアント (または接続解除を頻繁に行う HTTP 1.1 クライアント) が多数存在している場合には、タイムアウト値を調整することで、接続を開いたままにしておく時間を短くします。

適切な要求スレッド数の値の範囲は、負荷によって 100 〜 500 になります。システムに余分な CPU サイクルが存在する場合には、スレッド数を段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、スレッド数を増やすのをやめます。

初期スレッド数

「初期スレッド数」プロパティーは、サーバーが起動時に開始するスレッドの最小数を指定します。デフォルト値は 48 です。「初期スレッド数」は同時に実行可能なアクティブスレッドの最大数に対する強い制限値を表しますが、これがパフォーマンス上の障害になる可能性があります。

要求タイムアウト

「要求タイムアウト」プロパティーは、サーバーがあるクライアントへの接続を受け付けてからそのクライアントから情報を受け取るまでに待機する秒数を指定します。デフォルト設定は 30 秒です。ほとんどの状況下では、この設定を変更する必要はありません。これをデフォルトの 30 秒よりも小さい値に設定すると、スレッドをより早く解放できます。これをデフォルトの 30 秒よりも小さい値に設定すると、スレッドをより早く解放できる場合もあります。ただし、低速な接続のユーザーも切断してしまいます。

バッファー長

個々の要求処理スレッドがクライアントからの要求データを読み込むために使用するバッファーのサイズ (バイト)。

要求の実際のサイズに基づいてこの値を調整し、そのパフォーマンスへの影響を監視してください。ほとんどの場合はデフォルトで十分なはずです。要求のサイズが大きい場合はこのパラメータを増やしてください。

キープアライブ

HTTP 1.0 と HTTP 1.1 はどちらも、単一の HTTP セッション経由で複数の要求を送信する機能をサポートします。サーバーは、新しい HTTP 要求を 1 秒間に数百件受信できます。すべての要求の接続をいつまでも開いたままにできるとしたら、サーバーは多くの接続で過負荷状態になってしまう可能性があります。Unix/Linux システム上では、これにより、容易にファイルテーブルオーバーフローが発生する可能性があります。

Application Server のキープアライブシステムがこの問題を解決します。待機中の「キープアライブ」接続は、1 つ前の要求の処理を完了し、その同じ接続上で新しい要求が到着するのを待っています。サーバーは、待機中のキープアライブ接続の最大数に対するカウンタを維持します。サーバー上で最大待機接続数を超える接続が開いた状態で、新しい接続がキープアライブ要求を待機している場合、サーバーはもっとも古い接続を閉じます。このアルゴリズムにより、開いた状態で待機しているキープアライブ接続の数が制限されます。

システムに余分な CPU サイクルが存在する場合には、キープアライブ設定を段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、設定を増やすのをやめます。

パフォーマンスに影響を与える HTTP キープアライブ設定は、次のとおりです。

スレッド数

スレッド数は、キープアライブサブシステム内のスレッドの数を決定します。この設定は、システムのプロセッサ数の数倍になるように調整してください。たとえば、2 個の CPU を備えたシステムは、2 個または 4 個のキープアライブスレッドを持つことができます。

デフォルトは 1 です。ユーザー数や最大接続数が少ないサーバーでは、このデフォルトを変更しないでください。

最大接続数

最大接続数は、サーバーが維持するキープアライブ接続の最大数を制御します。指定可能な範囲はゼロから 32768 まであり、デフォルトは 256 です。

この設定は、サーバーが処理すると予想されるキープアライブ接続の数とサーバーの負荷に基づいて調整してください。なぜなら、この設定を増やすとリソース使用量も増え、待ち時間が長くなる可能性があるからです。

「最大接続数」に指定された接続数は、キープアライブスレッド間で均等に分割されます。最大接続数がスレッド数で割り切れない場合、サーバーは、最大接続数よりも若干多い数の同時キープアライブ接続を許可できます。

タイムアウト

タイムアウトは、サーバーが HTTP キープアライブ接続を開いたままで維持する最大時間 (秒) を決定します。クライアントはサーバーへの接続を開いたままに保つことができるため、1 つのサーバーへの複数の要求を、単一のネットワーク接続を使って処理できます。サーバーが処理できるオープン接続の数は限られているため、オープン接続の数が多すぎると、新しいクライアントが接続できなくなります。

タイムアウトのデフォルト値は 30 秒です。したがって、デフォルトでは、接続のアイドル状態が 30 秒を超えると、サーバーはその接続を閉じます。このパラメータの最大値は 300 秒 (5 分) です。

このパラメータの適切な値は、ある特定のクライアントからの各要求間の予想経過時間によって異なります。たとえば、クライアントからの要求頻度が多いことが予期される場合は、このパラメータを大きな値に設定します。同様に、クライアントからの要求頻度が少ないことが予期される場合は、このパラメータを小さな値に設定します。

キープアライブクエリー平均時間

キープアライブクエリー平均時間は、キープアライブ接続のポーリング間隔を指定します。このパラメータの値が n ミリ秒である場合、キープアライブ接続を要求したクライアントから見た応答時間は、0 ミリ秒から n ミリ秒までのオーバーヘッドを持ちます。

このパラメータのデフォルト値は 1 ミリ秒ですが、キープアライブ接続の予想同時負荷が 300 件未満である場合には、これで問題ありません。このデフォルト値を使用すると、同時負荷が高い場合にスケーラビリティーが極度に低下する恐れがあります。接続負荷の高いアプリケーションでは、このデフォルト値を増やしてください。

このパラメータを設定するには、asadmin を使用するか、あるいは管理コンソールの「HTTP サービス」ページで「プロパティーを追加」を選択し、次のように指定します。

キープアライブクエリー最大スリープ時間

キープアライブクエリー最大スリープ時間は、キープアライブ接続のポーリングによってさらなる要求の有無を確認したあとに待機する最大時間 (ミリ秒) を指定します。システムに余分な CPU サイクルが存在する場合には、このパラメータを段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、設定を増やすのをやめます。

このパラメータを設定するには、asadmin を使用するか、あるいは管理コンソールの「HTTP サービス」ページで「プロパティーを追加」を選択し、次のように指定します。

接続プール

接続キュー情報は、キュー内のセッション数や接続が受け付けられるまでの平均遅延時間などを示します。

システムに余分な CPU サイクルが存在する場合には、接続プール設定を段階的に増やしていき、増やすたびにパフォーマンスを監視します。パフォーマンスが飽和したら (改善しなくなったら)、設定を増やすのをやめます。

パフォーマンスに影響を与える接続プール設定は、次のとおりです。

最大保留カウント

最大保留カウントは、待機ソケット上で保留状態になっている接続の最大数を指定します。最大保留カウントを調整するのは、システムの負荷が非常に高い場合だけにしてください。低負荷から中程度の負荷の場合、デフォルトで問題ありません。

システムの動作を監視したあと、その結果に基づいて値を変更してください。そうでないと、サーバーは接続をドロップし始めます。バックログキューがいっぱいになった待機ソケット上で接続がタイムアウトすると、その接続は失敗します。最大保留カウントが制限に近づいた場合、高負荷下で接続のドロップが発生しないように、最大接続キューサイズを増やしてください。

キューサイズ

キューサイズは、サーバーが持つことのできる未処理の (まだ処理されていない) 接続の数を指定します。限られた数の要求処理スレッドを持つ、ユーザー数の多い高負荷システムでは、この設定を調整して大きな値にしてください。

注 –

接続キューサイズの設定を大きくしすぎると、サーバーのパフォーマンスが劣化する恐れがあります。その設計目的は、処理できない接続によってサーバーが過負荷状態に陥るのを防ぐことでした。サーバーが過負荷状態に陥っている場合に接続キューサイズを増やしても、要求処理の待ち時間が長くなり、接続キューが再度いっぱいになります。

送信バッファーサイズ

ソケットによって使用される送信バッファーのサイズ (バイト) を指定します。

受信バッファーサイズ

ソケットによって使用される受信バッファーのサイズ (バイト) を指定します。

送信バッファーサイズと受信バッファーサイズは、それぞれ出力バッファー、入力バッファー用として割り当てられるバッファーサイズのことです。これらのパラメータを調整するには、それらの値を規則的に増やし、そのパフォーマンスへの影響を監視します。パフォーマンスが飽和したら (あまり改善されなくなったら)、値を増やすのをやめます。

HTTP プロトコル

パフォーマンスに大きな影響を与える「HTTP プロトコル」属性は、「DNS 検索が有効」だけです。

DNS 検索が有効

この設定は、サーバーにアクセスするクライアントに対する DNS (ドメインネームサービス) 検索を、サーバーが実行するかどうかを指定します。DNS 検索が有効でない場合、あるクライアントが接続したときに、サーバーはそのクライアントの IP アドレスを認識しますが、そのホスト名は認識しません (たとえば、サーバーはクライアントを www.xyz.com としてではなく、198.95.251.30 として認識する)。DNS 検索が有効である場合、サーバーはクライアントの IP アドレスを解決してホスト名を得ますが、このホスト名は、アクセス制御、CGI (Common Gateway Interface) プログラム、エラー報告、アクセスロギングなどの処理で使用されます。

サーバーが 1 日に多数の要求への応答を行う場合には、DNS 検索を無効にすることで、DNS または NIS (Network Information System) サーバーへの負荷を減らしてください。DNS 検索を有効にすると待ち時間が長くなり、システムへの負荷が高まります。したがって、有効にする場合には注意が必要です。

HTTP ファイルキャッシュ

Application Server は、ファイルキャッシュを使用することで静的情報をより高速に提供します。ファイルキャッシュには、HTML ファイル、CSS ファイル、イメージファイル、テキストファイルなどの静的ファイルに関する情報が格納されます。HTTP ファイルキャッシュを有効にすると、静的ファイルを含むアプリケーションのパフォーマンスが改善されます。

管理コンソールでファイルキャッシュの属性を設定するには、「設定」>「config-name」>「HTTP サービス (HTTP ファイルキャッシュ)」を選択します。

最大ファイル数

最大ファイル数は、キャッシュ内のファイル数を決定します。この値が大きすぎると、必要性のほとんどないファイルまでサーバーがキャッシュに書き込むことになり、メモリーの無駄使いになります。この値が小さすぎると、キャッシュ処理の利点が失われます。この属性のさまざまな値を試し、特定のアプリケーションでの最適解を見つけてください。一般に、効果はそれほど大きくありません。

ハッシュ初期サイズ

ハッシュ初期サイズはメモリー使用量と検索時間に影響を与えますが、これによってパフォーマンスに対する測定可能な効果が得られることは、ほとんどありません。

最大有効期間

このパラメータは、ファイルがキャッシュに書き込まれたあと、そのキャッシュ情報がどのくらいの期間使用されるかを制御します。最大有効期間を経過したエントリは、同じファイルの新しいエントリで置き換えられます。

コンテンツの変更頻度が低い Web サイトでは、パフォーマンスを改善するためにこの値を増やしてください。最大有効期間を設定するには、Web ベースの管理コンソールで、HTTP サーバーノードに対する「HTTP ファイルキャッシュ」ページの「最大有効期間」フィールドで値を入力または変更し、「ファイルキャッシュを有効化」チェックボックスを選択します。

コンテンツを定期的に更新 (既存のファイルを変更) するかどうかに基づいて最大時間を設定します。たとえば、コンテンツが定期的に 1 日に 4 回更新される場合、最大時間を 21600 秒 (6 時間) に設定できます。それ以外の場合、最大時間には、ファイルが変更されたあと、以前のバージョンのコンテンツファイルを提供する最大時間を設定することを検討してください。

小/中のファイルサイズとファイルサイズ上限

キャッシュは小ファイル、中ファイル、大ファイルを異なる方法で処理します。中ファイルのコンテンツは、ファイルが仮想メモリー (Unix/Linux プラットフォーム) にマッピングされることにより、キャッシュされます。小ファイルのコンテンツは、ヒープスペースが割り当てられ、ファイルをそのスペース内に読み込むことにより、キャッシュされます。大ファイルのコンテンツはキャッシュされませんが、大ファイルの情報はキャッシュされます。

小ファイルと中ファイルを区別する利点は、小ファイルが多数ある場合に、仮想メモリーで多くのページが消費されるのを防ぐことにあります。このため、「Small File Size Limit」の値は、通常は VM ページサイズよりもやや低い値になります。

ファイル転送

ファイル転送が有効になっていると、サーバーはファイルのコンテンツではなく、ファイルのオープンファイル記述子をファイルキャッシュに書き込みます。また、キャッシュに書き込まれるのはオープンファイル記述子だけなので、通常行われる小、中、および大ファイルの区別は行われなくなります。

デフォルトでは、Windows では「ファイル転送」は有効に、UNIX では無効に設定されています。UNIX の場合、ファイル転送を有効にできるのは、必須のネイティブ OS サポートを含むプラットフォームだけです。それは HP-UX と AIX です。その他の UNIX/Linux プラットフォームではこれを有効にしないでください。

HTTP リスナー設定のチューニング

管理コンソールで 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 リスナー上のアクセプタスレッドが接続を受け付け、それらを接続キューに入れます。次に、セッションスレッドがキューから接続を取り出し、その要求を処理します。サーバーは、要求の終了時に必要に応じてセッションスレッドを追加します。

新しいスレッドの追加ポリシーは、接続キューの状態に基づいています。

Grizzly の設定

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 の設定を制御するプロパティーは、次のとおりです。

注 –

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 

ソケットからの要求バイトの読み取りに使用されるスレッドの数。 

 

Version 7 からの移行

既存のインストールを Application Server version 7.x からversion 8 へ移行する場合には、次の表でチューニング可能パラメータのマッピングを確認してください。

表 3–4 チューニング可能設定の、version 7 から version 8 へのマッピング

version 7.x のチューニング可能設定 

version 8.1 のチューニング可能設定 

RqThrottle 

スレッド数 (thread-count) 

RqThrottleMin 

初期スレッド数 (initial-thread-count) 

ConnQueueSize 

キューサイズ (queue-size-in-bytes) 

KeepAliveThreads 

スレッド数 (keep-alive-thread-count) 

KeepAliveTimeout 

タイムアウト (timeout-in-seconds) 

MaxKeepAliveConnections 

最大接続数 (max-connections) 

KeepAliveQueryMeanTime 

keep-alive-query-mean-time 

KeepAliveQueryMaxSleepTime 

keep-alive-query-max-sleep-time 

ListenQ 

スレッド数 (max-pending-count) 

AcceptTimeout 

要求タイムアウト 

HeaderBufferSize 

バッファー長