谈如何提高性能测试效率之监控

从这一章开始，我想谈一下如何提高性能测试的效率。

之所以谈这个问题，是因为在实际性能测试的过程中，经常遇到这样的情形：一共就执行两个案例，执行了1个月也没执行出来一个可用的测试结果。

对于做性能测试的筒子们可能习以为常，但对应的其他人来说，是很难理解的；

功能测试的筒子们问：你们设计了多少案例

答：2个

功能测试的筒子们：@#￥%……&*，擦，我们设计了1万个案例。

老板问：你们这俩案例执行需要多长时间？

答：1个半月

老板：为什么？

从别人的角度，的确很难理解。我们除了无力的解释，还能做的就是如何提高性能测试的效率。

提高效率是从多个方面来提高：

1）需要准确把握系统和产品的特性，预见系统的性能表现和性能瓶颈点，以便设计合理的案例，以最少的工作量获取有效的、能说明性能表现、性能问题的测试结论。

2） 需要选取合理的测试策略，即满足性能测试模型的需求，又容易实现。例如并行的集群系统只选一个服务器测试，只选TOP5的交易进行测试，只选大表去铺设存量数据，用什么方法快速地制造存量数据等等。

3）选取合适的测试工具，快速地构造测试脚本，如何复用测试脚本。

4） 如何提高每次性能测试的成功率

经常做性能测试的同学比较清楚，一个案例可能需要跑10遍才能得到有效的测试结果，第1次，啊~我忘了监控数据库了；第2次，咦~业务报重账了；第3次，这次没问题了，吖~怎么性能这么差呀，1天以后，哦~日志级别设的太高了，那个是功能测试用的日志级别；第4次，这下肯定没问题了，啊？还是很慢，分析分析，CPU怎么跑到95%了，谁给看看，这CPU怎么才1颗呀。。。。。。

5）并发地控制所有被测系统和压力机，进行监控、执行和结果回收。

6）快速的提取和分析监控结果。

这一章，咱们先介绍如何从监控以及监控数据的分析的角度来提高效率。

通常，监控的内容包括：

1）系统的基本监控（资源利用率）

2） 系统软件的监控（数据库的监控（比如SQL执行时间、buffer命中率），各类中间件的监控）

3）应用的监控

4）压力机的监控（这一点很少有人做，那是因为压力还不够大，如果压力大到一定程度，你一定会关心压力机集群本身的承受能力。一台压力机如果CPU资源利用率达到85%以上，同一个场景跑两次，可能会得到差异较大的吞吐量，如果是对比测试，这种吞吐量的差异是不可接受的。）

最初，我们是怎么监控的呢？其实就是在系统上敲个nmon命令，把系统监控起来，Oracle打个数据库快照，回头测试完了我们在系统上敲命令或者软件上点鼠标把AWR报告拿下来。

可是，这种方法在做单个机器问题分析的时候还好，但面对一次测试N台服务器，总不能一个一个去敲命令吧。因此，相应的方法或者工具就需要配合了。

最简单的方法：

XShell、SecureCRT之类的工具，可以把一个命令同时发到N个窗口，这是最简单的方法。不过这种方法只能干一些简单的事情，复杂了就不行了。

工具法：

自己写个小工具，把N个服务器的IP口令配进去，把需要执行的命令填进去，一键触发。可以做：开始监控、停止监控、回收结果、提取关键的结果信息、结果合并。

这里，会有人问“市面上有很多现成的监控工具，开源的、商业的，直接用这些监控工具不就可以了吗？这些工具都可以同时监控N个服务器呀”。的确是有不少监控工具，可是有多少专业的性能测试的团队用这些工具呢？

主要原因在于，这些监控工具都是从运维的角度出发来设计的，并不是专门针对性能测试来设计的，监控粒度比较粗，不能满足系统性能分析的需求。比如，我想要13:09:32~13:37:12这段时间的VP利用率和虚拟CPU的折叠情况，能拿出来吗？比如我想要13:09:32~13:37:12这段时间XX进程的数量的变化规律，我想要这段时间XX队列的队列深度的变化情况，这段时间的数据库某条SQL一共执行了多少次？能拿出来吗？

可能你觉得并不需要这么细粒度的数据和分析，这个倒是事实。但如果你的测试对象是银行业金融系统，是单机高吞吐的业务模型，你会觉得这是必要的。