你好，我是高楼。

学到这里，我们可以小小地庆祝一下了。因为在前面的28讲里，我已经把全链路压测所需要的前提条件全部都梳理了一遍。从这节课开始，我们就正式进入场景执行阶段了。

在我的RESAR性能工程理念中，我一直强调只有四种性能场景类型。分别是：基准场景、容量场景、稳定性场景和异常场景。这四种场景是递进的关系，每一类场景都是有清晰的目标的。这一节课，我们就是要先整体地了解一下这四种性能场景的目标，然后进行具体的演示。

一个场景设计的问题

在说每个场景的目标之前，我要先说一个问题，这是一个同行问我的。我觉得这是性能行业中非常典型的疑问，也是现在性能行业中经常有人做错的一个地方。

你好，我想请教一个关于TPS压测指标的问题。我们的生产环境，一个场景的系统TPS在高峰期达到了4000/s，但是就持续了几秒，按小时统计最大也不到30w业务量。业务人员给我们的业务指标是75w/h，那在实际压测的时候，如何兼顾两者的指标呢？如果全部按峰值TPS去跑一个小时，感觉太高了，不切实际。这种情况该如何评估压测呢？

我们可以来分析一下这几句话中的关键词：

4000TPS持续了几秒（这里我把问题中的4000直接当成业务级的事务来看了，因为他并没有描述清楚这个4000是哪一级的事务）；
真实环境下，30w笔业务每小时；
业务部门给的需求是，系统可以支持每小时75w笔的业务量。

第2、3点的区别是，一个是真实的每小时业务量，另一个是新提的需求。因为新提的需求要高于真实的每小时业务量，所以我们就以这个更高的要求作为场景目标。

那这时我们容易出现的疑问是：如果每个小时的业务量增加了一倍多，生产峰值TPS会不会增加呢？这个问题，我们从上面的描述中还看不出来，所以也没办法判断。因为75w/h的需求如果平均算过来，每秒大约只有208，这个值远远小于生产上真实达到过的峰值。

所以我们还是拿之前的4000TPS来要求TPS峰值，但是这里要记录一下，有需要的话再去和业务部门沟通。

那我们再整理一下需求就是：

4000TPS：这是一个明确的需求。但是也要注意，这是真实的业务模型所要求的TPS，这里会包括多少业务接口，我们还不清楚。
75w/h：这也是一个明确的需求。但是，我们还不确定是否会因此导致峰值TPS的增加，既然不知道，那我们就先设计场景满足这个75w/h的容量需求。至于峰值TPS，我们先按4000TPS来计算。

明确了这个需求之后，我们还不知道要设计什么样的场景来覆盖这个需求对不对？要想知道这点，我们先来看看每个场景的具体要求，再对应上述问题，看看如何设计可用的场景。

四类性能场景解析

基准场景

基准场景的目标是把每个接口都调优到最好的状态。这里我们要把每个接口都压测一遍，以便将基础的问题呈现出来。很显然，基准场景是不考虑真实的业务模型的，只是为了排除基础问题。

说明一下，这里提到的接口是原子类的接口，是业务流程中涉及到的一个个单独的接口。

容量场景

容量场景的目标是模拟真实的业务峰值。容量场景是性能项目中最重要的场景之一，要给出线上环境是否能满足需求的明确的答案。

在设计容量场景的压力过程时，要注意最核心的两点，那就是场景的连续递增设计和业务模型。

你也许会问，那容量场景的持续时间应该设置为多长呢？通常情况下，我们对容量场景的持续时间是不做特别限制的，具体的时间长度要根据实际的情况做出判断。比如说，场景TPS上升到最高点之后持续了几分钟，这时你看到TPS有下降的趋势，那就必然需要再多等一会，看一下性能衰减有多快。

那话说回来，对应上面那个问题的第一个需求（4000TPS），显然这个容量场景是一定要做的，对应的目标就是4000TPS。

稳定性场景

稳定性场景的核心是能够覆盖业务积累量，它的两个要点就是时长和业务积累量。

