性能指标
-
响应时间(Response Time: RT)
响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间。 -
HPS(Hits Per Second) :每秒点击次数,单位是次/秒。
-
TPS(Transaction per Second):系统每秒处理交易数,也可以理解成每次处理的事务数,单位是笔/秒。
具体的场景,比如:查询商品详情、下订单,可以将其理解为一个个事务,当里面的各项业务都做完了之后,就代表这个事务完成了(此处的事务,不能狭义的理解为数据库的事务) -
QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。
对于互联网业务中,如果某些业务有且仅有一个请求连接,那么 TPS=QPS=HPS,一般情况下用 TPS 来衡量整个业务流程,用 QPS 来衡量接口查询次数,用 HPS 来表示对服务器单击请求。 -
无论 TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好,根据经验,一般情况下:
- 金融行业:1000TPS~50000TPS,不包括互联网化的活动
- 保险行业:100TPS~100000TPS,不包括互联网化的活动
- 制造行业:10TPS~5000TPS
- 互联网电子商务:10000TPS~1000000TPS
- 互联网中型网站:1000TPS~50000TPS
- 互联网小型网站:500TPS~10000TPS
-
最大响应时间(Max Response Time) :指用户发出请求或者指令到系统做出反应(响应)的最大时间。
-
最少响应时间(Mininum ResponseTime) :指用户发出请求或者指令到系统做出反应(响应)的最少时间。
-
90%响应时间(90% Response Time) :是指所有用户的响应时间进行排序,第 90%的响应时间。
-
从外部看,性能测试主要关注如下三个指标
- 吞吐量:每秒钟系统能够处理的请求数、任务数。
- 响应时间:服务处理一个请求或一个任务的耗时。
- 错误率:一批请求中结果出错的请求所占比例。
优化分析
- 首先考虑自己的应用是 CPU 密集型,还是 IO 密集型
- CPU密集型:大量的计算
- 对数据进行排序、过滤、整合等等
- 解决方法:升级服务器、加上CPU
- IO密集型:
- 网络传输
- 磁盘io
- 数据库io
- redisio
- 解决方法:换SSD、加内存条、升级网卡等等
- CPU密集型:大量的计算
- 数据库
- 应用程序
- 中间件(tomcat、nginx)
- 网络和操作系统等方面
jvisualvm
作用
监控内存泄露,跟踪垃圾回收,执行时内存、cpu 分析,线程分析…
- 运行:正在运行的
- 休眠:sleep
- 等待:wait
- 驻留:线程池里面的空闲线程
- 监视:阻塞的线程,正在等待锁
压测中间件对性能的影响
测试简单请求+网关,给网关添加一个断言规则
总结
压测内容 | 压测线程数 | 吞吐量/s | 90%响应时间(ms) | 99%响应时间(ms) |
---|---|---|---|---|
Nginx | 50 | 7900 | 8 | 44 |
Gateway | 50 | 19000 | 4 | 8 |
简单服务 | 50 | 17000 | 4 | 7 |
Nginx+Gateway | 50 | |||
Gateway+简单服务 | 50 | 5000 | 21 | 54 |
全链路+简单服务 | 50 | 1700 | 37 | 57 |
- 中间件越多,性能损失越大,大多都损失在网络交互了
- 可以通过硬件:网线、网卡、或者高效率的传输协议提升性能
压测综合数据
压测内容 | 压测线程数 | 吞吐量/s | 90%响应时间(ms) | 99%响应时间(ms) | 主要原因 |
---|---|---|---|---|---|
首页一级分类渲染 | 50 | 440 | 125 | 197 | 数据库、Thymeleaf渲染 |
三级分类数据获取 | 50 | 4 | 破W了 | 破W了 | 数据库 |
首页全量数据获取 | 50 | 23 | 2818 | 3017 | 静态资源 |
一级分类的数据查询速度平均在4ms
优化手段
- Thymeleaf:开启缓存
- 数据库:为
parent_cid
添加索引 - idea:关闭日志打印
优化后的测试
优化1开启:
压测内容 | 压测线程数 | 吞吐量/s | 90%响应时间(ms) | 99%响应时间(ms) | 主要原因 |
---|---|---|---|---|---|
首页一级分类渲染 | 50 | 1120 | 133 | 235 | 数据库、Thymeleaf渲染 |
首页全量数据获取 | 50 | 22 | 3164 | 3815 | 静态资源 |
优化1、2、3全开:
压测内容 | 压测线程数 | 吞吐量/s | 90%响应时间(ms) | 99%响应时间(ms) | 主要原因 |
---|---|---|---|---|---|
首页一级分类渲染 | 50 | 1149 | 74 | 138 | 数据库、Thymeleaf渲染 |
三级分类数据获取 | 50 | 17 | 3352 | 3509 | 数据库 |
首页全量数据获取 | 50 | 24 | 2644 | 3096 | 静态资源 |
一级分类的数据查询速度平均在3ms
目标服务器的内存太小,导致吞吐量太少
优化首页全量数据获取
原因分析
目前是将所有的动态请求以及静态资源放在微服务中,这样的话,获取首页全量数据发的首页请求,无论是数据库的动态请求,还是每个页面的静态请求,都要交给Tomcat处理,这样,光静态请求就占用了Tomcat的很多资源,会导致吞吐量急剧下降,如何让静态资源快速返回,我们可以使用动静分离的手段。
动静分离
以前,无论是动态或是静态请求,都会交给Nginx,再由Nginx转交给网关,由网关交给后台服务的集群,假设现在产生了很多首页的请求,一个就占用了图上微服务一半的资源,两个就会占满,最终吞吐量每秒就会只有两三个左右。
我们的静态资源目前是放在微服务的静态资源文件夹下,如果我们将静态资源分离出来,放到Nginx中会怎么样呢?
静态资源的请求,由于静态资源都移到了Nginx里面,所以Nginx会直接将资源返回
而动态请求,Nginx还是转交给网关处理,最终转交给微服务
这样后台服务就只需要处理动态资源的请求,会提升很大的吞吐量。
具体步骤
1、静态资源搬家
将原idea的静态资源static
文件夹,全部移到服务器的/mydata/nginx/html/
目录下
2、修改index.html的资源请求路径
统一在请求前加上/static/
3、修改nginx配置
vim /mydata/nginx/conf/conf.d/gulimall.conf
4、重启nginx服务
模拟线上内存崩溃宕机
具体步骤
开启200个线程
-Xmx100m
分配内存太小,很容易就会把新生代、老年代挤满,频繁的垃圾回收,内存崩溃
运行过程中,CPU爆满卡死,最终将服务挤下线
调整参数
依旧是开启200个线程,将内存调大
-Xms1024m -Xmx1024m -Xmn512m
最终没有出现内存崩溃,服务一直处于可用状态
优化三级分类数据获取
具体流程
CategoryServiceImpl.java
private List<CategoryEntity> listByPrentCid(List<CategoryEntity> categories, Long parentCid) {
List<CategoryEntity> finalCategories = categories.stream().filter(category ->
category.getParentCid().equals(parentCid)).collect(Collectors.toList());
return finalCategories;
}
@Override
public Map<Long, List<Category2VO>> getCategoryJson() {
// 查出所有分类,再使用stream处理
List<CategoryEntity> allCategories = this.list();
List<CategoryEntity> l1Categories = listByPrentCid(allCategories, 0L);
Map<Long, List<Category2VO>> categoryMap = l1Categories.stream().collect(Collectors.toMap(k1 -> k1.getCatId(),
v1 -> {
List<CategoryEntity> l2Categories = listByPrentCid(allCategories, v1.getCatId());
List<Category2VO> category2VOs = null;
if (l2Categories != null && l2Categories.size() > 0) {
category2VOs = l2Categories.stream().map(l2 -> {
// 根据当前2级分类查出所有3级分类
List<CategoryEntity> l3Categories = listByPrentCid(allCategories, l2.getCatId());
List<Category3VO> category3VOs = null;
if (l3Categories != null && l3Categories.size() > 0) {
category3VOs = l3Categories.stream().map(l3 -> new Category3VO(l2.getCatId(),
l3.getCatId(), l3.getName())).collect(Collectors.toList());
}
return new Category2VO(v1.getCatId(), category3VOs, l2.getCatId(), l2.getName());
}).collect(Collectors.toList());
}
return category2VOs;
}));
return categoryMap;
}
结果
压测内容 | 压测线程数 | 吞吐量/s | 90%响应时间(ms) | 99%响应时间(ms) | 主要原因 |
---|---|---|---|---|---|
三级分类数据获取 | 50 | 168 | 504 | 868 | 数据库 |