本文记录了使用jmeter对Azure Service Fabric进行压力测试的情况。压力目标为上篇文章里创建完成的示例程序--Voting
- 节点配置：D1 标准 1 vCPU，3.5 GB，4 数据磁盘，2x500 最大 IOPS，50 GB 本地 SSD
节点配置
- jmeter项目如下图
- 单记录操作使用固定Url:api/Votes/press01
- 多记录使用随机函数api/Votes/${__RandomString(2,abcdefg)}
- 使用1~300个线程，610秒内启动，差不多每2秒增加一个。
-
每个线程PUT添加和GET查询都执行一次
jmeter线程组配置
jmeter http put操作
先测试单记录操作的情况：
先测试添加投票的接口，一直投一个票，发现Throughput 在50左右，本地测试也是一样情况，这时监控服务器，发现Cpu和内存都不高，经过分析应该是因为只对一行记录进行写入操作（）。
看一下响应时间图，如下图，可以看出，当操作单条记录时，响应时间几乎是随并发量线性增长的，操作的用户越多等的时间越长（因为单条记录的读写时间是固定的，在没有缓存和排队的情况下，这是必然现像）。当并发线程为50个时，响应时间在1秒左右，当300个线程时响应时间为5.8秒
image.png
但应该不会影响其它投票项的操作（服务器压力一直在20~30%也可以说明这一点。
image.png
吞吐量，见下图，可以看出，几乎保持在58左右，就是说Service Fabric的Statful的存储响应时间应为1/58秒=17毫秒左右。
使用随机函数，测试投不同票（写入不同记录）的情况，服务器负载高了，CPU在40%左右
image.png
下图为投指定票，随机投票，获取结果三种情况下CUP的负载情况：
image.png
增加节点到2和3个，并依次测试：
在Service Fabric Explorer中缩放Web节点
生成结果报告并比较结果
.\jmeter -g H:\jmeter_service_fabric_voting\service_fabric-voting.csv -o H:\jmeter_service_fabric_voting\report
压力测试报告结果分析
我分别在一个节点，2个节点，3个节点下测试了以下3个操作：
- 单记录读写操作(put single)
- 多记录除随机读写操作(put random)
-
多记录查询操作(get)
报告
单记录操作分析：（不同节点数量变化不大，节点越多，吞吐量反而有略微下降）
单记录读写的平均响应时间Average Response Times(ms)和吞吐量(Throughput)，在1~3个节点时分别为：
- 3022ms，56
- 3229ms，57
- 3325ms，55
多记录操作分析：（每增加一下节点，吞吐量增加1.8倍左右）
多记录随机读写的平均响应时间Average Response Times(ms)和吞吐量(Throughput)，在1~3个节点时分别为：
- 1个节点：1873ms，102
- 2个节点：1017ms，180
- 3个节点：743ms，245
查询操作：（因为测试用例只获取第一页，所以多节点性能并无明显提升）
查询操作的平均响应时间Average Response Times(ms)和吞吐量(Throughput)，在1~3个节点时分别为：
- 1个节点：1051ms，237
- 2个节点：649ms，279
- 3个节点：648ms，280
不同并发量下的响应时间
可以看出各种情况下响应时间都是随着并发量增加呈线性增长的。
Time Vs Threads
网友评论