使用ab接口压力测试

由于最近在开发前端日志监控系统,对接口负载有较高的要求。
我们需要模拟高并发的环境下,接口承受的最大负载。

后端接口使用nodejs部署,服务器为1核2G腾讯云。
如果是ubuntu系统,可以用下面命令安装

sudo apt install apache2-utils
// 下面为输入ab后的帮助命令
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
    -n requests     Number of requests to perform
    -c concurrency  Number of multiple requests to make at a time
    -t timelimit    Seconds to max. to spend on benchmarking
                    This implies -n 50000

-n 表示请求的次数,-c 表示并发数,-t 表示持续的时间

模拟500个客户端,进行20000次的请求。

ab -c 500 -c 20000 'http://127.0.0.1'

下面为压测的结果

Concurrency Level:      500 // 发送的并发数
Time taken for tests:   3.301 seconds
Complete requests:      10000 // 总的请求数
Failed requests:        0
Total transferred:      980000 bytes
HTML transferred:       0 bytes
Requests per second:    3029.78 [#/sec] (mean)  // 每秒处理的请求数
Time per request:       165.028 [ms] (mean) //  接口平均用时
Time per request:       0.330 [ms] (mean, across all concurrent requests)
Transfer rate:          289.96 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   28 162.8      0    1002
Processing:    41   76  30.3     74     880
Waiting:       41   76  30.3     74     880
Total:         41  104 176.4     75    1279

Percentage of the requests served within a certain time (ms)
  50%     75
  66%     77
  75%     79
  80%     81
  90%     84
  95%     87
  98%   1071
  99%   1241
 100%   1279 (longest request)

结果显示,500个请求没什么压力,那我们换成3000个并发呢
如果执行请求提示

socket: Too many open files (24)

表示连接数被限制了,可以用下面命令修改

ulimit -n 65535

以下为3000并发时的测试结果

Concurrency Level:      3000
Time taken for tests:   27.179 seconds
Complete requests:      30000
Failed requests:        0
Total transferred:      2940000 bytes
HTML transferred:       0 bytes
Requests per second:    1103.80 [#/sec] (mean)
Time per request:       2717.874 [ms] (mean) // 处理时间变长
Time per request:       0.906 [ms] (mean, across all concurrent requests)
Transfer rate:          105.64 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  400 1872.4      0   15037
Processing:    23  209 519.4    132   26165
Waiting:       23  209 519.4    132   26165
Total:         45  609 2043.7    141   27168

Percentage of the requests served within a certain time (ms)
  50%    141
  66%    194
  75%    216
  80%    246
  90%    495
  95%   3095
  98%   7318
  99%  15102
 100%  27168 (longest request)

可以看到处理能力出现了明显下降。

为了了解服务器瓶颈,需要看下云服务器的资源使用情况
cpu是满载了,还是内存用完了,还是硬盘io有问题,或者是程序没写好,出错了。进行逐一排查,榨干性能。

image.png

上图可以看出cpu出现了100%,导致处理能力下降。

由于我用的是单核处理器,所以我只开了一个进程,如果你是用多核处理器,可以用pm2开多个进程提高cpu的利用率。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 1.ios高性能编程 (1).内层 最小的内层平均值和峰值(2).耗电量 高效的算法和数据结构(3).初始化时...
    欧辰_OSR阅读 29,797评论 8 265
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 135,323评论 19 139
  • 第一章 Nginx简介 Nginx是什么 没有听过Nginx?那么一定听过它的“同行”Apache吧!Ngi...
    JokerW阅读 32,862评论 24 1,002
  • 又来到了一个老生常谈的问题,应用层软件开发的程序员要不要了解和深入学习操作系统呢? 今天就这个问题开始,来谈谈操...
    tangsl阅读 9,608评论 0 23
  • 有个人死了,上帝手拎行李箱向他走来。 上帝说:好了,孩子,我们走吧。 死者:这么快,我还有很多计划没…… 上帝:很...
    知行思阅读 2,865评论 0 1