[ 登場人物 ]
被害者：とある Web アプリケーション
現場：その Web アプリケーションが動作中の、Application Server と Database Server (もしかすると付近のネットワークも含まれる)
一線で捜査(操作)する刑事たち：JMeter のリモート実行用 PC
捜査(操作)本部：JMeter のリモート実行 PC を制御する PC

[ 事件のあらまし ]
ある Web アプリケーションのスケーラビリティの状況を把握し、憎きボトルネックの真犯人をあぶりだすべく、ストレステストという名のオトリ捜査(操作)が計画された。
自らの危険をかえりみずオトリとなった JMeter リモート実行 PC が、本部の指令に基づき、どんどん多重度(実行スレッド数)を上げていき、恐るべきボトルネックが姿を現すのを待ち構えるのだった。
ところが、まだまだ本来の犯人を追いつめるにはほど遠い段階にも関わらず、Web アプリケーションのスループットが頭打ちとなってしまう現象が発生！
現場で必死に捜査(操作)を行っている刑事たちの職務怠慢や、本来は被害者であるはずの Web アプリケーションの自作自演説までが疑われ、捜査は大混乱に陥った......

という状況で、困惑していました。
この手のテストは実行に時間を要するだけに、目的が達せられないと、かなり精神的なダメージがあります。で、テスト結果を眺めたり、よりシンプルな Servlet に対しての負荷テストなどを試行したりしながら、問題点を探しました。
JMeter のリモート実行 PC については、Windows パフォーマンスモニターを開いていて、テスト実行中に、CPU 負荷や Memory 使用量に問題はなさそうだったし、そもそもそれほどのスレッド数を指示する前からスループットは頭打ちとなっているのです。 一方、Application Server も Database Server もシステムリソースは全く逼迫していません。もちろん、スレッドプールなどの設定面での限界にも遠く達していません。

しばらく八方塞がりの思考状態となった後、いくつかの試行錯誤の末、真犯人が特定されました。
結果的には、実際のリクエスト発行はリモート実行に委ねていたため疑いをかけてなかった JMeter の制御用 PC に、ボトルネックがあったのでした。
それは、Notrton Internet Secutiry と、11b の無線 LAN 接続に起因する現象でした。 この環境ではリモート実行用 PC 独自に実行した際の性能が出ておらず、Norton をオフにして有線 LAN 接続にしたところ、本来の性能が出るのです。
つまり、制御用 PC のリモート実行用 PC との間のコミュニケーションがボトルネックとなり、リモート実行用PC には余裕があるのに、Web アプリケーションへのリクエストがのんびりとしか発行されていなかったのです。
もちろん、パフォーマンス系のテストを行う際に、不確定要素を除外しておかなかった私は罪深いのでしょうが、それにしてもこれまでの測定作業が無駄になったのは痛い...

教訓。
事件は現場だけではなく、会議室でも起こる可能性がある。