“数据库（或中间件）非常慢了，如何监控它的性能”

　　“你想得到什么性能指标？”

　　“是……内部的性能指标”

　　收到性能测试人员这样的问题后，通常会发生上面的对话。

　　我的观点是，准确的说出你想要做什么，比你会不会做更重要。

　　那么对于性能测试人员来说，”性能监控“这门必修课，该从何下手呢？

　　监控什么

　　如果我给你一个黑盒子，告诉你里面是一部机器，要监控它的性能。你能做到么？当然不能。因为你不知道这部机器如何运行，你不知道对它而言性能是什么。

　　性能测试也一样，说到操作系统，大家都知道性能指标要看CPU、MEMORY、DISK IO以及NETWORK等等。但是到了数据库和中间件，如果测试人员说不出具体内容，这表明他不知道针对这个对象，性能是什么，即便把完整的性能指标摆在面前，恐怕也是没有意义的。

　　当然知识和经验是一步步积累起来的，但也需要测试人员去主动的学习。从系统体系结构、运行原理到性能监控、性能调优基础和方法，官方手册总是好的教材。

　　那么在没有掌握这些知识之前，我希望上面的问题是这样问，“数据库（或中间件）非常慢了，一般需要监控它的哪些性能指标呢”，得到回答后赶紧翻资料吸收相关的知识。

　　过程中的监控

　　性能测试新手容易忽略测试过程中的性能监控，而只给出一个终的测试运行结果。

　　比如这个问题，“测试运行3小时后，系统没有响应，中间件无法连接”。

　　对于这样的问题，期望开发人员如何处理呢？中间件已经无法连接，想获取到一些内部的性能指标恐怕都已做不到。只有重运行一次，让开发人员来关注过程中的运行状况，但这本应是由测试人员来做的。

　　如果我们知道，中间件本身无法响应一般可能是因为这两个问题：

　　JVM堆内存用满，不停的进行GC，导致响应超慢（但是还没有OOM，否则报错了）

　　处理HTTP请求的线程，都被占用或者锁住

　　那么我们可以在测试过程中去监控这两项数据，跟踪变化趋势，直到系统再次无法响应。如果正好其中的一个资源也耗尽了，那么可以确认“无法响应“这个现象的直接原因。实际上，这两个指标基本也是中间件重要的指标，理应每次测试过程都进行监控和数据采集了。

　　监控的层次

　　系统的性能表现会涉及到多个层面，比如：

　　中间件 -> 中间件操作系统 -> 数据库 -> 数据库操作系统 -> 客户端

　　监控时也要着眼于多个层面，这样才有可能更接近问题的本质。还是上面那个中间件无法响应的问题，假设我们观察到了所有HTTP线程都被占用，也许更进一步我们又会发现这些线程都在执行数据库的查询，而这些查询在数据库中的状态依然是running，那说明更根本的原因是在数据库层面。这也是问题的逐步定位。

　　全面的监控

　　片面的数据不足以说明问题，系统的方方面面常常是相互影响的。

　　比如数据库的CPU占用很高，并不能证明系统是计算密集型、CPU是瓶颈，也有可能是spinlock的争用导致了CPU骤增。

　　再比如大量的page-in IO可能会使内存出现瓶颈。

　　上面的层次问题其实也属于”全面“的范围。只有拿到全面的数据，才有可能分析出正确的结论。

　　当然，这又是一个需要积累的过程，如果连spinlock都不知道，又怎么可能有准确的判断呢。

　　方法还是一个，主动的学习，系统的学习。