Hitachi

Cosminexus V11 アプリケーションサーバ 機能解説 保守／移行編

12.4.1　パフォーマンスチューニング

アプリケーションサーバ Version 11およびDeveloper Version 11では，J2EEアプリケーション実行基盤のパフォーマンスチューニングの観点のうち，次の観点が変更されています。

〈この項の構成〉

(1)　同時実行数の最適化

アプリケーションサーバ Version 9およびDeveloper Version 9以前では，Webコンテナのリクエスト処理スレッドは1つのコネクションに対して必ず1つのスレッドが割り当てられ，クライアントにレスポンス本文を送信し終えるまでリクエスト処理スレッドを占有していました。

アプリケーションサーバ Version 11およびDeveloper Version 11以降では，Servlet 3.0の非同期サーブレットやServlet 3.1の非同期I/O API，WebSocketなどのノンブロッキングI/Oを前提とする標準仕様をサポートするため，リクエストを受けるコネクションの管理と，受け付けたリクエストを処理するスレッドの管理を分離し，1つのコネクションが複数の処理スレッドを使用することや，リクエストの受付処理とレスポンスの送信処理を別々のスレッドに処理させることを可能にしました。

これに伴い，アプリケーションサーバ Version 11およびDeveloper Version 11ではVersion 9以前の同時実行数制御の考え方とは異なる部分があります。以降では，Webサーバの構成ごとに同時実行数制御の設定ポイントの相違点を説明します。

(a)　リダイレクタによるWebサーバ連携構成から移行する場合

アプリケーションサーバ Version 9およびDeveloper Version 9以前で使用していたリダイレクタ機能では，WebサーバとWebコンテナ間を常設コネクションで接続し，Webコンテナ側では1つのコネクションごとに1つのリクエスト処理スレッドを占有していました。そのため，生成されるスレッド数は同時接続可能な最大コネクション数と常に同じ値になります。また，同時実行スレッド数制御によって，生成されたスレッドのうち同時に実行が可能なスレッドを制御することで，パフォーマンスの低下やリソースの枯渇を抑制できました。アプリケーションサーバ Version 9およびDeveloper Version 9のスレッド数制御の仕組みを次の図に示します。

図12‒3　アプリケーションサーバ Version 9およびDeveloper Version 9のスレッド数制御の仕組み（Webサーバ連携の場合）

[図データ]

アプリケーションサーバ Version 11およびDeveloper Version 11のNIO HTTPサーバ機能では，WebサーバとWebコンテナ間を常設コネクションで接続しても，Webコンテナ側のリクエスト処理スレッドはコネクションに占有されることはありません。Webコンテナ側がデータの受信を検知するたびにスレッドプールからスレッドを割り当てて処理します。また，同時実行スレッド数制御によって，サーブレットのリクエスト処理要求に対して割り当てられたスレッドのうち同時に実行できるスレッドを制御することで，アプリケーションサーバ Version 9およびDeveloper Version 9と同様にパフォーマンスの低下やリソースの枯渇を抑制できます。アプリケーションサーバ Version 11およびDeveloper Version 11のスレッド数制御の仕組みを次の図に示します。

図12‒4　アプリケーションサーバ Version 11およびDeveloper Version 11のスレッド数制御の仕組み（Webサーバ連携の場合）

[図データ]

NIO HTTPサーバ機能では，J2EEサーバ起動時にスレッドプールにあらかじめ生成しておくスレッド数と，動的に生成する最大スレッド数を定義できます。Webサーバ連携構成のアプリケーションサーバ Version 9およびDeveloper Version 9から移行する場合に推奨されるスレッド数の設定値を次の表に示します。ただし，WebSocket機能を使用する場合はこの限りではありません。詳細は「12.4.1(1)(c)　WebSocket機能を使用するために最大同時接続数を増やす場合の注意点」を参照してください。

表12‒6　推奨される同時実行数設定値（Webサーバ連携構成からの移行の場合）

設定先のNIO HTTPサーバのパラメタ

推奨される設定値

アプリケーションサーバ Version 9およびDeveloper Version 9までの機能だけを使用する場合

