性能测试初探

目前已经对两个不同的C/S架构产品的Server端进分别进行过一次性能测试，慢慢开始对性能测试有了初步的认识，下面大概分享一下我们小组的性能测试过程。

过程

性能测试开始之前会和开发讨论，目的就是要确定真实业务场景下的各种相关数据的量级，最终计算出预期多少QPS才可以应付业务场景的需要。当有了预期的QPS作为一个性能目标后，就可以开展性能测试了（根据业务需求不同会有各种不同的指标要求，可能是一个，也可能是多个）。

这里性能测试使用的是Jmeter，Jmeter的优点很明显，就是简单易用，可以快速搭建分布式测试环境，通过水平扩展增加测试机器来增加对Server的请求压力，把Server推向它的性能转折点。

机器资源在性能测试中是一个比较重要的东西，因为机器配置的好坏或者机器的多少就已经决定了你能对Server造成多大的压力，不同机器之间的配置是越接近越好，因为Jmeter的分布式测试是不存在调度一说的，只是简单地通过一个Master对配置好的所有Slave发送测试计划jmx文件，然后Slave会去执行测试计划（Slave也可以是Master自己）。如果Slave机器之间的性能差距太大，那么性能差的机器就会成为短板，导致性能相对好的机器无法最大程度发挥性能。

分析

1. 机器资源

继续上面说的机器性能，为什么说性能差的机器会成为分布式测试环境中的短板呢？因为每一台Slave执行的测试计划都是一样的，都要发那么多请求，起那么多线程，一旦消耗的资源超过机器承受范围，该机器发送的请求数量和质量就无法达到预期，总请求数势必变少，也就无法知道并发数等重要指标是否满足，从严谨的角度出发，这一次测试结果是作废了。

所以，分布式环境中性能差的机器会成为测试计划里的短板，使得测试计划的各项参数被遏制在某条线之下。另外，Jmeter的分布式环境应该选用性能最好的机器作为Master，Master所做的工作肯定是比Slave要多的，如果Master性能不好，会造成Jmeter客户端的假死，导致本次压测数据作废，甚至可能得到一些偏差较大的数据。

个人真实经验：用了一台很谜的机器做Master，导致多次测试无法正常结束，浪费时间，后面换了一台好的机器做Master，压测都是一次过，在调到更大请求压力后看到的响应时间甚至比没换Master之前相对更低压力的响应时间更快，所以Master也会对测试数据有影响，应该谨慎挑选。

2. 通过重复测试来分散风险

道理非常明显，单次的测试结果存在较大的偶然性，这些偶然性可能来自于你的测试数据，可能来自于Slave的资源状态，也可能来自于网络……为了降低各个方面的风险，重复测试当然是必须的，至少重复三次取一个平均值，而且要特别关注明显异常的数据，比如某个数据突然变高或变低，要思考一下可能的原因，而不是直接舍弃这一次结果鲁莽地开始下一次测试，谁也说不准里面是否就有一个bug。

3. 调整测试计划

性能测试本身不仅仅是为了验证Server的性能指标是否达到预期，找到Server的性能转折点也是一件重要的事情，需不需要准确定位这个转折点就要看业务需要了。

如何通过调整测试计划来发现这个转折点？以Jmeter来举例子。

1. 线程数n
2. 发送请求的时间区间t——我理解为在t时间区间内，会逐步启动共n个线程并发出请求
3. 线程循环次数i——也就是总共多少个区间t，因为循环i次，总共就会发n*i个请求

以单个请求的平均响应时间为标准，由于线程在t区间内就会全部启动造成并发（可以粗略看成并发数为n/t），如果单请求平均响应时间大于区间t，则代表代表Server在区间t内已经处理不过来这么多请求了，就会造成请求的堆积。

为什么说Server处理不过来？

拿第一个启动起来的线程来看，本身预期该线程的请求在t区间内返回是没有问题的。但是，假如该线程发出的请求对应的响应时间大于t，则代表该响应在一个大于t的区间内依然算一个并发数，也就会影响到下一个区间t，结果是下一个区间t的并发数会受到来自上一个区间的叠加，最后导致在某个不知道的时间区间内，并发数会大于n/t，这对我们来说既不准确也不可控。

除了以响应时间作为判断转折点的依据之外，Througput也可以作为参考。

另外，应该特别注意一下总请求量，一旦发现总请求量不足预期，很大可能是机器资源不够了，此时只能把参数调低，继续往上压已经不现实。如果请求量比预期要多（这个我们遇到，谜之问题），可以先检查csv配置文件是否正确，csv里的数据是否充足，可以看看Jmeter发出的不同请求有没有发生内容的重复，再根据这些已知条件去排查。

4. 测试数据的准备

很多时候构造请求是需要数据的，可以根据数据库的运作特征来构造数据，从而相应地验证数据库的增删改性能，也可以根据Server逻辑来构造，从而触发Server的不同业务路径。但是构造数据务必要合理，以真实业务场景为依据。

其他

应该对一次性能测试怎样进行记录呢？可以有如下点：

• 核心测试计划的各种指标数据
• 存在性能问题的方案
• 优化修改后的方案
• 优化前的指标数据和优化后的对比指标数据

拿到上面的数据，就可以分析得出性能测试的结论，清晰可观地知道这一次性能测试产生一些什么样的积极意义了。