如何判断性能问题是出自应用中间件？

经本人实地调研发现，运维监控、甚至是专门的性能测试中，最容易漏掉监控的就是“应用中间件”和“存储”。
往往是出了问题，把所有可能怀疑遍了，也没发现什么可疑之处，比如cpu利用率不高、网络带宽占用率很低、读写磁盘IOPS不多、数据库响应时间很短，应用的并发数量也充足，可就是业务响应时间很长，吞吐量很低。甚至把硬件配置的一堆参数也分析的透彻，这时候才想起了中间件。

从上面的场景中，其实可以发现，从系统拓扑的角度，前端->中间件->应用->中间件->数据库的包抄当中，如果你发现其他都没有问题，那很可能就是中间件的问题了。
或者从系统层次的角度，应用->系统软件（中间件、数据库）->OS->硬件/网络这条线上，如果其他都没问题，那也得看看中间件了。

我比较主张，一旦遇到性能问题，或者平时关在测试环境里做的性能测试，只要是涉及到应用中间件的、并且有压力的，一定要做好中间件的监控，在所有监控数据都全面的时候，判断问题才得心应手。就好比去医院，说了病情，大夫一般什么结论也不会给，而是开一堆检查单化验单，你先做N个检查，我看看。

具体看中间件什么指标呢？
最直观的指标就是响应时间：这里的响应时间指的是业务在中间件中的响应时间
例如WAS可以监控到众多的这方面的响应时间，有
1）ServiceTime：完成servlet请求的平均响应时间（毫秒），
2）ResponseTime：接收到请求和对方应答之间的平均时间，
3）RequestResponseTime：接到请求与分派执行之间的时间，
4）DispatchResponseTime：从分派执行到返回应答之间的平均时间。
5）等等

可以先关注ResponseTime（接收到请求和应答之间的平均时间），如果这个值出现异常，那就说明业务在中间件中的这段处理可能有问题，这段时间包括了收到请求到分配执行的时间，包括了应用等待数据库连接池的时间、包括中间件调用数据库执行时间等等，然后我们再分段分析哪里出现了问题。如果ResponseTime较长，而从数据库上查看SQL的执行时间很短，那么8成就是中间件里面的时间长了。