アプリケーションサーバ Version 11およびDeveloper Version 11でサポートされた非同期処理を使用する場合

webserver.connector.nio_http.max_threads

webserver.connector.ajp13.max_threadsと同じ値

webserver.connector.ajp13.max_threadsの値

＋コネクション数を超えて同時実行される非同期処理※の最大同時実行数

webserver.connector.nio_http.min_threads

webserver.connector.ajp13.max_threadsと同じ値

webserver.connector.nio_http.max_connections

webserver.connector.ajp13.max_threadsと同じ値
注※

「コネクション数を超えて同時実行される非同期処理」に含まれるものは次のとおりです。

  • Servlet 3.0のjavax.servlet.AsyncContextのstartメソッドの呼び出し

  • WebSocketのjavax.websocket.RemoteEndpoint.AsyncインタフェースのsendBinaryメソッド，sendObjectメソッド，sendTextメソッドの呼び出し

(b)　インプロセスHTTPサーバ構成から移行する場合

アプリケーションサーバ Version 9およびDeveloper Version 9以前で使用していたインプロセスHTTPサーバ機能では，クライアントから接続要求があるたびに，スレッドプールにあらかじめ生成しておいたスレッドをコネクションごとに割り当て，クライアントとの接続が切れるまでそのスレッドを占有していました。また，同時実行スレッド数制御によって，生成されたスレッドのうち同時に実行できるスレッドを制御することで，パフォーマンスの低下やリソースの枯渇を抑制できました。

アプリケーションサーバ Version 11およびDeveloper Version 11のNIO HTTPサーバ機能では，Webコンテナ側のリクエスト処理スレッドはコネクションに占有されることなく，Webコンテナ側がデータの受信を検知するたびにスレッドプールからスレッドを割り当てて処理します。また，同時実行スレッド数制御によって，サーブレットのリクエスト処理要求に対して割り当てられたスレッドのうち同時に実行できるスレッドを制御することで，アプリケーションサーバ Version 9およびDeveloper Version 9と同様にパフォーマンスの低下やリソースの枯渇を抑制できます。

NIO HTTPサーバ機能では，J2EEサーバ起動時にスレッドプールにあらかじめ生成しておくスレッド数と，動的に生成する最大スレッド数を定義できます。インプロセスHTTPサーバ構成のアプリケーションサーバ Version 9およびDeveloper Version 9から移行する場合に推奨されるスレッド数の設定値を次の表に示します。ただし，WebSocket機能を使用する場合はこの限りではありません。詳細は「12.4.1(1)(c)　WebSocket機能を使用するために最大同時接続数を増やす場合の注意点」を参照してください。

表12‒7　推奨される同時実行数設定値（インプロセスHTTPサーバ構成からの移行の場合）

設定先のNIO HTTPサーバのパラメタ

アプリケーションサーバ Version 11およびDeveloper Version 11で推奨される設定値

アプリケーションサーバ Version 9およびDeveloper Version 9までの機能だけを使用する場合

アプリケーションサーバ Version 11およびDeveloper Version 11でサポートされた非同期処理を使用する場合

webserver.connector.nio_http.max_threads

webserver.connector.inprocess_http.max_connectionsと同値

webserver.connector.inprocess_http.max_connectionsの値

＋コネクション数を超えて同時実行される非同期処理※の最大同時実行数

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

webserver.connector.inprocess_http.max_connectionsと同じ値
注※

「コネクション数を超えて同時実行される非同期処理」に含まれるものは次のとおりです。

  • Servlet 3.0のjavax.servlet.AsyncContextのstartメソッドの呼び出し

  • WebSocketのjavax.websocket.RemoteEndpoint.AsyncインタフェースのsendBinaryメソッド，sendObjectメソッド，sendTextメソッドの呼び出し

(c)　WebSocket機能を使用するために最大同時接続数を増やす場合の注意点

