本文作者：二鱼，转载至微信公众号：测试进化营
作为非专业后台开发的测试，在过往码代码的经历中从来都不需要考虑什么性能、压测。最近工作中，一项测试后台服务被人“看上”了，身兼开发&测试双重重任，无奈开启了后台服务性能优化之路。
导言
要使后台服务能够支撑更大的并发请求，首先要搞清楚几个问题：
1. 衡量后台的性能指标有哪些？
2. 后台支持的最大并发量是多少？
3. 服务的性能瓶颈在哪里？
4. 如何提升后台性能并验证优化效果？
后台服务性能指标
衡量后台服务的性能通常有以下几个指标：
• QPS(吞吐量)——系统每秒可以处理的事务数
• 并发数——系统同时处理的事务数
• 响应时间——通常是服务平均响应时间
QPS同时取决于单个请求的响应时间和并发数：
1）并发数的大小跟响应时间无关，可以通过增加机器数提高服务的并发数
2）对单个机器而言，并发数取决于后台服务的进程数和线程数
3）单个请求的响应时间会受到后台压力的影响。如果不断增加后台服务的压力使系统处于超负荷工作，会导致单个请求对CPU消耗和IO处理的响应时间更长
在性能优化之前，首先要对后台服务进行压力测试，找出当前的性能瓶颈
如何做后台服务压力测试
后台服务压力测试根据后台的服务类型有不同的测试方法，通常的后台服务类型有http、 ftp后台服务、数据库等。通常HTTP后台服务压测时会选用免费工具Jmeter。下面简单介绍下如何用Jmeter做压力测试。
Windows下Jmeter的安装
(1)Jmeter安装包下载地址
http://jmeter.apache.org/download_jmeter.cgi
(2)将下载包解压后，设置好环境变量
JMETER_HOME=D:\apache-jmeter-2.13(此处填写解压后的地址)
PATH=%JMETER_HOMR%\bin;%PATH%;
(3)命令行启动Jmeter：jmeter
Jmeter核心组件
1）测试计划：测试的起点（默认有，可新建）
2）Sampler：不同类型测试
3）线程组：设置虚拟用户，线程数为虚拟用户数, Ramp-Up Period 指定创建全部线程的时间，例如线程数为5，等候时间为10秒，则创建每个线程之间的时间间隔为两秒；循环次数定义了线程组的运行次数，如设置为永远则请求一直执行下去，直到手动停止；调度器设置运行的起始时间
4）监听器：测试结果分析
配置一项完整的压力测试
Step1:默认会有一个测试计划，添加线程组，设置需要测试的线程数
以上图为例，这里设置了3个参数：
1）线程数：压测发送到后台的线程数为500
2）Ramp_up 时间：线程启动的时间为1s
3）循环次数：一次线程数启动完成之后，重复压测的次数1
因此，此次压测并发量是500次/秒
Step2:添加http请求类型。根据测试对象设置http请求的后台服务IP地址，端口号请求路径以及上传到后台的文件参数
Step3:添加结果分析。Jmeter中可以添加多种结果分析类型，通常用的比较多的是查看结果树和聚合报告；查看结果树种可以看到每个请求具体请求参数以及返回结果信息。
聚合报告中可以查看汇总压测情况
上图各项指标的含义说明如下：
1）Label：请求类型，如设置Http，FTP等
2）Samples：样本数目，总共发送到后台服务的样本数目
3）Average：平均值，是总运行时间除以发送到后台服务的请求数
4）Median：中间值，是代表时间的数字，有一半的后台服务响应时间低于该值而另一半高于该值
5）90%line：是指90%请求的响应时间比所得数值要小
6）Min：后台服务响应的最短时间
7）Max：后台服务响应的最长时间
8）Error%：请求的错误百分比
9）Throughput:图形报表量，这里是后台服务每单位时间处理的请求数，注意查看是秒或是分钟
Step4：分析测试结果
具体分析当前压测结果，找出当前服务的瓶颈，根据调优思路给出测试结论。比如下图，从查看结果树可以看到在当前同步请求机制下，当增加后台服务并发量之后部分请求后台会返回500错误
聚合报告中可以看出当前吞吐量和错误率。
后台优化方案有哪些
根据前面后台服务的调优思路以及当前后台服务的特性，有4种优化方案：
1） 增加后台服务的进程数和线程数
通过几组参数设置测试之后发现：在当前并发量为300时，把后台服务的线程数增加1倍，吞吐量并没有得到提升，错误率反而增加了；
当把后台服务的进程数增加到8个时，错误率达到最低，但是增加到16个时，错误率又上来了；这是因为不断增加进程数和线程数，不仅不会继续继续降低错误率，反而因为超出后台最大负荷，导致请求错误率的提升。故增加服务进程数和线程数需要适当！
2）减少后台服务端的I/O操作
后台服务端的I/O操作通常比较耗时，会延长服务的响应时间。 我们的后台服务涉及文件传输，必定有文件I/O操作，通过查看代码发现原先的服务有3次文件I/O操作，优化后我们将请求接口中获取的文件参数直接传递给核心程序，并且只针对需要保存的进行写入操作。实际上需要做保存的文件毕竟是少数，优化后至少可以降低一半的I/O操作耗时
3）采用消息队列的异步请求机制
A.异步请求
优化了I/O操作后吞吐量并没有达到预期。经分析，实际上我们提供的服务，处理的返回结果对实时性要求不高。接下来我们针对文件上传请求和核心服务分别做了测试，发现主要的耗时操作在核心服务。因此我们将核心服务单独剥离出来——从同步请求优化成异步请求；收到请求后，将文件参数传给核心程序并立即启动处理，但不再等待核心程序处理结果便给前端返回Request接收成功的Response。核心程序处理完成后将结果写入到缓存后台服务中。前端等待一段时间后，通过查询接口查看处理结果。
B.消息队列
请求接口在短时间内收到大量请求后会针对每个请求启动一个核心处理任务，这里是通过celery的消息队列来管理核心任务。收到上传请求后，创建一个job任务，任务都放在消息队列中；任务调度器将消息队列中的任务分配到各个worker中执行，多个worker之间是并行执行；任务执行完成之后将结果缓存在Redis中；全部任务执行完成之后，前端调用查询接口从缓存中去查询结果。
3)增加后台服务机器的数量
最直接最有效的方法当然是多部署几台服务器。当然这个费钱，穷时慎用！
