Глядя на код, это совокупные миллисекунды времени настенных часов , измеренного System.currentTimeMillis(), необходимого для обработки каждого входящего запроса.Таким образом, это измерение для отдельного потока коннектора http, который всегда занят (в системе со стабильными системными часами), не должно увеличиваться более чем на 60 000 в минуту.Однако для GlobalRequestProcessor он может увеличиваться намного быстрее, чем это, в зависимости от того, сколько одновременных запросов обрабатывается.
Если в течение данной минуты вы получите 100 запросов, удовлетворенных за одну секунду, и еще 100 запросовэтот блок в течение 10 секунд, прежде чем вернуть значение, то этот счетчик для GlobalRequestProcessor увеличится на 100x1x1000 + 100x10x1000 = 1 100 000 в эту минуту.Сервер переместится вперед, это приведет к тому, что вы получите ошибочно большие значения за прошедшее время.То есть, если время переходит вперед на одну минуту во время обработки данного сервлета, и сервлету потребовалось 20 секунд для обработки запроса, это измерение скажет вам, что сервлету потребовалось 80 секунд для обработки запроса.Если у вас есть живой запрос, когда происходит DST «Spring Forward», то вам скажут, что этот запрос занял более часа, а это означает, что это измерение JMX будет увеличиваться более чем на один час.Для версии, на которую я смотрел, если часы отскакивают назад, вы можете уменьшить счетчик!Надеемся, что Tomcat 6 использует System.nanoTime(), чтобы избежать этой зависимости от стабильности системных часов.
До Java 1.5 не было хорошего способа измерить истинное прошедшее время (в отличие от настенных настенных часов). время).Поскольку ни один из Tomcat 6.x и более ранних версий не требует Java 5 или более поздней версии, на самом деле у них нет способа измерить что-либо, кроме миллисекунд, или измерить истинное истекшее время, которое не зависит от изменений часов.(Если для этого не используется рефлексия. Я ничего не заметил, но и не искал.)