アプリケーションサーバ Version 11およびDeveloper Version 11のNIO HTTPサーバ機能では，スレッド数と最大同時接続数は必ずしも同じ値である必要はありません。同時接続数に対してスレッド数が少ない場合でも，データの受信処理を同時に行う最大同時実行数が最大スレッド数以内であれば実行待ちは発生しません。また，スレッドが割り当てできないで実行待ちが発生した場合でも，無限長の実行待ちキューにキューイングされるので，スレッドに空きができればデータの受信処理が再開されます。

アプリケーションサーバ Version 11およびDeveloper Version 11以前で追加されたWebSocket機能を使用する場合，多数のWebSocketクライアントとの接続を長時間維持するために最大同時接続数を増やす必要が生じることがあります。アプリケーションサーバ Version 9およびDeveloper Version 9以前はCosminexus HTTP ServerとインプロセスHTTPサーバともに，最大同時接続数の上限を「1024」としていましたが，アプリケーションサーバ Version 11およびDeveloper Version 11ではWebSocket対応を考慮して上限値を引き上げました。

しかし，最大同時接続数に合わせてNIO HTTPサーバの最大スレッド数を増やすと，スレッド数に比例してメモリ使用量も増加します。また，1つのプロセスが生成できるスレッド数はOSによって上限があります。最小スレッド数に対して確保できるメモリ容量やOSのスレッド数上限が不足している場合は，J2EEサーバの起動処理中にOutOfMemoryErrorが発生してJ2EEサーバの起動に失敗するおそれがあります。最大スレッド数に対して確保できるメモリ容量やOSのスレッド数上限が不足している場合は，リクエスト受付処理中にOutOfMemoryErrorが発生してJ2EEサーバがプロセスダウンするおそれがあります。

もし，NIO HTTPサーバの最小スレッド数や最大スレッド数を増やす場合には，メモリサイズ（物理メモリのサイズ，J2EEサーバプロセスの-Xmx指定値）も適切に再見積もりしてください。

最大スレッド数の見積もり方法についてはマニュアル「アプリケーションサーバ システム設計ガイド」の「5.2.1　J2EEサーバが使用するリソースの見積もり」を参照してください。メモリ使用量については，マニュアル「アプリケーションサーバ システム設計ガイド」の「5.3.1　J2EEサーバが使用する仮想メモリの使用量の見積もり」を参照してください。

ページの先頭へ

(2)　タイムアウトの設定

アプリケーションサーバ Version 11およびDeveloper Version 11以降では，タイムアウトの発生個所とタイムアウト値の設定パラメタがアプリケーションサーバ Version 9およびDeveloper Version 9以前と異なります。以降では，Webサーバの構成ごとにタイムアウトの設定ポイントの相違点を説明します。

(a)　リダイレクタによるWebサーバ連携構成から移行する場合

アプリケーションサーバ Version 11およびDeveloper Version 11では，リダイレクタモジュール（mod_jk）がプロキシモジュール（mod_proxy）に，Webコンテナ側のリクエストの受け口がNIO HTTPサーバに変わります。

そのため，アプリケーションサーバ Version 9およびDeveloper Version 9でリダイレクタとWebコンテナに設定していたタイムアウトは，アプリケーションサーバ Version 11およびDeveloper Version 11ではリバースプロキシとNIO HTTPサーバに設定するタイムアウトに変わります。

アプリケーションサーバ Version 9およびDeveloper Version 9でタイムアウトが設定できるポイントについて，次の図に示します。

図12‒5　アプリケーションサーバ Version 9およびDeveloper Version 9でタイムアウトが設定できるポイント（Webサーバ連携の場合）

[図データ]

アプリケーションサーバ Version 11およびDeveloper Version 11でタイムアウトが設定できるポイントについて，次の図に示します。

図12‒6　アプリケーションサーバ Version 11およびDeveloper Version 11でタイムアウトが設定できるポイント（Webサーバ連携の場合）

[図データ]

アプリケーションサーバ Version 9およびDeveloper Version 9からアプリケーションサーバ Version 11およびDeveloper Version 11への移行が必要なポイントについて，それぞれの相違点を次の表に示します。

表12‒8　各ポイントに設定するタイムアウトの相違点（Webサーバ連携構成からの移行）

