WAS高速化の要とトランスポート・チャネル・サービス：WebSphereサーバ・チューニング入門（2）（2/3 ページ）

トランスポート・チャネル・サービスとは？

　今回は、「トランスポート・チャネル・サービス」をテーマに取り上げます。WASの使用経験のあるエンジニアの方々でもあまり耳慣れない用語かもしれません。

誤ったパフォーマンス・チューニングを行っている原因

　筆者の経験では、このコンポーネントに関する知識が不足しているために、誤ったチューニングを行っているケースを非常に多く見てきております。その大きな理由としては、「トランスポート・チャネル・サービス」が取り入れられたWASのバージョン6（V6.x）とそれ以前のバージョン（V5.x）で、製品内部で使用されている技術および実装が大きく異なっている点が挙げられます。

　「WAS V5.xのパフォーマンス・チューニング経験のあるエンジニアが、その違いに気が付かずに以前と同様のチューニングを施しているケースが多い」と筆者は考えております。以下にV5.xとV6.xとの違いを説明し、チューニング実施に当たっての検討事項を解説していきます。

V5.xのリクエスト・ハンドリング：「HTTPトランスポート」

　まずは、WAS V5.xの「HTTPトランスポート」によるリクエスト・ハンドリングの仕組みを見てみましょう。

図2　WAS V5.xのリクエスト・ハンドリング：HTTPトランスポート

　新規接続リクエストが到着するとTCPソケットのListenキューに保持されます。続いて、Acceptスレッドが接続を受理し、接続オブジェクトをAccepted Connectionキューに渡します。

　そして、実行可能なWebコンテナ・スレッドが、この接続オブジェクトをキューから受け取り、「ブロッキングI/O」の仕組みを利用してリクエストを処理します。Webコンテナ・スレッドはコネクションごとにブロッキングread／writeを実施します。多くのエンジニアの方々が、同時リクエスト数（同時接続数）と同等、あるいはそれ以上のWebコンテナ・スレッド数が必要であると考えられているのは、こういった仕組みからです。

　「HTTPトランスポート」のカスタム・プロパティの1つである「MaxConnectBacklog」の指定で、Listenキューのサイズを変更できます。このListenキューのサイズは、OSによって制限される場合があり、実際に「MaxConnectBacklog」で指定した値より大きくなったり、あるいは、小さくなったりする場合があります。

　例えば、Solarisのnddコマンドのオプションの1つである「tcp_conn_req_max_q」で、TCP最大保留接続数を変更できます。

　Accepted Connectionキューのサイズの最大数は、WASのバージョンによって異なり、V5.1では、最小スレッド数と最大スレッド数の平均（Webコンテナ・スレッド・プール・サイズの最小値と最大値の平均）です。

　「HTTPトランスポート」内にキューイングされる最大リクエスト数は、「MaxConnectBacklog（Listenキュー）」＋「Accepted Connectionキュー」＋「Webコンテナ・スレッドの最大値（最大Webコンテナ・スレッド・プール・サイズ）」＋1となります。この値と同数のリクエストがキューされている、あるいは、処理の最中に、新規リクエストが到着するとそのリクエストは受信されません。

V6.0のリクエスト・ハンドリング：「トランスポート・チャネル・サービス」

　WAS V6.0で導入された「トランスポート・チャネル・サービス」は別名「チャネル・フレームワーク」とも呼ばれ、JavaのNew I/O API（java.nioパッケージ）のノン・ブロッキングI/O機能をベース技術とし、スケーラビリティの高いI/O基盤を提供します。

　この新しいノン・ブロッキングI/Oアーキテクチャは、HTTPクライアント接続とWebコンテナ・スレッドの多対1マッピングを提供しており、クライアントとの接続およびHTTPやJMSリクエストのI/O処理をより効果的に行えるようになりました。それにより、V5に比べて少ないWebコンテナ・スレッドでより多くのクライアント接続を処理することが可能になり、負荷の高い環境においても“connection refused”エラーの発生を抑制できます。

図3　「トランスポート・チャネル・サービス」のアーキテクチャ

　以下に、「トランスポート・チャネル・サービス」を利用したリクエスト・ハンドリングについて説明します。

図4　WAS V6.0のリクエスト・ハンドリング：トランスポート・チャネル・サービス

　新規接続リクエストが到着すると、TCPソケットのListenキューに保持されます。続いて、Acceptスレッドが接続を受理し、接続オブジェクトをAccepted Connectionキューに渡します。SelectorスレッドがAccepted Connectionキューにあるクライアントからのリクエストを処理し、リクエストはReady Requestキューに渡されます。そして、実行可能なWebコンテナ・スレッドがリクエストをキューから受け取り、リクエストを処理します。

V6.0とV5.xのリクエスト・ハンドリングの違い

　以下にV5.xとV6.0のリクエスト・ハンドリングの違いを説明します。

スロットル・ポイントの違い

　V5.xでは、「MaxConnectBacklog」（Listenキュー）がスロットル（処理を絞り込む）・ポイントであり、「MaxConnectBacklog」数（デフォルト値：511）の調整も必要な場合がありました。

　V6.0では、スロットル・ポイントはAccepted Connectionキュー（最大オープン接続数：20000）であり、非常に高負荷な環境を除き、ほとんどのケースで、「MaxConnectBacklog」の調整が不要です。

KeepAlive接続

　V5.xでは、HTTPクライアント・リクエスト・コネクションとWebコンテナ・スレッドが1対1でマッピングされているために、KeepAlive接続を90％に制限します。それによって、レスポンスを返した後もKeepAliveによりすべてのWebコンテナ・スレッドがクライアントに占有されるために新規リクエストを受け付けられない、という事態を防止していました。

　例えば、同時45リクエストをKeepAlive接続するように調整する場合、V5.xでは、Webコンテナ・スレッド数を50に設定します。

　V6.0では、すべての接続は（デフォルトで）KeepAliveをサポートするようになりました。

HTTPクライアントとWebコンテナ・スレッドのマッピング

　V5.xでは、HTTPクライアント・リクエスト・コネクションとWebコンテナ・スレッドが1対1でマッピングされており、拡張性という面で制約となっていました。

　V6.0では、ノン・ブロッキング・アーキテクチャにより、HTTPクライアントとWebコンテナ・スレッドの1対1マッピングという制約が解除されました。それにより、V5.xと比べ、少数のWebコンテナ・スレッドで多数のクライアントからの接続を効率よくパフォーマンス性能を発揮できるようになりました。

　V5.xで稼働していたWebアプリケーションをV6.0に移行した場合や同様のアプリケーションをV6.0で稼働させる場合、多くのケースにおいてWebコンテナ・スレッドの数をV5.xよりも少なく設定することで、性能向上が可能になります。この特徴を理解せずに、Webコンテナ・スレッド数を不適切に調整しているケースが多く見られますので、注意が必要です。

　ただし、DBアクセス、アプリケーションのロック、同期処理などによりスレッドがブロックされるような場合には、より多くのスレッドへ割り振ることを検討する必要もあります。