Catalina:type=GlobalRequestProcessor,name=http-0.0.0.0-8080属性に対するTomcat6のMBeanの意味は何processingTimeですか？
私が理解している限り、これは特定のコネクタの起動からのミリ秒単位の処理時間を意味します。しかし、この値を毎分測定すると、60kよりはるかに大きい値が返されることがあります（つまり、最大1000kのデルタ値を取得しました）。
私の質問は、何ミリ秒が測定されるかです。リアルタイムまたはCPU時間？蓄積されたすべてのコネクタスレッドの処理時間？
監視するための適切なしきい値は何でしょうprocessingTimeか？
コードを見ると、これは各着信要求を処理するために必要なウォールクロック経過時間の累積ミリ秒です。System.currentTimeMillis()したがって、(システム クロックが安定しているシステム上で) 常にビジーである個々の http コネクタ スレッドのこの測定値は、毎分 60,000 を超えて増加することはありません。ただし、 の場合、GlobalRequestProcessor処理される同時リクエストの数によっては、それよりもはるかに速く増加する可能性があります。
特定の 1 分間に、1 秒間に満たされた 100 のリクエストと、値を返す前に 10 秒間ブロックする別の 100 のリクエストを受信した場合、このカウンタGlobalRequestProcessorはその分で 100x1x1000 + 100x10x1000 = 1,100,000 増加します。
これは壁時計の経過時間を測定するため、サーバーの時計が進むと、経過時間の値が誤って大きくなることに注意してください。つまり、特定のサーブレットの処理中に時間が 1 分進み、サーブレットが要求を処理するのに 20 秒かかった場合、この測定値は、サーブレットが要求を処理するのに 80 秒かかったことがわかります。DST の「Spring Forward」が発生したときにライブ リクエストが発生した場合、そのリクエストに 1 時間以上かかったことが通知されます。つまり、この JMX 測定値は 1 時間以上増加します。私が見たバージョンでは、クロックが逆方向にジャンプすると、このカウンターが減少する可能性があります! うまくいけば、Tomcat 6 はSystem.nanoTime()、システム クロックの安定性への依存を回避するために使用します。
Java 1.5 より前のバージョンでは、実際の経過時間を (壁時計の経過時間とは対照的に) 測定する良い方法がありません。Tomcat 6.x 以前はいずれも Java 5 以降を必要としないため、ミリ秒以外のものを測定したり、クロックの変更に関係なく実際の経過時間を測定したりする方法は実際にはありません。（これを行うためにリフレクションを使用しない限り。私は気づいていませんが、検索もしていません。）