基于Jmeter与python，建立半自动化压测流程 （一）

简单记录一下实施过程与踩过的坑

1.背景介绍

本公司与某客户的项目，为docker单机部署。部署服务器为AWS。主要分为三个服务：算法模型服务，Redis服务和爬虫服务。客户主要想知道当前硬件环境下混合接口测试时系统可承受的最大TPS，开发团队想知道系统可以承受的最大并发。故产生此次测试需求。

因为墙的原因，施压服务器从以往的阿里云转为两台AWS，硬件指标与被压测环境服务器一致，4核CPU，64GB物理内存，均为千兆网卡。

根据长期压测经验，压测工具选为开源工具Jmeter。数据分析与脚本控制选择python写脚本。硬件监控采用AWS自带监控，nmon配合使用。

此处需注意，Jmeter为Java开发，虚拟用户模型实现基于线程，耗用系统资源比较高，需根据压测机物理配置对应修改Jmeter的配置文件（通俗说Jmeter本身也需要进行JVM调优。）Jmeter官方文档内我没有找到推荐配置，故按照JVM一般调优原则进行配置。

Jmeter有一个很容易被误解的概念，此处也做一下说明。

Jmeter中的并发和用户数没有必然联系。用户数实际为Jmeter此时开启了多少线程。理论上如果你不设置TPS控制器，这些线程会尽最大努力去发送请求。而1s内你设置的这些用户数发出了多少请求，可以理解为“此时的1s内并发数”。我们都知道现实中不太可能出现理想的真正并发，我们要始终明确：我们的目的是找瓶颈，不是纠结到底有多少真正的并发。

我们这次实施时，通过不断增加用户数和JVM调优，在当前单台测试机上获得的Jmeter最大线程约为11000。测试中发现此配置已经足以满足此次测试需求，故只用单机跑压测就可以。需要的话可以上分布式测试，Jmeter官网文档有详细配置说明，很简单，不再赘述。

！此处有疑惑：我们获得11000active线程的数据时，施压机硬件配置仍绰绰有余，但是jvm此时无论如何调整，均不能获得更多active线程。我没有找到解决办法，有知道的可以告诉我一下，谢谢。

2.实施过程

务必注意，压测的实施只是手段，最重要的是结果分析与系统瓶颈寻找。不论过程如何实现，永远要记住我们的目的是什么。

测试中需始终注意的其他方面：

*确保施压机本身不会出现硬件瓶颈。此处踩过坑。之前用阿里云一台便宜服务器作为施压机。对某查询接口进行压测时，因为返回数据本身数据量过大，阿里云的百兆网卡被打满，无法支持测试需求。

*测试机与被压测机器最好处于一个相对“干净”的状态。不要跑其他占用资源的服务，或者干脆就专机专用。什么时候需要什么时候申请，用完释放，也不会很耗钱。

*Jmeter 脚本在本地PC编写，施压时务必采用非GUI模式，同时如非必要，也请在配置文件内将输出文件类型选为‘csv’而非‘xml’。不在测试脚本内放置任何监听器与结果分析器，只输出结果，分析统一在本地PC分析。

*服务端要有完善的错误日志，不然测试出瓶颈，没有日志也无从分析。

*如被压测机器数据无法隔离，务必慎重删改操作，用完及时清理脏数据。

*施压机与被压测机，均需注意linux系统设置的最大TCP连接数。如设置过低，可能产生不了你需要的并发连接。

*考虑是否关闭各级缓存，缓存对性能有质的提升。

 

3.某次例子

以这次测试中某次测试做例子。因为保密原因在博客内只能定性描述，不能放真实数据。

需求:探求某查询接口 /search 在当前配置下的最大TPS。

寻求最大TPS的过程就是不断增加用户与并发数，把被测服务器逼上绝境。根据性能测试的曲线拐点模型（可以搜索一下看看详细定义）。当施压并发数不够时，被测服务器仍有能力处理多余请求。继续增大并发数，TPS曲线会逐渐由曲线变为与x轴平行的直线，此时TPS已经稳定。继续增加负载，会重复上述过程，直到某一刻，曲线变平后不会再增加，反而出现下降拐点。此时服务端已不能处理更多请求，开始出现排队现象，响应时间明显边长。我们要找的就是曲线出现下降拐点的TPS值。

因为我们要追求最大TPS，需要不断增加线程数与并发数。故测试脚本的用户数需要不断增加。脚本在本地PC写好以后，scp批量传到施压服务器。为方便起见，利用python脚本来进行控制。（也可考虑用Jmeter的梯度加压模式，看自己选择）

python脚本按照顺序，逐个调用Jmeter进行压测。Jmeter的压测报告文件实质就是csv文件或者xml文件，可以用Jmeter自带GUI界面进行处理分析，也可用用python进行分析。用python脚本分析的话，可以直接在当前目录下生成Excel文件，方便后期的报告整理。（Jmeter的分析结果无法导出）

python处理完所有压测脚本后通知到钉钉或邮箱，此时该分析结果了。

注意：Jmeter在开始测试时会先创建线程，结束测试时会销毁线程，此时测试数据存在不稳定现象。Jmeter GUI中没有找到对应处理机制，我在python脚本内对前后数据进行一些删除，只取中间线程稳定时的数据。

TPS曲线可以由Jmeter GUI的各种后置处理器分析。开始的几个脚本因为压力不够，未观测到TPS的拐点现象。此时对应的施压机与被压测机硬件指标也一切正常。（Jmeter数据结果中有各结果的时间戳，可以获取精确的开始与结束时间，硬件指标在服务器后台找对应时间段的数据，或在nmon的统计数据中找。）

继续查找的话，会看到某测试结果中出现TPS拐点，此时得到此接口最大TPS值。

实际操作要更复杂一些，寻求最大TPS可能需要测试很多组并发数。在几十并发内不断查找。

寻找瓶颈先占坑，后续补充。

 

==========================================================

续坑。

继续以上面测试为例，TPS出现拐点时，施压机与被压测机，基本硬件指标正常。Redis服务器各指标正常，连接数未占满。

需注意，当前服务端CPU占用率最高不到50%，内存20%，瓶颈显然不在硬件。此时需开发运维同学介入，毕竟最了解实际业务代码的还是他们。

初步估计，瓶颈应在服务端，消费能力明显不足，大量请求停留在队列中。没有很好利用服务器资源。

下次压测记录留待优化代码后补充。