ポイント

タイムアウトの種類

アプリケーションサーバ Version 9およびDeveloper Version 9

アプリケーションサーバ Version 11およびDeveloper Version 11

2

リダイレクタ側で設定するWebコンテナへのコネクション確立のタイムアウト。

設定対象

  • mod_jk.conf （リダイレクタ動作定義ファイル）

  • 論理Webサーバ（web-server）

設定個所

JkConnectTimeout

リバースプロキシ側で設定するWebコンテナ（NIO HTTPサーバ）へのコネクション確立のタイムアウト。

設定対象

  • httpsd.conf

  • 論理Webサーバ（web-server）

設定個所

ProxyPassのconnectiontimeoutキー，

ProxyPassのtimeoutキー，

またはTimeout

3

リダイレクタ側で設定するWebコンテナへのリクエストヘッダおよびリクエストボディ送信のタイムアウト。

設定対象

  • mod_jk.conf （リダイレクタ動作定義ファイル）

  • 論理Webサーバ（web-server）

設定個所

JkSendTimeout

リバースプロキシ側で設定するWebコンテナ（NIO HTTPサーバ）へのリクエストヘッダおよびリクエストボディ送信のタイムアウト。

設定対象

  • httpsd.conf

  • 論理Webサーバ（web-server）

設定個所

ProxyPassのtimeoutキー，またはTimeout

4

リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト。

設定対象

  • worker.properties （ワーカ定義ファイル）

  • 論理Webサーバ（web-server）

設定個所

worker.<ワーカ名>.receive_timeout

リバースプロキシ側で設定するWebコンテナ（NIO HTTPサーバ）からのデータ受信のタイムアウト。

設定対象

  • httpsd.conf

  • 論理Webサーバ（web-server）

設定個所

ProxyPassのtimeoutキー，またはTimeout

5

Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.ajp13.receive_timeout

Webコンテナ（NIO HTTPサーバ）側で設定するリバースプロキシからのデータ受信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.nio_http.receive_timeout

13

Webコンテナ側で設定するリダイレクタへのレスポンス送信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.ajp13.send_timeout

Webコンテナ（NIO HTTPサーバ）側で設定するリバースプロキシへのデータ送信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.nio_http.send_timeout

(b)　インプロセスHTTPサーバ構成から移行する場合

アプリケーションサーバ Version 11およびDeveloper Version 11では，インプロセスHTTPサーバがNIO HTTPサーバに代わります。

そのため，アプリケーションサーバ Version 9およびDeveloper Version 9でインプロセスHTTPサーバに設定していたタイムアウトは，アプリケーションサーバ Version 11およびDeveloper Version 11ではNIO HTTPサーバに設定するタイムアウトに変わります。

タイムアウトが設定できるポイントについて，次の図に示します。

図12‒7　タイムアウトが設定できるポイント（インプロセスHTTPサーバの場合）

[図データ]

アプリケーションサーバ Version 9およびDeveloper Version 9からアプリケーションサーバ Version11およびDeveloper Version 11への移行が必要なポイントについて，それぞれの相違点を次の表に示します。

表12‒9　各ポイントに設定するタイムアウトの相違点（インプロセスHTTPサーバ構成からの移行）

ポイント

タイムアウトの種類

アプリケーションサーバ Version 9およびDeveloper Version 9

アプリケーションサーバ Version 11およびDeveloper Version 11

5

Webコンテナ側で設定するクライアントからのリクエスト受信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.inprocess_http.receive_timeout

NIO HTTPサーバ側で設定するクライアントからのデータ受信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.nio_http.receive_timeout

13

Webコンテナ側で設定するクライアントへののレスポンス送信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.inprocess_http.send_timeout

NIO HTTPサーバ側で設定するクライアントへのデータ送信のタイムアウト。

設定対象

  • usrconf.properties（J2EEサーバ用ユーザプロパティ）

  • 論理J2EEサーバ（j2ee-server）

設定個所

webserver.connector.nio_http.send_timeout

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2020, 2021, Hitachi, Ltd.