这两个要点之间是有关系的，用固定TPS值来执行稳定性的场景时，业务积累量和时长是线性的关系。对应上面的问题中的需求，如果容量场景中的4000TPS能够稳定达到的话，那显然75w的业务积累量只需要3.125分钟（750000笔业务 ÷ 4000TPS = 187.5s）就可以完成了。

那可不可以用这样的逻辑来计算TPS呢？750000笔业务 ÷ 3600s（即一小时）≈ 208.3TPS，也就是用208.3TPS运行一个小时来达到业务积累量。

从业务积累量上来说，显然，这两者是没有区别的，但区别在于TPS的量级和时长。这个区别在技术层面会产生什么影响呢？

我们先假设在这两个场景中用到的参数化数据都是一样的。那4000TPS和208TPS的区别就在于，在单位时间内发送了多少请求到服务端。当请求较为集中的时候（前面我们已经说了4000TPS是可以达到的），服务器上需要开启的工作线程资源、内存资源、CPU资源、网络资源等显然都需要得更多。

不过这里我还想提一下，其实CPU、网络、工作线程类的资源和容量场景中的要求是一样的，但是内存会有不同。在容量场景中，因为跑得时间较短，服务器端或数据库层不需要那么多的内存资源。但在稳定性场景中呢，就需要更多的内存来保存临时数据了，因为参数化数据的量级在稳定性场景中是更多的。

异常场景

异常场景的目标是在出现故障（操作系统、数据库、中间件、进程等等故障）时，验证业务受到的影响。异常场景就是为了模拟生产故障出现时的场景，以此来验证业务系统能不能自动调整。很多企业中把它归结为“非功能测试”的范畴。这一点如果你想了解更多，可以参考一下我上一个专栏的第28讲。

所以针对前面我们提到的需求，显然容量场景和稳定性场景都是必须要做的。那基准场景就不用考虑了吗？直接上容量场景和稳定性场景就够了吗？

其实没有基准场景是不行的。但是，因为上面的需求中只描述了容量场景和稳定性场景的需求，所以有些人会觉得可以跳过基准场景。但是，基准场景作为可以发现通用性能问题的阶段，在性能问题的定位上起着不可忽视的作用。所以，当有了容量场景的需求的时候，你就应该默认基准场景是必须要做的了。

描述了这么多场景设计的内容，针对我们的这个项目，后面我们自然是要把四类场景都执行起来的。

在这节课中，我们一起先来看一下基准场景是怎么跑起来的。

要想把场景跑起来，自然先要有压力数据。在全链路压测的逻辑中，经常会有人提到一种先进炫酷的技术那就是用流量录制回放，那这里我们就来用它产生基准场景的压力。

不过这里有个小的难点。因为我们这个是自己搭建的项目，并没有真实的流量，而GoReplay 可以做的又只是录制回放，那GoReplay要录制的真实流量怎么产生呢。我的逻辑是：

先用 JMeter 模拟真实用户的请求。
在 Gateway 上用 GoReplay 录制请求。
将录制的请求放大回放。

我们就按照这个步骤来做一下。

准备工作

使用Go录制回放

首先，我们要安装一下 Go 语言环境和 GoReplay ：

下载go语言包。解压。
# tar -C /usr/local -zxvf go1.14.4.linux-amd64.tar.gz

# 打开环境变量文件
vim /etc/profile
# 添加
export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin
# 生效
source /etc/profile

下载GoReplay包。

[root@vm ~]# curl -L -O https://github.com/buger/goreplay/releases/download/v1.3.1/gor_1.3.1_x64.tar.gz

更详细的安装步骤可以参考：《性能工具之 Goreplay 安装及入门使用》。
然后，我们用JMeter 把100个线程运行起来。JMeter配置如下：

这里，我把 Ramp-up period 配置为300秒，这是为了实现递增的过程，从而模拟生产环境中的递增趋势。请注意，在真实环境中是不需要这样做的。在真实环境中，我们直接在要录制的网关上执行GoReplay录制的动作就可以了。

接下来，我们使用GoReplay录制回放请求，这里又分了几个小步骤。

创建录制脚本。

[root@gateway-mall-gateway-764bdbcc94-qdp5k /]# cat record.sh 

