本文记录了使用jmeter对Azure Service Fabric进行压力测试的情况。压力目标为上篇文章里创建完成的示例程序--Voting

1. 节点配置：D1 标准 1 vCPU，3.5 GB，4 数据磁盘，2x500 最大 IOPS，50 GB 本地 SSD

节点配置

• jmeter项目如下图
  1. 单记录操作使用固定Url:api/Votes/press01
  2. 多记录使用随机函数api/Votes/${__RandomString(2,abcdefg)}
  3. 使用1~300个线程，610秒内启动，差不多每2秒增加一个。

  4. 每个线程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