性能测试感悟

具体流程：

　　（1）需求评估

　　目的：评估是否需要做性能测试。

• 需要做性能测试

　　新产品要上线，预估单台机器QPS峰值超过100。

　　已经上线过的产品，由于接入了新的业务或者用户量增加，预估单台机器QPS峰值超过100。

• 不需要做性能测试

　　单台机器QPS峰值低于50的需求。

　　有相同产品实现逻辑的产品，且已经做过性能测试。

　　例如：假如一个请求，每次用户开启应用时都会发送到服务器，服务器则会返回给客户端本账号在好友中的积分排名情况。从产品的角度认为，每次应用启动，都会触发服务器查询一次数据库。这样会数据库会造成很大压力。而测试再了解了具体实现后发现：针对每个用户机器码的排序数据是从redis服务器返回的，而redis服务器会每隔一小时请求存储的mysql服务器来更新账号排名信息，这样看来mysql服务器请求频率很低，没有任何压力。由于redis服务器的性能之前已经测试过类似的，没有性能问题，所以这次并不需要对mysql服务器做压力测试。

• QPS评估方法：

　　产品已经灰度或者上过线，可直接参考灰度数据来推算全量用户的QPS峰值。

　　产品未上过线，可通过类似已上线的产品来评估线上QPS

　　以上两种都不符合，可通过通用算法来推算QPS。

　　计算模型：

　　每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量。

　　其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。

　　简单计算的结果：

　　((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒

　　（2）逻辑了解：

　　目的：产品、开发、测试相互认识，便于后续的沟通。

　　方法：在逻辑了解时，组织产品、测试、开发做需求评审及产品实现讲解会。

　　讲解会需要了解的点：

• 了解整个性能测试的业务逻辑。一般需要了解请求个数，请求参数含义，请求参数可取值等。

• 了解服务器部署情况，主要要和线上服务器做明确隔离。不要简单认为所有的请求都是指向测试服务器，就认为是只向测试服务器打压。主要分为三种情况:1、测试请求会经过跳转链接到线上服务器。2、测试请求的js会异步请求线上资源。3、测试服务器会经过逻辑处理后返回给客户端，而这里的逻辑处理可能包括到线上服务器处理或查询数据。

• 了解本次性能测试的测试目标QPS及推断方法。

• 了解本次打压的请求间和参数间比例关系，这样便于后续写脚本时能够尽量模拟线上用户行为。

　　（3）测试方案：

　　主要用来评估本次性能测试的排期。并以邮件通知到各方。

　　发送时机：开发实现讲解之后，用例设计之前。

　　模板参考：（见附录一）

　　（4）环境搭建：

　　1) 测试服务器的搭建的搭建。测试环境可以由开发来搭建。原则上测试服务器配置不能高于线上服务器的配置，且测试服务器部署的服务要尽量接近线上服务器，比如说线上服务器上运行了3个服务，峰值时会占用30%的cpu，那么测试服务器也要运行同样类似，且打压时cpu最高只能打到70%。这样得出的结果才具有指导意义。

　　2) 打压环境的搭建：主要指linux打压机的部署。具体部署方法就不在此赘述了，具体可以参照：http://www.51testing.com/html/13/n-3715213.html

　　3) 如果没有条件来搭建测试服务器，可否直接用线上的？

• 如果线上的服务器之前打过压力，可以直接用线上的压力指标来衡量是否满足本次需求。

• 如果之前没有打过压力，则在确认线上使用负载均衡的前提下，保证多台服务器中有一台挂掉后，其他服务器可以做到负载均衡压力，使线上用户不受影响时。可以对其中一台进行打压，在打压时需挑选线上用户非高峰时间段进行，且密切关注打压服务器情况，一旦挂掉，迅速启动起来。

　　（5）数据准备：

　　主要指性能测试有效数据的准备。请注意是有效数据？

　　举例：加入你手动写完脚本后，跑一下脚本，发现服务器返回没有报错。都是200的response。这是否就说明是有效的打压呢？未必！应该回放脚本时，通过抓包工具抓包看下，对比真正使用场景中返回的response。看下内容格式是否一致。如果你的打压脚本返回的是空的200请求或者仅仅有关键字，但是内容都是空的，而真正场景返回的是大小为15K的json。这说明你的打压场景是有问题的。

　　如果出现问题：应该和开发沟通原因，最后让打压请求返回正确的数据。

　　准备测试机的查看权限。服务器log位置及信息。主要信息包括服务器响应时间，出错log标示，具体客户端请求信息。

　　（6）脚本开发：

　　根据上面获取到的逻辑和数据进行脚本开发。视个人习惯，可以使用录制方式和手动写脚本。但是需要注意一点，在保证尽量模拟用户行为的前提下，尽量使脚本简单。如if语句和for循环。这类语句在高并发下，本身就可能导致压力机性能问题。

　　（7）打压过程：

　　打压过程并不是放那里不管，通过linux系统提供的命令，需要时刻关注被测服务器的性能指标，结合LoadRunner场景的曲线来动态判断是否存在瓶颈。LoadRunner场景曲线主要关注HPS、TPS、responsetime。服务端主要监控cpu、内存、磁盘IO、网络IO。然后从这几方面再层层深入查找问题。另外，值得强调的是，打压过程不仅需要关注被测服务器的指标，也需要关注打压agent的性能指标是否正常。比如说如果并发数一直上不去，可能是打压机本上连接数受限导致的。也可能是打压机自己出口带宽满了导致的。

　　（8）问题定位&修改优化&回归：

　　问题定位是一个比较考验个人综合技术能力的地方。也是整个性能测试的核心所在。需要强调的是，不是看到某个参数遇到问题了，就直接可以断定服务区的瓶颈就在这个地方。比如：

• 大量的页调入请求导致内存队列的拥塞

• 网卡的大吞吐量可能导致更多的CPU开销

• 大量的CPU开销又会尝试更多的内存使用请求

• 大量来自内存的磁盘写请求可能导致更多的CPU以及IO问题

　　具体是哪个部分的问题，需要再根据具体的逻辑实现和推断来逐步缩小范围。主要的过程可以参考一下步骤层层深入。服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

　　最后就是开发优化，测试回归，这里需要强调一点：测试回归时，如果开发优化时修改了功能逻辑，则需要根据改动回归功能逻辑是否正常。不能只盯在性能指标满足了就OK了。

　　（9） 性能报告：

　　性能测试报告没有固定的格式，但是大体需要包括以下几个方面：

　　整体结论：本次性能测试的整体结论。是否符合预期，是否可以上线。

　　具体推算方式：主要指给出整体结论的参考数据、计算公式等。

　　具体性能图标：服务器cpu、内存、网络IO、磁盘IO、TPS、responsetime等指标，涉及到数据库的还需要给出与数据库相关的指标。