#!/bin/bash

PORT="8201"
OUT_FILE="request.gor"
HEADER="dunshan:7DGroup"

./gor --input-raw :$PORT --output-file=$OUT_FILE  -output-file-append --http-set-header $HEADER

[root@gateway-mall-gateway-764bdbcc94-qdp5k /]#

在上面的脚本中，“PORT”是我们要录制的端口，“OUT_FILE”是保存的文件名。“HEADER”是在录制的过程中要添加到请求中的HTTP Header，这样在回放的时候，我们就可以直接根据这个Header进行判断了。

执行./record.sh启动录制，这样在同目录下会生成request.gor文件。
将request.gor复制到压力机上。
创建GoReplay压力脚本run.sh，脚本内容如下：

#!/bin/bash

OUTPUT="http://10.96.136.36:8201"
MIDDLEWARE="./middleware_wrapper.sh"
#MIDDLEWARE="./middleware_echo.py"
INPUT_FILE="request.gor"

sudo ./gor --input-file $INPUT_FILE --input-file-loop  --output-http=$OUTPUT --prettify-http --output-http-track-response

在上面这段脚本当中，“OUTPUT”是目标服务器的URL路径；“MIDDLEWARE”是用来扩展GoReplay功能的中间件，我们可以根据需要自己编写，像关联这样重要的功能就要在这一步实现（详见本专栏第21-22讲）；“INPUT_FILE”是在录制过程中生成的文件。

执行run.sh。

我们先只执行一遍，查看下调用的内容是不是正常。

先看订单有没有生成，影子库的截图是这样的：

从影子库的最近一条订单时间来看，确实是产生了新的订单，说明执行是成功的。

下面再来看看日志，确定一下执行的过程也是没问题的。Auth服务上的日志：

