Tomcat 6的MBean Catalina:type=GlobalRequestProcessor,name=http-0.0.0.0-8080对于属性processingTime的意义是什么？
据我了解，这意味着自启动以来特定连接器的处理时间（以毫秒为单位）。但是当我每分钟测量这个值时，我偶尔会得到远大于60k的值（即我得到delta值高达1000k）。
我的问题是，测量的是什么毫秒。实时或CPU时间？所有连接器线程的处理时间累计？
监控processingTime的最佳门槛是什么？
答案 0 :(得分：4)
查看代码，这是处理每个传入请求所需的System.currentTimeMillis()所测量的挂钟已用时间的累积毫秒数。因此，对于始终忙碌的单个http连接器线程（在具有稳定系统时钟的系统上）的此测量值不应每分钟增加超过60,000。但是，对于GlobalRequestProcessor，它可以比这更快地增加，具体取决于正在处理的并发请求数。
如果在给定的一分钟内，您在一秒钟内收到100个满意的请求，并且在返回值之前另外100个请求阻止了10秒，那么GlobalRequestProcessor的此计数器将增加100x1x1000 + 100x10x1000 = 1,100,000 in那一分钟。
请注意，由于这会测量挂钟经过的时间，因此如果服务器上的时钟向前跳跃，则会导致错误地获取经过时间的大值。也就是说，如果在给定的servlet处理期间时间向前跳过一分钟并且servlet花了20秒来处理请求，则此测量将告诉您servlet花了80秒来处理请求。如果您在DST“Spring Forward”发生时碰巧有实时请求，那么您将被告知该请求需要一个多小时，这意味着此JMX测量将增加一个多小时。对于我看过的版本，如果时钟向后跳，你可以最终减少这个计数器！希望Tomcat 6使用System.nanoTime()来避免这种对系统时钟稳定性的依赖。
在Java 1.5之前，没有一种好的方法来衡量真实的经过时间（而不是经过的挂钟时间）。由于Tomcat 6.x及更早版本都不需要Java 5或更高版本，因此它们无法测量除毫秒之外的任何其他内容，也无法测量与时钟更改无关的实际经过时间。 （除非使用反射来做到这一点。我没有注意到，但我也没有搜索过它。）