十、性能压测
【摘要】压力测试考察当前软硬件环境下所能承受的最大负荷并帮助找出系统瓶颈所在。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内,做到心中有数
前言
性能压测-压力测试-基本介绍
性能监控
压力测试
压力测试考察当前软硬件环境下所能承受的最大负荷并帮助找出系统瓶颈所在。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内,做到心中有数。
使用压力测试,我们有希望找到很多种用其他测试方式更难发现的错误。有两种错误类型是:内存泄露,并发与同步。
有效的压力测试系统将应用以下这些关键条件:重复、并发、量级、随机变化。
性能指标
响应时间(Response Time:RT)
响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所消耗的时间。
HPS(Hits Per Second):每秒点击次数,单位是次/秒。
TPS(Transaction Per Second):系统每秒处理交易数,单位是笔/秒。
QPS(Query Per Second):系统每秒处理查询次数,单位是笔/秒。
无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好。根据经验,一般情况下:
- 金融行业:1000TPS~50000TPS,不包括互联网化的活动。
- 保险行业:100TPS~100000TPS,不包括互联网化的活动。
- 制造行业:10TPS~5000TPS。
- 互联网电子商务:10000TPS~1000000TPS。
- 互联网中型网站:1000TPS~50000TPS。
- 互联网小型网站:500TPS~10000TPS。
最大响应时间(Max Response Time) 指用户发出请求或者指令到系统做出反应(响应)的最大时间。
最少响应时间(Mininum Response Time) 指用户发出请求或者指令到系统做出反应(响应)的最少时间。
90%响应时间(90% Response Time) 是指所有用户的响应时间进行排序,第90%的响应时间。
从外部看,性能测试主要关注如下三个指标:
- 吞吐量:每秒种系统能够处理的请求数、任务数。
- 响应时间:服务处理一个请求或一个任务的耗时。
- 错误率:一批请求中结果出错的请求所占比例。
性能压测-压力测试-Apache JMeter安装使用
JMeter
JMeter安装
JMeter压测示例
1.添加线程组。2.添加HTTP请求。3.添加监听器。4.启动压测&查看分析报告。
创建测试计划
右击测试计划->添加->线程(用户)->线程组
设置线程数为200,Ranm-Up时间为1秒,循环次数为100。
右击线程组->添加->取样器->HTTP请求
右击线程组->添加->监听器->察看结果树、汇总报告、聚合报告、汇总图
影响性能考虑点包括:
数据库、应用程序、中间件(tomcat、Nginx)、网络和操作系统等方面。
首先要考虑自己的应用属于CPU密集型何时IO密集型。
JMeter Address Already in use错误解决
windows本身提供的端口访问机制的问题。
Windows提供给TCP/IP链接的端口为1024-5000,并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。
- 在
cmd
中,用regedit
命令打开注册表。 - 在
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
下:- 右击parameters,添加一个新的DWORD,名字为MaxUserPort。
- 然后双击MaxUserPort,输入数值数据为65534,基数选择十进制(如果是分布式运行的话,控制机器和负载机器都需要这样操作哦)
- 修改配置完毕之后记得重启机器才生效。
https://docs.microsoft.com/zh-cn/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055
TCPTimeWaitDelay:30
性能压测-压力测试-JMeter在windows下地址占用bug解决
性能压测-性能监控-堆内存与垃圾回收
性能压测-性能监控-jvisualvm使用
jconsole与jvisualvm
jdk的两个小工具jconsole、jvisualvm(升级版的jconsole);通过命令行启动,可监控本地和远程应用。远程应用需要配置。
因为我的电脑上已经安装了java的环境,所以在控制台直接输入下面的命令。
1 | zhangyao@MacBookPro ~ % jconsole |
就会跳出如下界面。
推荐使用jvisualvm。
1 | zhangyao@MacBookPro ~ % jvisualvm |
工具->插件
性能压测-优化-中间件对性能的影响
输入zhelimall.com
客户端->nginx->gateway->集群的商品服务->gateway->nginx->客户端。
这个过程请求经历了两个中间件分别是nginx和gateway。
压测内容 | 接口地址示例 | 压测线程数 | 吞吐量/sec | 90%响应时间/ms | 99%响应时间/ms |
---|---|---|---|---|---|
Nginx | 192.168.60.105 | 50 | 433 | 105 | 640 |
Gateway | 127.0.0.1:88 | 50 | 14143 | 5 | 9 |
简单服务 | localhost:8000/hello | 50 | 14546 | 2 | 4 |
首页一级菜单渲染 | localhost:8000/ | 50 | 614(db,thymelef) | 89 | 139 |
首页一级菜单渲染(开thymelef缓存) | localhost:8000/ | 50 | 814 | 62 | 94 |
首页一级菜单渲染(开thymelef缓存、优化数据库、关日志) | localhost:8000/ | 50 | 1161.1 | 46 | 72 |
三级分类数据获取 | 127.0.0.1:8000/index/catalog.json | 50 | 7.4(db)/12.4(加索引) | … | … |
三级分类数据获取(优化业务) | 127.0.0.1:8000/index/catalog.json | 50 | 191 | 290 | 370 |
三级分类数据获取(使用redis作为缓存) | 127.0.0.1:8000/index/catalog.json | 50 | 508 | 105 | 132 |
首页全量数据获取 | 127.0.0.1:8000/ | 50 | 22.6(静态资源) | 2814 | 23920 |
Nginx+Gateway | 50 | ||||
Gateway+简单服务 | localhost:88/hello | 50 | 7014 | 11 | 25 |
全链路 | zhelimall.com/hello | 50 | 700 | 59 | 152 |
- 中间件越多,性能损失越大,大多都是损失在网络交互上了;
- 优化业务
- DB(MySQL优化)
- 模板的渲染速度(缓存)
- 静态资源
给数据库添加索引
性能压测-优化-简单优化吞吐量测试
性能压测-优化-nginx动静分离
前面我们是把所有的静态资源static/index/css
、static/index/img
、static/index/js
。都放在微服务的tomcat下,这样关静态请求就占用了tomcat的很多资源,导致吞吐量急剧的降低。为了解决这个问题就可以使用nginx进行动静分离。
把项目下的static
文件夹搬到nginx/html
下。
替换链接、script、图片的路径。
修改nginx的配置,之后重启nginx。
1 | server { |
性能压测-优化-模拟线上应用内存崩溃宕机情况
调整商品服务运行内存-Xmx50m
,然后使用200个压测线程数。
使用jvisualvm监控Java后台运行情况。
程序后台抛出很多异常。
在浏览器访问zhelimall.com
发现服务已经不可用。
重新调整-Xmx1024m -Xms1024m -Xmn512m
启动内存。
性能压测-优化-优化三级分类数据获取
三级分类数据获取速度慢主要原因是在业务端进行了太多次与数据库的交互。把启动内存调整为-Xmx100m
。优化思路主要是:把多次查询数据库变成一次。先把三级分类一次性全部查出存放在list中,然后在对list进行操作。