上周六是我们TestOps性能进阶课程第八天——性能测试实战的学习。这一天的课程是由测试行业的大牛叶微微老师为我们带来的，必须是干货满满。老师教大家一起学习企业级的性能测试应该如何做，这里芒果一如既往的抽出其中一部分内容跟大家介绍~
需求点的选取
首先芒果要介绍的是需求点的选取。
需求点的选取第一个要做到的就是明确需求：要了解本次性能测试的背景以及当前项目的现状；要此次清楚性能测试的目的；要根据业务的紧急程度，系统是第一次上线还是迭代升级，服务队性能的要求等情况，来选择是上线前进行性能测试还是上线后。
第二个要做的是明确压测范围：到底是对页面进行压力测试，还是接口进行，或者是对场景的压测；明确是对哪些页面、接口或者是场景进行测试。
第三个也是最重要的一点就是熟悉被测业务：要熟悉被测的模块，要熟悉被测系统的系统架构、业务形态，要了解系统的缓存机制、消息队列；要知道被测的业务有什么特点，到底是cpu密集型还是io密集型；对于接口的性能，要对接口逻辑、数据流、接口服务依赖、基础依赖的流程进行详细了解。
性能测试的指标
第二个要给大家介绍的是性能测试的指标。一般来说企业级系统的性能指标一般从吞吐量（每秒系统能够处理的请求数、任务数）、响应时间（服务处理一个请求或者任务的时间）、错误率（一批请求中结果出错的请求所占的比例）、资源消耗（服务处理请求消耗的资源，如CPU、内存、IO等）来考虑。
在这里叶老师给大家展示了，他所在企业的某个测试项目的性能测试指标：
叶老师还给大家介绍了常用的QPS（单个进程每秒请求服务器的成功次数）、PV（page view，即页面流览量）和需要部署机器数量计算公式。
术语说明：
QPS = req/sec = 请求数/秒
QPS计算PV和机器的方式：
QPS统计方式 [一般使用 http_load 进行统计]
QPS = 总请求数 / ( 进程总数 *请求时间 )
单台服务器每天PV计算：
公式1：每天总PV = QPS * 3600 * 6
公式2：每天总PV = QPS * 3600 * 8
峰值QPS和机器计算公式：
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间（虽然有些时候二八原则不是很准确，但是在叶老师这次举例的项目二八原则是符合要求的）
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
简单举例
问：每天600w PV 的在单台机器上，这台机器需要多少QPS？
答：( 6000000 * 0.8 ) / (86400 * 0.2 ) = 278 (QPS)
问：如果一台机器的QPS是100，需要几台机器来支持？
答：278 / 100 约等于 3
性能测试案例
然后叶老师还给大家展示了这个项目的部分性能测试案例，并对这些案例进行了详细分析。在介绍的过程中叶老师提到对于内部服务接口，页面请求接口可以通过一些测试工具或者抓包工具去获取到，也可以通过跟开发沟通来拿到这些接口，然后根据具体业务来确定是哪些。对于接口性能测试，一般情况下接口会特别多，所以不会都测，主要是有可能出问题跟核心接口，要分优先级，其余的可以使用自动化接口，或者使用测试平台进行测试。以下是部分测试案例的截图，以供大家参考：
监控工具nmon
这次的实战项目的测试执行是使用Jmeter进行的，由于之前我们有对Jmeter进行深入的学习，芒果在这里就不过多的介绍。介绍一下叶老师在项目中使用的监控工具nmon：
Nmon可以对被测系统的CPU占用率、内存使用情况、磁盘IO、网络IO、文件系统使用率、进程消耗进行监控。分别输入 c、t、n、m，可以了解系统 CPU，Memory，消耗资源最高的线程的使用情况：
如果想要实时监控系统在一段时间内的使用情况并将结果记录下来，我们可以通过运行以下命令实现:
#./ nmon -f -t -r test -s 30 -c 180 l test:这次监控记录的标题，与生产的文件名称 l -s 30:每30秒进行一次数据采集 l -c 180:一共采集180次 以上就是 nmon 记录了系统在 1.5 小时内的使用情况输入命令后，将自动在当前目录生成一个hostname_timeSeries.nmon 的文件（hostname为当前服务器的主机名，如:hosname为dell，生产的文件为:dell_090320_2213.nmon）。
可以通过以下命令将 nmon 结果转换为 csv 文件: # sort -A dell_090320_2213.nmon > dell_090320_2213.csv 即可在当前目录生成 test1_090320_2213.csv 文件。我们将 dell_090320_2213.csv 文件下载本地，通过 nmon_analyser 工具转换为 excel 文件，此时打开 excel 文件，我们即可通过图形化方式查看到系统的运行趋势图了。
常见问题处理
接着芒果要给大家介绍的是叶老师传授给大家的，对于性能测试过程中一些常见问题的处理方式：
1、服务器、压力机资源都没问题的情况下，压力上不去是什么原因造成的？
1）用另一个接口进行压测，看压力是否没问题，来排除是程序还是环境问题；
2）如果是环境问题，因环境都是虚拟机，换个压力机或服务器，看下是否正常；
3）查看中间件等配置参数，确保中间件的配置无误；
4）通过工具查看网络是否有问题；
5）如果是程序问题，查看log，打印出每个节点的响应时间，看具体响应时间长在哪。
2、出现问题，如何排查是否是代码还是数据库问题？
打印出详细的log可以看出。
3、设置场景时，怎样设置思考时间或pacing更合理？
分场景来定，如果需要测拐点，可以不用设置，如果需要模拟真实场景，则需要设置； 思考时间是每个脚本中间设置的，pacing的话，则是在一个迭代结束后，等待pacing设置的时间后，再开始另一个迭代。
4、如何测试dubbo接口？
loadrunner测的时候，将dubbo外封装一层http的包，用http协议测试 jmeter测的时候，将dubbo接口配置，写一个java脚本，打包成jar包，放在jmeter的lib的ext目录下，用java协议测试。
5、什么场景下会用到集合点？
一般不建议用集合点，除非是秒杀等相关场景下才会用到集合点。
6、同一脚本，场景配置全都一样，可结果不同，有哪些原因？
一般情况下，都不会一模一样，差不太多的话也算是正常 但是如果差距很大，就需要排查问题了，可能原因有：cpu、内存、io等相关资源，redis缓存，网络等。
7、在无指标的情况下，如何判断该条用例是否通过？
1）响应时间，看是接口还有页面，接口的话基本在几十毫秒到几百毫秒之间，如果时间太长，还是需要进行优化的，如果是页面，基本遵循二五八原则；
2）用户数基本分是单服务还是集群来分开测，单服务50～200用户，集群基本300～500用户；
3）服务器资源，一般不建议超过80%，因为如果一台服务挂了，另外的服务器可以接收这台服务器的所有请求；
4）成功率，一般成功率支持99.99% 如果以上都没问题，那可判断该用例通过，否则失败，需排查原因及调优。
8、tps或响应时间偶尔出现一个大的抖动，如何排查具体原因？
监控当时的网络及服务器、压力机等资源，是否因为环境造成。
9、tps或响应时间出现很规律的上下抖动，如何排查具体原因？
之前测试https的时候遇到过，上下抖动很规律，当时主要原因是lvs的问题，逐个在外网、lvs测试相同场景，可查出，后来运维优化lvs后，问题解决。
10、查询单个商品接口没问题，但改成多个商品后，压力上不去，如何优化？
当时测试批量查询价格接口时，压力上不去，了解程序是同时获取24个商品查询价格返回，如果缓存中仅有几个商品没有，也还是会去库里获取全部数据更新到缓存内再返回，后优化成：先mget到所有数据，如果查询到部分是空的，则再去数据库获取部分数据，将获取到的数据更新到缓存内再返回。
性能测试小诀窍
最后芒果要给大家介绍的是叶老师在做项目的过程中介绍的一些小诀窍：
日志相关：去除无用日志（整体优化，提升IO性能），去除debug级别日志，去除重复的日志输出。
数据库相关：增加数据库连接数（提升DB处理性能，改善接口性能）依据慢SQL（DAO操作耗时可查看**time-handler**.log）以及业务场景，增加索引/重建索引（提升DB处理性能），索引优化（组合索引优于多个单索引）。
代码相关：通过日志文件，找出耗时较长的功能代码块，进行业务代码优化（整体优化），去除无用代码。
接口相关：增加dubbo线程池大小（默认200）及客户端调用方法的超时时间（客户端与服务端超时时间相匹配），提升duboo接口性能（提升台账和促销接口性能）增加项目部署节点（响应时间正常但CPU过高）CUP负载不均匀。
Nginx相关：调整nginx负载策略磁盘空间不够影响处理性能，降低TPS，及时清理日志文件（不要rm 或者 mv，执行 echo "" > xxx.log）。
JVM相关：分析进程堆栈信息（CUP使用率过高时可分析部分原因）
./usr/local/java/jdk1.7.0_80/bin/jstack -l pid |sort | uniq -c |sort
