Mall商城的高级篇的开发（二）性能压测和性能监控

Mall商城的高级篇的开发（二）

var code = "42322799-fb32-4c9b-9817-cfac8ce1ce71"

性能压测--压力测试

压力测试考察当前软件硬件环境下系统所能承受的最大负荷并帮助找出系统的瓶颈所在。压测都是为了系统在上线的处理能力和稳定性维持在一个标准的范围内，做到心中有数。

使用压力测试，我们有希望找到很多种用其他测试方法很难发现更多的错误。有两种错误类型是：内存泄露、并发与同步。

有效的压力测试系统将应用在一下这些关键条件：重复、并发、量级、随机变化

性能指标

性能指标是来整体把握整个系统的状况。

• 响应时间（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～10000000TPS
• 最大响应时间（Max Response Time）指用户发出请求或者指令到系统作出反应（响应）的最大时间。
• 最少响应的时间（Mininum Response Time）指用户发出请求或者指令到系统作出反应（响应）的最少时间
• 90%响应时间（90% Response Time）是指所有用户的响应时间进行排序，第90%响应时间
• 从外部看，性能测试主要关注如下的指标
  • 吞吐量：每秒钟系统能处理的请求数、任务数
  • 响应时间；服务处理一个请求或一个任务的耗时
  • 错误率：一批请求结果中出错的请求所占的比例。

JMeter

安装

官方下载地址：Apache JMeter - Download Apache JMeter

启动命令。

JMeter压测示例

1. 编写测试计划。

2. 添加用户线程组。并配置用户线程组的属性。

3. 给线程组添加配置元件中的HTTP请求默认值。并配置属性。


4. 给线程组添加取样器中的HTTP请求。并配置属性。因为我们在第三步，已经配置过了，这个就不用配置。

5. 配置返回的结果。一个是查看结果树、一个是聚合报告、用表格查看结果。

6. 启动测试。

压测我们的首页

压测步骤

1. 添加用户线程，模拟用户发起请求

2. 配置HTTP请求

3. 生成结果报告

压测结果截图

1. 汇总报告

2. 聚合报告

3. 查看结果树

4. 汇总图

影响性能的考虑点

数据库、应用程序、中间件（tomcat、nginx）、网络和操作系统等方面

优化的点：应该考虑自己的应用场景属于CPU密集型还是IO密集型

性能监控

JVM内存模型

JVM的相关笔记：JVM_BearBrick0的博客-CSDN博客

堆

在堆内存中，存在几乎90%的对象实例，所有的对象实例以及数组都要在堆上分配。堆是垃圾收集器管理的主要区域，也被称为GC堆；也是我们优化考虑最多的地方。

堆的划分可以参考上面提出的相关笔记。

堆的一次性完成GC的流程：

后面会总结完成的GC流程，先立个Flag。

在做压力测试期间，我们应该对堆中内存来进行监控，包括CPU线程等指标。

JConsole与JVisualvm

JDK的两个小工具JConsole、JVisualvm（升级版的Jconsole），通过命令行启动，可监控本地和远程应用。远程应用需要配置

JConsole

在命令行使用Jconsole，命令便可弹出控制面板：

找到我们的Product服务

1. 概览图

2. 内存使用率的图

Jvisualvm

可以监控内存泄漏，跟踪垃圾回收，执行时内存、CPU分析、线程分析...

使用JMeter做压力测试，并做性能监控

整个项目的访问流程图

测试我们的中间件Nginx

编写测试计划，和上面的步骤相差不大，需要注意的是需要配置自己Nginx的IP地址。

监控Nginx的状态

docker stats

测试结果：

出现的异常

结果报告

测试我们的网关服务Gateway

接口的压力测试步骤和上面类似，这里监控CPU和内存的使用情况我们使用visualvm：

这里主要监控CPU和内存的使用情况

编写简单服务测试

@GetMapping("/hello")
@ResponseBody
public String hello() {
   return "hello";
}

压测的数据表格

压测内容	压测线程数	吞吐量/s	90%响应时间百分比	99%响应时间百分比
Nginx	50 一直循环	25998	3	7
Gateway	50 一直循环	27823	2	8
测试简单服务	50 一直循环	38513	2	6
Gateway+简单服务	50 一直循环	12693	5	57
全链路	50 一直循环	1008	68	321
首页渲染一级菜单	50 一直循环	264（db、thymeleaf）	90	234
三级分类的数据获取	50 一直循环	27（db、thymeleaf）	2523	3295
首页全量数据的获取	50 一直循环	2（静态资源）、（优化之后）19	38881	429
首页渲染（开启缓存、优化数据库（给字段加索引）、降级日志的界别）	50 一直循环	280	388	1547
三级分类的数据获取（优化查询的业务逻辑）	50 一直循环	467	219	335

根据数据可以看出，我们应该优化的一个方向：

• 中间件越多，性能损失越大，大多数的原因都是由于网络之间的耗时
• 业务
  • 模版引擎的渲染速度（缓存的开启）
  • db（Mysql的优化）
    • 给字段建立普通索引
  • 静态资源

JVM分析和调优

结合JvisualVm来给伊甸园和老年代分配合理的内存空间，主要目的是来减少Yong GC和Full Gc所带来的时间的消耗。

Nginx的动静分离

为了减少Tomcat的压力，将静态的配置文件都放到Nginx服务器中。来增加整体项目的

整体的效果图：

流程图：

效果图：

操作流程

1. 将静态的文件移动到Nginx的服务器

2. 配置Nginx的响应的配置文件

模拟线上应用内存奔溃宕机

由于我们将静态的文件都分配到了Nginx服务器中，而Tomcat只接受我们动态的请求，也就是做了动静分离的效果，我们来看看吞吐量有没有提升。

同时为了测试线上的真实效果，我们选择打开thymelead的缓存。