2021-10-24 11:22:56.464  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : ==============redis=mall.auth==请求内容===============
2021-10-24 11:22:56.464  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求地址:http://10.100.220.76:8401/oauth/token
2021-10-24 11:22:56.464  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求方式:postAccessToken
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求类方法头信息:7DGroup
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : redis 压测流量：5
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : ============My===请求内容===============
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求地址:http://10.100.220.76:8401/oauth/token
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求方式:POST
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求类方法:CommonResult com.dunshan.mall.auth.controller.AuthController.postAccessToken(Principal,Map)
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求类方法参数:[org.springframework.security.authentication.UsernamePasswordAuthenticationToken@f00b9e84: Principal: org.springframework.security.core.userdetails.User@ff46140: Username: portal-app; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Not granted any authorities; Credentials: [PROTECTED]; Authenticated: true; Details: null; Not granted any authorities, {password=123456, grant_type=password, client_secret=123456, client_id=portal-app, username=7dTest005}]
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : 请求类方法头信息:7DGroup
2021-10-24 11:22:56.465  INFO [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : Mysql 压测流量
2021-10-24 11:22:56.469 DEBUG [mall-auth,ddcce4f1b50707d1,1551de5039a85bf9,false] 1 --- [nio-8401-exec-1] c.d.mall.auth.aop.db.DataSourceAspect    : redis switch 0 to 5

Portal日志：

2021-10-24 11:22:56.403  INFO [mall-portal,1bd396aebbbcc2b7,98336b0b0e15d0ba,false] 1 --- [nio-8085-exec-9] c.d.mall.portal.aop.db.DataSourceAspect  : ===============请求内容===============
2021-10-24 11:22:56.403  INFO [mall-portal,1bd396aebbbcc2b7,98336b0b0e15d0ba,false] 1 --- [nio-8085-exec-9] c.d.mall.portal.aop.db.DataSourceAspect  : 请求地址:http://10.96.136.36:8201/home/content
2021-10-24 11:22:56.403  INFO [mall-portal,1bd396aebbbcc2b7,98336b0b0e15d0ba,false] 1 --- [nio-8085-exec-9] c.d.mall.portal.aop.db.DataSourceAspect  : 请求方式:GET
2021-10-24 11:22:56.403  INFO [mall-portal,1bd396aebbbcc2b7,98336b0b0e15d0ba,false] 1 --- [nio-8085-exec-9] c.d.mall.portal.aop.db.DataSourceAspect  : 请求类方法:CommonResult com.dunshan.mall.portal.controller.HomeController.content(Integer,Integer)
2021-10-24 11:22:56.403  INFO [mall-portal,1bd396aebbbcc2b7,98336b0b0e15d0ba,false] 1 --- [nio-8085-exec-9] c.d.mall.portal.aop.db.DataSourceAspect  : 请求类方法参数:[4, 1]
2021-10-24 11:22:56.403  INFO [mall-portal,1bd396aebbbcc2b7,98336b0b0e15d0ba,false] 1 --- [nio-8085-exec-9] c.d.mall.portal.aop.db.DataSourceAspect  : 请求类方法头信息:7DGroup
........................

Order日志：

2021-10-24 11:22:57.015  INFO [mall-order,8f7b6e9d44c60348,85b18558eb463fc5,false] 1 --- [nio-8084-exec-5] c.d.mall.order.aop.db.DataSourceAspect   : ===============请求内容===============
2021-10-24 11:22:57.015  INFO [mall-order,8f7b6e9d44c60348,85b18558eb463fc5,false] 1 --- [nio-8084-exec-5] c.d.mall.order.aop.db.DataSourceAspect   : 请求地址:http://10.96.136.36:8201/order/generateConfirmOrder
2021-10-24 11:22:57.015  INFO [mall-order,8f7b6e9d44c60348,85b18558eb463fc5,false] 1 --- [nio-8084-exec-5] c.d.mall.order.aop.db.DataSourceAspect   : 请求方式:POST
........................

从上面的日志内容来看，每个服务中的日志都显示正确。

下面我们再来看一下Zipkin中的调用树，确认一下是不是已经把设置的Header加到标签中去了。

从Zipkin来看，请求确实调到了不同的脚本上，结果也是正确的。

循环多遍执行run.sh，查看网关上的回放日志。

2021-10-24 11:10:36.710  INFO [mall-gateway,8313cfa404164710,8313cfa404164710,false] 1 --- [undedElastic-13] c.dunshan.mall.filter.AuthGlobalFilter   : dunshan-流量标识：7DGroup
2021-10-24 11:10:36.710  INFO [mall-gateway,8313cfa404164710,8313cfa404164710,false] 1 --- [undedElastic-13] c.dunshan.mall.filter.AuthGlobalFilter   : AuthGlobalFilter.filter() user:{"user_name":"7dTest005","scope":["all"],"id":2434424,"exp":1635129516,"authorities":["前台会员"],"jti":"8368728f-79db-4bff-9afc-c63d15247257","client_id":"portal-app"}
2021-10-24 11:10:36.837  INFO [mall-gateway,c6efe4825748f2d4,c6efe4825748f2d4,false] 1 --- [undedElastic-13] c.dunshan.mall.filter.AuthGlobalFilter   : dunshan-流量标识：7DGroup
2021-10-24 11:10:36.837  INFO [mall-gateway,c6efe4825748f2d4,c6efe4825748f2d4,false] 1 --- [undedElastic-13] c.dunshan.mall.filter.AuthGlobalFilter   : AuthGlobalFilter.filter() user:{"user_name":"7dTest005","scope":["all"],"id":2434424,"exp":1635129516,"authorities":["前台会员"],"jti":"8368728f-79db-4bff-9afc-c63d15247257","client_id":"portal-app"}
........................

从日志上看，系统已经按照预期执行了相应的请求，压测标签在日志中也都是对的。

执行基准场景

上面的准备工作都完成了之后，我们就可以放大更多倍数进行回放，执行基准场景了。还记得我们基准场景的目标吧？主要是为了找到系统中的各种单接口的问题。

压力场景数据

我们先来模拟访问首页这个基准场景。首页是最为常用的，所以也非常重要。我们先来看看首页的访问路径。

图中这个结构就是访问首页时的路径了，你也可以把它看成是逻辑图。因为这个架构并不复杂，所以RESAR性能分析七步法中的第二步“分析架构图”就可以省了。

下面，我们根据GoReplay录制回放的逻辑，准备好相关的脚本，使用Goreplay放大100倍执行首页基准场景。脚本如下：

[root@s5 ~]# cat run.sh
#!/bin/bash

OUTPUT="http://10.96.136.36:8201"
#MIDDLEWARE="./middleware_wrapper.sh"
INPUT_FILE="request-mall-home.gor|10000%"
sudo ./gor_ldd --input-file $INPUT_FILE --input-file-loop --output-http=$OUTPUT --prettify-http --output-http-track-response --stats --output-http-stats  -output-http-compatibility-mode true

可以看到，上面的脚本中，“10000%”就是放大的倍数，这里是指100倍。

接着我们执行run.sh发起压力，监控结果如下：

从这张监控截图中我们可以看到，一开始响应时间较高，达到了500ms，这时候TPS只有50；随着压力的持续，响应时间降到了200ms左右，TPS也增加到了200左右。

但是200TPS算是好还是坏呢？根据我在上一个专栏的经验，我们对这个系统优化之后，这个首页的TPS在单个容器上达到过1200，而现在只有200，这显然是不能接受的。

这里我们可以先停一下，不要着急去猜问题的答案。回想我们的基准场景的目标，就是要找到单接口的性能问题，而现在我们已经从压力数据判断出这个接口的性能是有问题的了。那下一步要做什么事情呢？

请注意，我说的是“下一步”。现在你要做的就是静下心来，不要慌张，想清楚“下一步”，这恰恰是最重要的。

我带领团队做性能分析的时候经常一再强调，做性能分析并不是直接给出性能瓶颈的答案，而是给出性能分析的逻辑。有了逻辑自然会找到性能瓶颈的证据链，也自然会找到性能瓶颈的根本原因。所以在分析性能瓶颈的过程中，知道答案并不是首要的，只要知道“下一步”做什么具体的动作，自然可以做到心中不慌乱。

好了，现在我们回想一下RESAR性能分析七步法。

显然，前两步“压力场景数据”和“分析架构图”我们已经看过了。下一步就是去“拆分响应时间”了。但是鉴于我们这个首页架构非常简单，只有 gateway-portal-mysql 三个环节，而首页的逻辑就是在portal上，至于mysql慢不慢，我们也很容易从portal上做出判断，所以这一步也不用花太多时间。

接下来，我们可以直接去全局监控数据中看一看有什么不合理的地方。

全局监控

全局监控数据如下：

通过这张截图我们发现，Portale服务所在的s7工作节点的CPU已达到97%了。但是因为这个机器是一个只有2C的虚拟机，配置过低，稍微有一点压力就会达到很高的CPU消耗，何况我们也达到了200TPS，所以暂时不分析原因，而是把服务移到配置高一点的机器上再接着观察。

下面我们把Portal服务移到一个8C16G的虚拟机上。再次查看压力数据。

从这张趋势图中我们看到，TPS可以达到550左右。因为这个接口只需要300多的TPS，而且根据经验，压力越大的时候TPS增加得越慢。所以我们可以限制资源到4C8G，再来看一下能不能达到300TPS。限制资源配置如下：

这里出现一个了插曲，在保存资源限制时出现了报错：节点没有足够的CPU可用。报错信息是下面这个样子：

为了搞清楚这个问题的原因，我们去查看了这个 Portal 所在的 Worker 上的服务，发现这个Worker上还有其他服务。这个Worker上的资源分配情况是，虽然资源使用率都很低，但是CPU已经被分配出去了。所以当我们想分配4C8G的资源给Portal服务时，显示了上面的错误。

为了避免服务之间的资源争用，我们把这个Portal服务移到一个没有任何服务的Worker上去了。这时，我们添加了一个8C16G的新Worker节点，单独运行Portal服务。再次启动压力：

看起来已经很美好了：TPS能达到700左右，响应时间在15毫秒，并且抖动也不大。我们再查看一下全局监控：

从图上可以看出，s6消耗的资源多。s6是一个2C的机器，我们先进去看一下是哪个进程导致的CPU消耗过高。

[root@s6 ~]# top
top - 18:05:53 up 75 days, 23:20,  2 users,  load average: 9.16, 7.58, 4.12
Tasks: 198 total,   2 running, 196 sleeping,   0 stopped,   0 zombie
%Cpu(s): 69.7 us, 12.1 sy,  0.0 ni, 12.1 id,  0.0 wa,  0.0 hi,  6.1 si,  0.0 st
KiB Mem :  8008972 total,   192056 free,  5909516 used,  1907400 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1797212 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
31214 root      20   0 4681832 612756   7152 S 125.0  7.7 365:49.67 java
  956 root      20   0 1058124  90796   6636 S  25.0  1.1   6274:30 dockerd
  954 root      20   0 2465836 152556  20364 S   6.2  1.9   5786:27 kubelet
 4310 root      20   0 4617612 546260   6820 S   6.2  6.8 201:44.12 java
 9241 root      20   0  162152   2268   1544 R   6.2  0.0   0:00.01 top

通过PID 31214对应的容器，我们知道问题出在 Gateway：

[root@s6 ~]# docker ps |grep gateway
8a4bf818dfab        registry.cn-beijing.aliyuncs.com/7d-mall/mall-gateway   "java -Dcom.sun.mana饪?"   13 days ago         Up 13 days                              k8s_mall-gateway_gateway-mall-gateway-7cf7868798-fc2gr_default_7c55578b-7e1d-4c58-a58e-f347caa3bbdc_0
25dbe722defd        registry.aliyuncs.com/k8sxio/pause:3.2                  "/pause"                 13 days ago         Up 13 days                              k8s_POD_gateway-mall-gateway-7cf7868798-fc2gr_default_7c55578b-7e1d-4c58-a58e-f347caa3bbdc_0
[root@s6 ~]# docker inspect --format "{{.State.Pid}}" 8a4bf818dfab
31214
[root@s6 ~]#

因为我们希望Gateway能支撑更大的转发能力。而s6只是一个2C的虚拟机，在这个TPS下表现已经很不错了，没有太大的可操作空间了。所以我们选择直接增加一个Gateway的节点，并且把它调度到其他的Worker上去：

[root@s5 ~]# kubectl get pods -n default -o wide|grep gateway
gateway-mall-gateway-69dc766c9d-gbvbb        1/1     Running     0          31s     10.100.219.253   s11    <none>           <none>
gateway-mall-gateway-69dc766c9d-n828c        1/1     Running     0          24m     10.100.59.84     s12    <none>           <none>
[root@s5 ~]#

查看一下压力数据：

这时候，TPS已经可以达到1100了，响应时间在10ms左右。现在，我们来判断一下瓶颈在哪里，查看全局监控数据：

现在已经没有明显的系统资源占用太高的情况了。但是只看这一层还不够，我们还要看一下Service级别的资源。我们要根据这个接口的路径，一层层去找瓶颈点在哪里，当查到mysql服务的资源时，我看到了下面的信息：

恼火得很，这里只分配了512M的内存，但申请的内存已经超过了660M，这个限制就有点过狠了。

所以我们就得来调整一下资源了。放开mysql的资源限制，让他可以用到8C16G的资源。再压一遍看看：

压力数据看起来和上一轮一样，还是得再看一下全局监控：

从这张全局监控的截图里，我们已经看不出有什么明显的问题了。但我们在第26讲中说过这个界面是有缺陷的，所以还是要登录到各个主机上查看一下是否有优化点。

定向监控

下面我们来看下定向监控。我们要到每个机器里去执行一下top（我之所以喜欢喜欢用top是因为top给出的CPU数据是非常明确且完整的，而CPU又是非常综合的计数器，所以我习惯性地会进到系统中执行一下top，看一下每颗CPU的情况）。

在每个机器里都执行了一遍top之后，我发现了这样的情况。

%Cpu0  : 29.4 us,  5.8 sy,  0.0 ni, 64.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 21.2 us,  4.4 sy,  0.0 ni, 73.0 id,  0.0 wa,  0.0 hi,  1.4 si,  0.0 st
%Cpu2  : 31.8 us,  5.5 sy,  0.0 ni, 62.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 19.6 us,  5.1 sy,  0.0 ni, 74.3 id,  0.0 wa,  0.0 hi,  1.0 si,  0.0 st
%Cpu4  : 26.2 us,  5.5 sy,  0.0 ni, 68.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  : 21.3 us,  3.8 sy,  0.0 ni, 73.9 id,  0.0 wa,  0.0 hi,  1.0 si,  0.0 st
%Cpu6  : 27.6 us,  5.1 sy,  0.0 ni, 53.1 id,  0.0 wa,  0.0 hi, 54.8 si,  0.0 st
%Cpu7  : 28.6 us,  3.4 sy,  0.0 ni, 67.0 id,  0.0 wa,  0.0 hi,  1.0 si,  0.0 st

一看到这种情况我就怀疑是软中断，这是我最近经常会遇到的问题（如果你不了解这个分析逻辑，可以查看一下上一个专栏的第14讲。）我去查了一下这个机器所用的网络队列：

显然，是单队列网卡了。但是这是一个虚拟网卡。

当前用的是Calico的IPIP模式，查看Calico源码之后，我发现IPIP模式有局限，只能使用单队列网卡，那就没招只能换网络插件了。于是我把网络插件换成了Flannel。接着压起来，看一下效果：

看起来有效果哦，同样的场景，已经达到了1250TPS。再来看看软中断：

%Cpu0  : 38.2 us, 14.2 sy,  0.0 ni, 39.2 id,  0.0 wa,  0.0 hi,  8.3 si,  0.0 st
%Cpu1  : 26.4 us, 13.9 sy,  0.0 ni, 58.3 id,  0.0 wa,  0.0 hi,  1.4 si,  0.0 st
%Cpu2  : 40.5 us, 13.9 sy,  0.0 ni, 35.0 id,  0.0 wa,  0.0 hi, 10.5 si,  0.0 st
%Cpu3  : 32.9 us, 12.1 sy,  0.0 ni, 52.6 id,  0.0 wa,  0.0 hi,  2.4 si,  0.0 st
%Cpu4  : 40.7 us, 14.5 sy,  0.0 ni, 31.6 id,  0.0 wa,  0.0 hi, 13.1 si,  0.0 st
%Cpu5  : 33.0 us, 11.7 sy,  0.0 ni, 52.9 id,  0.0 wa,  0.0 hi,  2.4 si,  0.0 st
%Cpu6  : 39.7 us, 14.8 sy,  0.0 ni, 36.2 id,  0.0 wa,  0.0 hi,  9.3 si,  0.0 st
%Cpu7  : 31.8 us, 11.1 sy,  0.0 ni, 55.4 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st

这里我们看到，si已经能用到四颗CPU了。效果还是明显的。

到这里，定向监控分析也就完成了。

总结

好了，这节课就讲到这里。这是我们这个专栏中关于场景的第一课。执行场景是压测项目的核心环节，它不仅把前面准备的所有内容都用起来了，还是性能分析的起点。

在这一节课里，我描述了各类场景的目标，也给了你一个案例，告诉你如何去分析性能需求并设计出合适的场景。

在这节课所讲的基准场景中，我们的目标就是把所有的接口都调试到最好的状态。这一步在全链路压测中是非常重要的环节，我不建议你跳过。

刚才，我们只通过对一个接口的基准场景模拟，就发现了Calico IPIP模式单网卡软中断的问题。像这样的问题，如果直接执行容量场景再去做判断，会因为容量场景里的接口过于复杂而导致你需要查更多的计数器，分析成本和判断成本都会高出很多。

当然，如果艺高人胆大，你也可以直接执行容量场景，那样的话，出现了多个性能问题会交织在一起，就只能凭借技术功底做判断了。我不建议你这样做。

课后题

学完这节课，我想请你思考两个问题：

你在执行场景的时候是直接压大容量的场景还是有非常清晰的策略？可以分享一下。
在k8s的云原生环境中，网络结构有什么特点？

欢迎你在留言区与我交流讨论。我们下节课见！