推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > dotNET跨平台 > 后端开发都应该了解点接口的压力测试(Apache Bench版)

后端开发都应该了解点接口的压力测试(Apache Bench版)

dotNET跨平台 2021-06-11

背景

小A:小B,最近调你的接口老是超时呀,8秒都还没返回结果,是不是有性能问题呀!
小B :我看看~~

类似这样的对话,在现实中是时有发生的,不是特别严重的话,往往大家也不会去重视这个事。

尤其是在一些测试资源并不完备的,开发人员对性能测试没有接触过的一些公司,遇到这些会显得更加力不从心。

本着对自己写出来的东西负责,上线之前,我们都应该对自己的接口进行一个简单的压力测试。

其实做这一步也是为了让我们心里有个度,有个底,不至于说连能承受多少量都不知道。如果什么都不知道,那很容易陷入一个无底深渊,这是一件很可怕的事情。

老黄平时用的比较多的是Apache Bench,当然,jmeter、wrk和vegeta也都是非常不错的。

说说用这个的原因吧,免安装,绿色版,开箱(解压)即用,说白了,老黄其实就是懒鬼~~

jmeter要装jdk,懒得弄。

wrk/wrk2 要自己编译,mac上面可以直接安装,但是我的mac配置不高,不折腾。

vegeta用起来感觉不是很顺手,后面再慢慢挖掘。

Apache Bench 介绍

Apache Bench 是Apache服务器自带的一个web压力测试工具,简称ab。

ab进行的测试的本质是基于HTTP协议,可以理解为对web服务器软件的黑盒性能测试,获得的一切数据和计算结果,都是可以通过HTTP来解释的。

Apache Bench 简单使用

下面的示例都是在CentOS上面的。

通过下面的命令安装,

yum -y install httpd-tools

装好之后,运行一下ab -V就可以看到版本信息。

ab -V

This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

运行一下ab -h就可以看到帮助信息。

帮助信息有很多,也比较详细,老黄把一些常用的参数都添加了注释,方便大家查看。

其中最常用的两个参数是 -c-n,当然如果是POST/PUT请求的话,还离不开 -T-p

说了不少废话,来看看怎么使用才是重点。

下面准备了两个简单的接口来进行演示

[ApiController]
[Route("test")]
public class TestController : ControllerBase
{
[HttpGet]
public string Get() => "GET";

[HttpPost]
public string Post([FromBody]string value) => value;
}

这个接口是跑在docker里面的(一台2c4g的活动云服务器),下面的图可以看到具体的信息,还有两个接口的访问详情。

后端开发都应该了解点接口的压力测试(Apache Bench版)

先来压一下GET请求的接口, 200并发,5000个请求。

ab -c 200 -n 5000 localhost:9000/test
后端开发都应该了解点接口的压力测试(Apache Bench版)

POST请求有点不一样,要先准备一下body的参数,这里在/tmp目录创建了一个post.json文件,里面就一个字符串。

cat /tmp/post.json
"Post"

在压测命令里面,指定Content-Typeapplication/json, 参数的数据文件路径是/tmp/post.json

同样也是200并发,5000个请求。

ab -c 200 -n 5000 -T "application/json" -p /tmp/post.json localhost:9000/test

到这里,大家对怎么压测,应该都不会太陌生了,比较陌生的应该是压测的结果要怎么看。

下面拿其中一个结果示例来说明各项指标的含义:

Server Software:        Kestrel  # 服务器软件名称
Server Hostname: localhost # 服务器主机名
Server Port: 9000 # 服务器端口

Document Path: /test # 测试的URL路径
Document Length: 3 bytes # 文档大小

Concurrency Level: 200 # 并发数
Time taken for tests: 2.386 seconds # 消耗的总时间
Complete requests: 5000 # 总次数
Failed requests: 0 # 失败的请求数
Write errors: 0 # 网络连接写入错误数
Total transferred: 680000 bytes # 传输的总数据量
HTML transferred: 15000 bytes # HTML文档的总数据量
Requests per second: 2095.43 [#/sec] (mean) # (平均每秒的请求数) 这个是非常重要的参数数值,服务器的吞吐量
Time per request: 95.446 [ms] (mean) # (所有并发用户都请求一次的平均时间)
Time per request: 0.477 [ms] (mean, across all concurrent requests) # (单个用户请求一次的平均时间)
Transfer rate: 278.30 [Kbytes/sec] received # 每秒获取的数据长度 (传输速率,单位:KB/s)

# 网络上消耗的时间的分解
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 3 3.7 2 20
Processing: 12 68 120.0 53 1057
Waiting: 1 67 120.1 52 1050
Total: 15 71 119.8 55 1058

# 整个场景中所有请求的响应情况
Percentage of the requests served within a certain time (ms)
50% 55
66% 63
75% 68
80% 71
90% 77
95% 88
98% 105
99% 1012
100% 1058 (longest request)

这么多的指标,我们可以重点关注下面几个

  1. Requests per second
  2. Failed requests
  3. 90%,95%和98%的响应时间

第一个是吞吐量,这个上不去,其实是挺尴尬的。

第二个是失败的请求数,这个数要尽可能的低,最好是0,没有失败的。设想一下,100个请求,80个都是失败的,这个结果还能有意义不。

第三个是响应时间,这个可以看到大部分请求的速度如何。

进行压测时的一些小建议:

  • 压测尽可能让并发数从低往高慢慢递增,避免一开始就设的太大,一个比较好的参考依据是现在阶段线上环境的并发数
  • 压测的持续时间可以持续久一点,这样可以看到更多可能出现的情况,可以考虑5分钟,8分钟,15分钟等
  • 有条件的,压测和被压测的机器要独立,因为压测的时候也会有资源占用,可能会影响被压测的接口
  • 不要只看压测的结果数据,还要留意被压测机的cpu,内存等指标在压测时是否正常
  • 内网压测的效果达到预期后,再考虑外网的,网络因素,可控性不强

分布式压测和全链路压测,暂时不用想了,留给更专业的人去做吧~~


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《后端开发都应该了解点接口的压力测试(Apache Bench版)》的版权归原作者「dotNET跨平台」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注dotNET跨平台微信公众号

dotNET跨平台微信公众号:opendotnet

dotNET跨平台

手机扫描上方二维码即可关注dotNET跨平台微信公众号

dotNET跨平台最新文章

精品公众号随机推荐