想接做网站的单子,wordpress 设置 logo,门户网站建设需求文档,wordpress弹窗代码背景 小A#xff1a;小B#xff0c;最近调你的接口老是超时呀#xff0c;8秒都还没返回结果#xff0c;是不是有性能问题呀#xff01;小B #xff1a;我看看~~类似这样的对话#xff0c;在现实中是时有发生的#xff0c;不是特别严重的话#xff0c;往往大家也不会去… 背景 小A小B最近调你的接口老是超时呀8秒都还没返回结果是不是有性能问题呀小B 我看看~~类似这样的对话在现实中是时有发生的不是特别严重的话往往大家也不会去重视这个事。尤其是在一些测试资源并不完备的开发人员对性能测试没有接触过的一些公司遇到这些会显得更加力不从心。本着对自己写出来的东西负责上线之前我们都应该对自己的接口进行一个简单的压力测试。其实做这一步也是为了让我们心里有个度有个底不至于说连能承受多少量都不知道。如果什么都不知道那很容易陷入一个无底深渊这是一件很可怕的事情。老黄平时用的比较多的是Apache Bench当然jmeter、wrk和vegeta也都是非常不错的。说说用这个的原因吧免安装绿色版开箱(解压)即用说白了老黄其实就是懒鬼~~jmeter要装jdk懒得弄。wrk/wrk2 要自己编译mac上面可以直接安装但是我的mac配置不高不折腾。vegeta用起来感觉不是很顺手后面再慢慢挖掘。Apache Bench 介绍 Apache Bench 是Apache服务器自带的一个web压力测试工具简称ab。ab是一个命令行工具对发起负载的本机要求很低根据ab命令可以创建很多的并发访问线程模拟多个访问者同时对某一URL地址进行访问因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单上手学习较快可以提供需要的基本性能指标但是没有图形化结果不能监控。ab进行的测试的本质是基于HTTP协议可以理解为对web服务器软件的黑盒性能测试获得的一切数据和计算结果都是可以通过HTTP来解释的。Apache Bench 简单使用 下面的示例都是在CentOS上面的。通过下面的命令安装yum -y install httpd-tools
装好之后运行一下ab -V就可以看到版本信息。ab -VThis 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的活动云服务器)下面的图可以看到具体的信息还有两个接口的访问详情。先来压一下GET请求的接口 200并发5000个请求。ab -c 200 -n 5000 localhost:9000/test
POST请求有点不一样要先准备一下body的参数这里在/tmp目录创建了一个post.json文件里面就一个字符串。cat /tmp/post.json
Post
在压测命令里面指定Content-Type为application/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% 5566% 6375% 6880% 7190% 7795% 8898% 10599% 1012100% 1058 (longest request)
这么多的指标我们可以重点关注下面几个Requests per secondFailed requests90%95%和98%的响应时间第一个是吞吐量这个上不去其实是挺尴尬的。第二个是失败的请求数这个数要尽可能的低最好是0没有失败的。设想一下100个请求80个都是失败的这个结果还能有意义不。第三个是响应时间这个可以看到大部分请求的速度如何。进行压测时的一些小建议压测尽可能让并发数从低往高慢慢递增避免一开始就设的太大一个比较好的参考依据是现在阶段线上环境的并发数压测的持续时间可以持续久一点这样可以看到更多可能出现的情况可以考虑5分钟8分钟15分钟等有条件的压测和被压测的机器要独立因为压测的时候也会有资源占用可能会影响被压测的接口不要只看压测的结果数据还要留意被压测机的cpu内存等指标在压测时是否正常内网压测的效果达到预期后再考虑外网的网络因素可控性不强分布式压测和全链路压测暂时不用想了留给更专业的人去做吧~~
