ウェブアプリケーションサーバ(WAS)の最大スレッド数を増やすことについて、簡単に説明します。

次のようなシリンダーがあるとしましょう。

単位時間当り流入される水の量と単位時間当り排出される水の量は、キューイングされたアクティブサービス数に相当します。

WASの最大スレッド数を増やすことは、上のシリンダーを次のように作りかえることと似ています。

即ち、シリンダーの広さを大きくするか又はシリンダーの高さを高くすることです。 しかし、そのようにすると性能(Performance)はあがるのでしょうか？そもそもシリンダーの性能とは何でしょうか?　シリンダーの性能とは、同じ時間内により多くの水を排出できる能力です。梅雨の季節に、”時間当り何トンの水を放流しているか”というニュースを耳にされたことがあるでしょう。シリンダーの場合、その性能は”１秒当たり2リットルの水を流すことができる”などのようなものです。しかし、シリンダーのサイズだけを大きくすると、この性能は上がるのでしょうか？そんなことはありません！下記のように、排水口のサイズを大きくすることによって、性能が上がるのです。

排水口のサイズを大きくすることはWAS運用環境では何を大きくすることでしょうか? それは、アプリケーションの処理時間を絶対的に早くする事で、アプリケーションの処理能力を改善することです。 アプリケーションチューニングが根本的な排水口の性能をあらわします。また、WASとDBサーバがある場合、WASの立場では、DB側の性能は相対的に排水口の役割をします。たとえば、SQLクエリが遅いか、DB側が遅くてWASのスレッドがいっぱいの場合、いくらWAS側の最大スレッド数を増やしてもシリンダーの排水口(DB)は増えず、シリンダーだけ大きくしたようなもので、結局単位時間当り流せるシリンダーの能力は上昇しないのです。

ではWASの最大スレッド数はいつ、どれくらい増やすのがいいのでしょうか。グラフを見ると次のようになっています。

即ち、”排水口の最大処理能力まで増やせば十分”なのです。奇形的に過度に大きく設定すると thread context switchingなどにより排水口の本来の性能も出せなくなり逆効果になります。

では、排水口のサイズはどのようにして分かるのでしょうか。排水口のサイズが分からないと、増やすべきシリンダーのサイズがわかりません。 排水口のサイズは単位時間当りの最大処理数です。単位時間当り処理数には性能テスト 過程により、単位時間当り処理数の単位であるTPS(Transation Per Second)という単位を使います。 単位時間当り最大排出量が一番多くなるシリンダーのサイズ、即ち、最大性能がでる時点のWASスレッド数を指定することが重要です。例えば、WAS-DB構造で、負荷量の増加によって、一時的にDB側の障害が先に発生した場合、WASスレッド数を徐々に増やしていくと、DB側のボトルネックによりそれ以上性能(tps)が増加しなくなる数、すなわち最小の適切なWASスレッド数になります。では、通常ログ数値はいくつでしょうか?その質問はナンセンスです。シリンダーによって排水口の サイズは異なるからです。サイトごとにH/W性能が異なり、構成が異なり、開発したアプリケーションの処理速度が異なるのですから、”一般的に”という統計的数値は意味がありません。

排水口が広いとシリンダーに溜まっている水の量は少量です。 即ち、応答速度が速いと、アクティブに動いているアクティブサービス数は少ないのです。 そのため、相対的に応答速度がかなり速い特性を持っている場合、WASの最大スレッド数は相対的に少ない数値に設定するのが効果的です。(これは、WASチューニングのいろいろな方法の中の一つです)

ジェニファー(Jennifer)というアプリケーション性能管理(APM)ツールが現在数多くのサイトに適用されています。 ジェニファーでは、定量化されたデータをリアルタイムに確認することが可能です。ジェニファーでアクティブサービス数がpeak時に平均何個かを確認する事で、WASで最大スレッドとして適切な数を知ることが可能です。 多くのサイトでモニタリングしてみると、その数はいろいろあります。ただ、その数は通常は思ったよりかなり少ないのです。

もうひとつの例で説明しましょう。高速道路は通常片道2車線です。しかし、車が早く走るので、たった2車線だけでも単位時間当り通過する車両の数は多いです。東京都内には、高速道路より広い道路もあります。しかし、信号もあって、車両渋滞が発生するため、10車線でも高速道路より時間当り通過する車両数は少ない場合もあります。即ち、道路の車線の数を増やすだけでは車両混雑が解決できないのです。道路にある横断報道をなくして歩道橋を適切に作るなど交通の流れを悪くするボトルネックをなくすべきです。 10車線から2車線に狭くなるところでは、前の10車線を20車線に増設する必要はありません。 渋滞する車両だけが増えます…即ち、サービスキューイングされるアクティブサービス数だけが増えます。thread context switchingなどによる逆効果は、”高速道路で突然2車線が1車線になる道では横入りする車のため、急に速度を落とすので、もともと1車線の場合の交通の流れより遅くなる現状”と似ています。

結局、応答速度が速ければ、WASの最大スレッド数は少なくても問題ないのです。車両が早く走ることができれば、高速道路で2車線だけで十分であるように・・・。しかし、高速道路で向うの料金所の渋滞でが発生したとき、高速道路を片道10車線に増やしたら、解決できるでしょうか？この場合は警察が むしろ、高速道路に侵入することを制限したほうが効果的です。これがジェニファーのPLC(Peak Load Control)です。