Jmeter性能测试实例

前面一段时间公司开发新网站，用于展示一些足球想关数据，网站由PHP7开发接口，使用node调用接口渲染页面，并由websocket发送实时事件信息。需要对网站做一个压力测试，考虑了一下，最终选用jmeter来完成这个测试。

接口

• betcompany：一个简单的数据接口，获取支持的赔率数据的公司
• matchday：获取比赛日信息
• conerOddsDetail：单个比赛角球赔率信息
• detailed：单个比赛的详细信息
• handicap：所有盘口数据（这个接口计算量非常大，且为实时数据，对服务器CPU消耗会非常高）
• matchlist：所有比赛列表（这个接口的数据量比较大且服务器端计算压力也比较高，更多的是需要访问数据库的次数也很多）。
• matchlist_origin：所有比赛列表，因服务器架构设计原因，实际上处理借口是matchlist_origin，而matchlist是对matchlist_origin一次转发

目的

1. 测试出在中等压力或低压力下测试接口响应速度
2. 测试出服务器并发能力

第一次测试

方案

每一个loop，对每一个接口作一次GET（两个GET之间随机sleep 1~500ms），共循环500次统计测试结果（此时handicap还没有开发完成）。

从下图可以看出来，一开始测试的时候，无压力matchlist接口都在1秒以上，完全无法接受，甚至后面几个接口都有错误。

第二次测试

服务器开发对matchlist接口进行优化（合并）以后，我们单独对这个接口做一下压力测试。限定jmeter的QPS，单独测试接口性能。

限定QPS	CPU使用率（约）	平均相应时间	服务器实际吞吐量（平均）
40	80%	3244.59ms	24.18/s
20	70%	1001.85ms	19.96/s
15	50%	767.34ms	14.99/s

从上面表格中可以看出：

1. 第二次测试时，matchlist接口，实际处理能力差不多也就在20个/秒左右，再增加压力，实际并发能力并没有提高，而响应时间却大幅度提升。压力增加到40个请求每秒的时候，实际处理能力也只是增加了4个每秒，然而响应时间已经增加到3秒多（用户体验会很差），CPU已经到80%以上（服务器运维一般报警设置为70~80%）。
2. 请求数在15个一下时，并没有太高的服务起压力，而700多毫秒的速度和我们单个请求matchlist的响应速度基本相等

分析

实际上第二次测试时，matchlist接口像比较第一次测试已经有很大的优化，但是仍然不能接受，并发能力太弱，20个用户就能把网站高挂掉。

再次分析matchlist接口后发现，因为数据量很大，而且数据存储比较分散，这个接口需要多次请求数据库，并且还需要对数据进行一定量的计算，是导致这个接口慢的很大原因。还有原来设计也有一些不足，于是决定将很多分散的数据合并存储，并且更改架构，放弃原来转发机制等。

第三次测试

经过第二次测试以后，开发/SA再次花时间优化代码，以及服务器端配置，然后我们准备第三次测试。经过简单接以后发现matchlist接口性能确实有大幅度的提升，所以，此次测试方案选择所有接口开100个虚拟用户，每个用户不简隔的调用接口500次，共50000次（除handicap接口因为并发原因，未测完50000次），统计平均响应时间。具体测试数据如下表：

接口	平均响应时间	90th percentile	吞吐量（个/秒）
matchday	3.76 ms	4.00 ms	495.56
conerOddsDetail	52.35 ms	86.00 ms	415.49
detailed	22.86 ms	27.00 ms	456.77
handicap	5391 ms	7497 ms	17.05
matchlist	308.7 ms	890 ms	200.01
betcompany	33.13 ms	48.00 ms	1063.44

从表中我们可以看出，除了刚刚完成功能测试的handicap接口外，所有接口性能都已经大幅度提升，matchlist，也可以保证在CPU压力在80%以下，能够并发200个/秒，已经基本上可以符合要求了。但handicap仍然需要优化。

handicap这个接口的优化的难点在于，其本身计算量非常大，特表消耗CPU资源，且需要返回实时数据。因为实时数据，所以原来并没有加缓存。

第四次测试

再次分析过需求以后，讨论后认为handicap这个实时数据其实可以加一个缓存，过期时间设定为1秒中，同时再配合一些其他的优化。matchlist接口同样加上缓存。开发再进一步优化代码，我们进行第四次测试(只对matchlist和handicap重新测试)

接口	平均响应时间	90th percentile	吞吐量（个/秒）
matchday	3.50 ms	5.00 ms	495.56
conerOddsDetail	52.35 ms	86.00 ms	415.49
detailed	22.86 ms	27.00 ms	456.77
handicap	80.53 ms	142.00 ms	373.43
matchlist	145.17 ms	453.00 ms	403.44
betcompany	33.13 ms	48.00 ms	1063.44

至此，所有接口基本上性能都已经达到预定目标

下面时每一个接口的测试报告：