12.4.1 パフォーマンスチューニング
アプリケーションサーバ 11-40では,J2EEアプリケーション実行基盤のパフォーマンスチューニングの観点のうち,次の観点が09-87以前と異なります。
-
同時実行数の最適化
-
タイムアウトの設定
- 〈この項の構成〉
(1) 同時実行数の最適化
アプリケーションサーバ 09-87以前では,Webコンテナのリクエスト処理スレッドは1つのコネクションに対して必ず1つのスレッドが割り当てられ,クライアントにレスポンス本文を送信し終えるまでリクエスト処理スレッドを占有していました。
アプリケーションサーバ 11-40では,Servlet 3.0の非同期サーブレットやServlet 3.1の非同期I/O API,WebSocketなどのノンブロッキングI/Oを前提とする標準仕様をサポートするため,リクエストを受けるコネクションの管理と,受け付けたリクエストを処理するスレッドの管理を分離し,1つのコネクションが複数の処理スレッドを使用することや,リクエストの受付処理とレスポンスの送信処理を別々のスレッドに処理させることができます。
これに伴い,アプリケーションサーバ 11-40では,09-87以前の同時実行数制御の考え方とは異なる部分があります。以降では,Webサーバの構成ごとに同時実行数制御の設定ポイントの相違点を説明します。
(a) リダイレクタによるWebサーバ連携構成から移行する場合
アプリケーションサーバ 09-87以前で使用していたリダイレクタ機能では,WebサーバとWebコンテナ間を常設コネクションで接続し,Webコンテナ側では1つのコネクションごとに1つのリクエスト処理スレッドを占有していました。そのため,生成されるスレッド数は同時接続可能な最大コネクション数と常に同じ値になります。また,同時実行スレッド数制御によって,生成されたスレッドのうち同時に実行が可能なスレッドを制御することで,パフォーマンスの低下やリソースの枯渇を抑制できました。アプリケーションサーバ 09-87のスレッド数制御の仕組みを次の図に示します。
アプリケーションサーバ 11-40のNIO HTTPサーバ機能では,WebサーバとWebコンテナ間を常設コネクションで接続しても,Webコンテナ側のリクエスト処理スレッドはコネクションに占有されることはありません。Webコンテナ側がデータの受信を検知するたびにスレッドプールからスレッドを割り当てて処理します。また,同時実行スレッド数制御によって,サーブレットのリクエスト処理要求に対して割り当てられたスレッドのうち同時に実行できるスレッドを制御することで,アプリケーションサーバ 09-87と同様にパフォーマンスの低下やリソースの枯渇を抑制できます。アプリケーションサーバ 11-40のスレッド数制御の仕組みを次の図に示します。
NIO HTTPサーバ機能では,J2EEサーバ起動時にスレッドプールにあらかじめ生成しておくスレッド数と,動的に生成する最大スレッド数を定義できます。Webサーバ連携構成のアプリケーションサーバ 09-87から移行する場合に推奨されるスレッド数の設定値を次の表に示します。ただし,WebSocket機能を使用する場合はこの限りではありません。詳細は「12.4.1(1)(c) WebSocket機能を使用するために最大同時接続数を増やす場合の注意点」を参照してください。
設定先のNIO HTTPサーバのパラメタ |
推奨される設定値 |
|
---|---|---|
アプリケーションサーバ 09-87以前の機能だけを使用する場合 |
アプリケーションサーバ 11-40でサポートされている非同期処理を使用する場合 |
|
webserver.connector.nio_http.max_threads |
webserver.connector.ajp13.max_threadsと同じ値 |
webserver.connector.ajp13.max_threadsの値 +コネクション数を超えて同時実行される非同期処理※1の最大同時実行数 |
webserver.connector.nio_http.min_threads |
webserver.connector.ajp13.max_threadsと同じ値 |
|
webserver.connector.nio_http.max_connections |
J2EEサーバに接続するコネクション数の総和※2 |
- 注※1
-
「コネクション数を超えて同時実行される非同期処理」に含まれるものは次のとおりです。
-
Servlet 3.0のjavax.servlet.AsyncContextのstartメソッドの呼び出し
-
WebSocketのjavax.websocket.RemoteEndpoint.AsyncインタフェースのsendBinaryメソッド,sendObjectメソッド,sendTextメソッドの呼び出し
-
- 注※2
-
「J2EEサーバに接続するコネクション数の総和」は,J2EEサーバのNIO HTTPサーバに接続する接続数の総和です。複数のプロセスからJ2EEサーバに接続する場合,各プロセスからの最大接続数の総和を設定してください。
なお,Cosminexus HTTP ServerのリバースプロキシからJ2EEサーバへの最大接続数は,マニュアル「HTTP Server」の「4.7.4(5) 性能に関する注意事項」を参照してください。
(b) インプロセスHTTPサーバ構成から移行する場合
アプリケーションサーバ 09-87以前で使用していたインプロセスHTTPサーバ機能では,クライアントから接続要求があるたびに,スレッドプールにあらかじめ生成しておいたスレッドをコネクションごとに割り当て,クライアントとの接続が切れるまでそのスレッドを占有していました。また,同時実行スレッド数制御によって,生成されたスレッドのうち同時に実行できるスレッドを制御することで,パフォーマンスの低下やリソースの枯渇を抑制できました。
アプリケーションサーバ 11-40のNIO HTTPサーバ機能では,Webコンテナ側のリクエスト処理スレッドはコネクションに占有されることなく,Webコンテナ側がデータの受信を検知するたびにスレッドプールからスレッドを割り当てて処理します。また,同時実行スレッド数制御によって,サーブレットのリクエスト処理要求に対して割り当てられたスレッドのうち同時に実行できるスレッドを制御することで,アプリケーションサーバ 09-87と同様にパフォーマンスの低下やリソースの枯渇を抑制できます。
NIO HTTPサーバ機能では,J2EEサーバ起動時にスレッドプールにあらかじめ生成しておくスレッド数と,動的に生成する最大スレッド数を定義できます。インプロセスHTTPサーバ構成のアプリケーションサーバ 09-87から移行する場合に推奨されるスレッド数の設定値を次の表に示します。ただし,WebSocket機能を使用する場合はこの限りではありません。詳細は「12.4.1(1)(c) WebSocket機能を使用するために最大同時接続数を増やす場合の注意点」を参照してください。
設定先のNIO HTTPサーバのパラメタ |
アプリケーションサーバ 11-40で推奨される設定値 |
|
---|---|---|
アプリケーションサーバ 09-87以前の機能だけを使用する場合 |
アプリケーションサーバ 11-40でサポートされた非同期処理を使用する場合 |
|
webserver.connector.nio_http.max_threads |
webserver.connector.inprocess_http.max_connectionsと同値 |
webserver.connector.inprocess_http.max_connectionsの値 +コネクション数を超えて同時実行される非同期処理※1の最大同時実行数 |
webserver.connector.nio_http.min_threads |
webserver.connector.inprocess_http.max_connectionsまたは webserver.connector.inprocess_http.max_spare_threadsまたは webserver.connector.inprocess_http.init_threadsのうち 最も小さい方の値 |
|
webserver.connector.nio_http.max_connections※2 |
webserver.connector.inprocess_http.max_connectionsと同じ値※3 |
- 注※1
-
「コネクション数を超えて同時実行される非同期処理」に含まれるものは次のとおりです。
-
Servlet 3.0のjavax.servlet.AsyncContextのstartメソッドの呼び出し
-
WebSocketのjavax.websocket.RemoteEndpoint.AsyncインタフェースのsendBinaryメソッド,sendObjectメソッド,sendTextメソッドの呼び出し
-
- 注※2
-
クライアントとNIO HTTPサーバ間のコネクションを常設にする場合,webserver.connector.nio_http.max_connectionsの値は,クライアントから接続される数以上にしてください。
- 注※3
-
インプロセスHTTPサーバの接続元としてプロキシサーバを配置している構成からの移行で,複数のプロセスからJ2EEサーバに接続する場合,各プロセスからの最大接続数の総和を設定してください。
なお,Cosminexus HTTP ServerのリバースプロキシからJ2EEサーバへの最大接続数は,マニュアル「HTTP Server」の「4.7.4(5) 性能に関する注意事項」を参照してください。
(c) WebSocket機能を使用するために最大同時接続数を増やす場合の注意点
アプリケーションサーバ 11-40のWebSocket機能を使用する場合,多数のWebSocketクライアントとの接続を長時間維持するために最大同時接続数を増やす必要が生じることがあります。アプリケーションサーバ 09-87以前はCosminexus HTTP ServerとインプロセスHTTPサーバともに,最大同時接続数の上限を「1024」としていましたが,アプリケーションサーバ 11-40ではWebSocketを考慮して上限値が09-87以前より大きくなっています。
しかし,最大同時接続数に合わせてNIO HTTPサーバの最大スレッド数を増やすと,スレッド数に比例してメモリ使用量も増加します。また,1つのプロセスが生成できるスレッド数はOSによって上限があります。最小スレッド数に対して確保できるメモリ容量やOSのスレッド数上限が不足している場合は,J2EEサーバの起動処理中にOutOfMemoryErrorが発生してJ2EEサーバの起動に失敗するおそれがあります。最大スレッド数に対して確保できるメモリ容量やOSのスレッド数上限が不足している場合は,リクエスト受付処理中にOutOfMemoryErrorが発生してJ2EEサーバがプロセスダウンするおそれがあります。
もし,NIO HTTPサーバの最小スレッド数や最大スレッド数を増やす場合には,メモリサイズ(物理メモリのサイズ,J2EEサーバプロセスの-Xmx指定値)も適切に再見積もりしてください。
最大スレッド数の見積もり方法についてはマニュアル「アプリケーションサーバ システム設計ガイド」の「5.2.1 J2EEサーバが使用するリソースの見積もり」を参照してください。メモリ使用量については,マニュアル「アプリケーションサーバ システム設計ガイド」の「5.3.1 J2EEサーバが使用する仮想メモリの使用量の見積もり」を参照してください。
(2) タイムアウトの設定
アプリケーションサーバ 11-40では,タイムアウトの発生個所とタイムアウト値の設定パラメタがアプリケーションサーバ 09-87以前と異なります。以降では,Webサーバの構成ごとにタイムアウトの設定ポイントの相違点を説明します。
(a) リダイレクタによるWebサーバ連携構成から移行する場合
アプリケーションサーバ 11-40では,リダイレクタモジュール(mod_jk)をプロキシモジュール(mod_proxy)に,Webコンテナ側のリクエストの受け口がNIO HTTPサーバになっています。
そのため,アプリケーションサーバ 09-87でリダイレクタとWebコンテナに設定していたタイムアウトは,アプリケーションサーバ 11-40ではリバースプロキシとNIO HTTPサーバに設定するタイムアウトに変わります。
アプリケーションサーバ 09-87でタイムアウトが設定できるポイントについて,次の図に示します。
アプリケーションサーバ 11-40でタイムアウトが設定できるポイントについて,次の図に示します。
アプリケーションサーバ 09-87からアプリケーションサーバ 11-40への移行が必要なポイントについて,それぞれの相違点を次の表に示します。
ポイント |
タイムアウトの種類 |
|
---|---|---|
アプリケーションサーバ 09-87 |
アプリケーションサーバ 11-40 |
|
2 |
リダイレクタ側で設定するWebコンテナへのコネクション確立のタイムアウト。
|
リバースプロキシ側で設定するWebコンテナ(NIO HTTPサーバ)へのコネクション確立のタイムアウト。
|
3 |
リダイレクタ側で設定するWebコンテナへのリクエストヘッダおよびリクエストボディ送信のタイムアウト。
|
リバースプロキシ側で設定するWebコンテナ(NIO HTTPサーバ)へのリクエストヘッダおよびリクエストボディ送信のタイムアウト。
|
4 |
リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト。
|
リバースプロキシ側で設定するWebコンテナ(NIO HTTPサーバ)からのデータ受信のタイムアウト。
|
5 |
Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト。
|
Webコンテナ(NIO HTTPサーバ)側で設定するリバースプロキシからのデータ受信のタイムアウト。
|
13 |
Webコンテナ側で設定するリダイレクタへのレスポンス送信のタイムアウト。
|
Webコンテナ(NIO HTTPサーバ)側で設定するリバースプロキシへのデータ送信のタイムアウト。
|
(b) インプロセスHTTPサーバ構成から移行する場合
アプリケーションサーバ 11-40では,09-87のインプロセスHTTPサーバがNIO HTTPサーバになります。
そのため,アプリケーションサーバ 09-87でインプロセスHTTPサーバに設定していたタイムアウトは,アプリケーションサーバ 11-40ではNIO HTTPサーバに設定するタイムアウトに変わります。
タイムアウトが設定できるポイントについて,次の図に示します。
アプリケーションサーバ 09-87からアプリケーションサーバ 11-40への移行が必要なポイントについて,それぞれの相違点を次の表に示します。
ポイント |
タイムアウトの種類 |
|
---|---|---|
アプリケーションサーバ 09-87 |
アプリケーションサーバ 11-40 |
|
5 |
Webコンテナ側で設定するクライアントからのリクエスト受信のタイムアウト。
|
NIO HTTPサーバ側で設定するクライアントからのデータ受信のタイムアウト。
|
13 |
Webコンテナ側で設定するクライアントへのレスポンス送信のタイムアウト。
|
NIO HTTPサーバ側で設定するクライアントへのデータ送信のタイムアウト。
|