30 | 预压测：如何基于小流量快速验证容量压测效果？

你好，我是高楼。

上一节课呢，我们重点讲解了基准场景、容量场景、稳定性场景和异常场景这四类性能场景。通过对一个接口的基准场景模拟，我们提前发现了Calico IPIP模式单网卡软中断的问题，为后面容量场景的测试减少了一些麻烦。

这节课，我们就再进一步，把容量场景跑起来。我们先预压测一下，把场景中存在的小问题先找出来。

因为是预压测，所以一开始我们不用上太多的线程。先添加20个线程，运行一下看看结果就可以了。

说明一下，这里我换到JMeter上来运行，倒不是因为GoReplay不能满足压测需求，经过前面的改造，GoReplay其实已经可以完成我们的压测需求了。只是我还是更习惯JMeter在功能上的丰富性，所以在预压测这一讲，我们还是用JMeter来执行。

第一阶段

压力场景数据

怀着激动的心情，我们先来启动压力：

果然是不压不知道，一压心直跳呀。错误率很高不说，响应时间也很长。这就是我们要面对的问题了。

我们先来分析一下错误在哪。

从报错的信息来看，是断言判断不到设定的“操作成功”和“下单成功”字样。这是什么问题呢？

我们先把脚本拿到本地来跑一下试试。

我们发现，返回信息里的中文全是乱码。这样一来，断言自然也就失效了。为了解决乱码，我们打开JMeter目录中的/bin/jmeter.properties，添加UTF-8的配置到文件中。

sampleresult.default.encoding=utf-8

再次回放，脚本就可以正常显示了。

我们还是用不大的压力（20个线程）再把压力跑起来，压力数据变成了下面这个样子：

看起来好像还不错。虽然也有几个错误，但相比刚才已经少很多了。剩下的这些错误应该就是真正的业务错误了。不过我们现在先不管它。先看看资源使用率的情况。

全局监控分析

通过这张全局监控截图，我们比较欣喜地看到，终于有一个机器的CPU已经标红了。在这种情况下，再分析就是要走我们的RESAR性能分析七步法了，保证手到擒来。

下面我们进到CPU高的s12服务器，执行top。

top - 23:14:44 up 3 days, 22:55,  1 user,  load average: 14.43, 11.99, 8.53
    Tasks: 193 total,   1 running, 192 sleeping,   0 stopped,   0 zombie
    %Cpu0  : 76.4 us,  6.7 sy,  0.0 ni, 13.8 id,  0.3 wa,  0.0 hi,  2.7 si,  0.0 st
    %Cpu1  : 71.4 us,  7.7 sy,  0.0 ni, 19.9 id,  0.3 wa,  0.0 hi,  0.7 si,  0.0 st
    %Cpu2  : 76.5 us,  6.4 sy,  0.0 ni, 14.8 id,  1.0 wa,  0.0 hi,  1.3 si,  0.0 st
    %Cpu3  : 79.9 us,  4.7 sy,  0.0 ni, 14.1 id,  0.7 wa,  0.0 hi,  0.7 si,  0.0 st
    %Cpu4  : 85.6 us,  3.7 sy,  0.0 ni,  9.4 id,  0.3 wa,  0.0 hi,  1.0 si,  0.0 st
    %Cpu5  : 81.4 us,  4.1 sy,  0.0 ni, 13.2 id,  1.0 wa,  0.0 hi,  0.3 si,  0.0 st
    %Cpu6  : 87.6 us,  4.4 sy,  0.0 ni,  5.4 id,  0.7 wa,  0.0 hi,  2.0 si,  0.0 st
    %Cpu7  : 85.2 us,  5.4 sy,  0.0 ni,  8.4 id,  0.7 wa,  0.0 hi,  0.3 si,  0.0 st
    KiB Mem : 15731892 total,  1074660 free,  7042760 used,  7614472 buff/cache
    KiB Swap:        0 total,        0 free,        0 used.  8349352 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
     6515 27        20   0 3916212 325008  13304 S 547.0  2.1 715:56.39 /opt/rh/rh-mysql57/root/usr/libexec/mysqld --defaults-file=/etc/my.cnf
     3868 root      20   0 9706460 804212  14332 S  61.3  5.1 113:43.58 java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=1100 +
    29812 1000      20   0 1942964 243780   9608 S  25.5  1.5   0:38.93 java -Xms512m -Xmx512m -Duser.timezone=Asia/Shanghai -Djava.io.tmpdir=/tmp -cp classes zipkin2.dependencies.ZipkinDependenciesJob
    25306 nfsnobo+  20   0 2599060 489856  51700 S   7.3  3.1  59:17.13 /bin/prometheus --config.file=/etc/prometheus/prometheus.yml --web.enable-lifecycle --storage.tsdb.path=/prometheus --storage.tsdb.retention.time=10d --web.console.libr+
     1189 root      20   0 1275732 108700  30124 S   6.6  0.7  92:33.30 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
     1174 root      20   0 2271884 104784  36608 S   4.3  0.7 152:25.24 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network+
    22095 root      10 -10  200708  33180  15344 S   2.0  0.2   6:42.03 /usr/local/aegis/aegis_client/aegis_11_17/AliYunDun
    24216 1000      20   0 2068796 486356  13508 S   2.0  3.1   5:23.46 java -Xms512m -Xmx512m -Dlogging.level.zipkin=DEBUG -Dlogging.level.zipkin2=DEBUG -Duser.timezone=Asia/Shanghai -cp . -Dlog4j2.disable.jmx=true org.springframework.boot+
     3850 root      20   0  109096   8148   2652 S   1.7  0.1   3:10.85 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/0be4d32538621f4f99f2837f37f860c939fd9f3bf0faeb7b84c7da4ee0e38f68 -addre+  3773 1000      20   0 7509920   3.4g  22540 S   0.7 22.6  30:48.27 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.head+
        1 root      20   0   44252   4672   2656 S   0.3  0.0   2:04.64 /usr/lib/systemd/systemd --switched-root --system --deserialize 22                                                                                                            6 root      20   0       0      0      0 S   0.3  0.0   0:30.63 [ksoftirqd/0]
      414 root      20   0  149560  77504  77136 S   0.3  0.5   2:19.20 /usr/lib/systemd/systemd-journald

从top的数据来看，问题在于mysql消耗的CPU较高。

定向监控分析

在我的经验中，这种时候就可以直接到innodb_trx里面蒙一把了，里面大概率是能看到慢日志的。我们在查询innodb_trx表中的数据时要多查几次，如果同一事务ID持续了一段时间，那就是明显慢了。当然，如果你开启了慢日志，可以到慢日志里去查看。

果不其然，我在这里确实抓到了可能比较慢的SQL。我们取出它的执行计划看看。

因为ot表上是全表扫描，涉及到10万条数据，这数据太多了，又没走索引。我们执行语句，添加一个索引。

alter table mall.oms_order_item add index index_order_id(order_id) ;
    analyze table mall.oms_order_item;

再次查看执行计划看看区别：

这回，从rows那一列是不是看到了明显的变化？ot表相关的type也变成了我们添加的索引。这种问题，应该说是非常常见了。

这时候我又刷新了几下innodb_trx表，又找了几个走全表扫描的SQL。各自添加索引之后，我们再回去看一眼TPS：

截图里这种情况就有点奇怪了呀。很显然在刚才改索引的时候，TPS是上去过的，你可以看一下23：24分之前的那一段，TPS曾经达到过800左右。但是中间却断了一会儿，这里应该是和我刚才执行的添加索引、分析表的SQL语句有关。我们再观察一会儿：

可以看到，报错之后压力并没有变化，但TPS是在逐渐恢复的。这是个好的方向。这时候我们再回来看看资源使用的情况：

还记得上面我们看到的是s12资源使用率多吗？现在已经转移到了s6身上了吧。这说明上一个问题已经解决，现在是个新问题了。

第二阶段

接下来我们再运行一段时间场景，看看还有啥问题。

这里还是有一些报错。我查了一下日志，发现是因为库存不足。

2021-12-01 23:39:53.327 ERROR [mall-order,,,] 1 --- [io-8084-exec-18] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.dunshan.mall.common.exception.ApiException: 库存不足，无法下单] with root cause
    
    com.dunshan.mall.common.exception.ApiException: 库存不足，无法下单
    	at com.dunshan.mall.common.exception.Asserts.fail(Asserts.java:11)
    	at com.dunshan.mall.order.service.impl.PortalOrderServiceImpl.generateOrder(PortalOrderServiceImpl.java:190)
    	at com.dunshan.mall.order.service.impl.PortalOrderServiceImpl$$FastClassBySpringCGLIB$$9b833cea.invoke(<generated>)
    ......................

业务的问题比较好处理，加上库存就行了。

从上面这张图我们也可以看到，TPS一直稳稳地在近600左右。

资源使用率方面呢，根据上面的全局监控，我们可以知道s6上的资源使用率过高。所以我们要登录到这台主机，看看是什么进程导致的。

top - 23:45:54 up 14 days,  8:12,  2 users,  load average: 18.57, 16.12, 11.52
    Tasks: 126 total,   2 running, 124 sleeping,   0 stopped,   0 zombie
    %Cpu0  : 70.9 us, 13.6 sy,  0.0 ni,  2.3 id,  0.0 wa,  0.0 hi, 13.2 si,  0.0 st
    %Cpu1  : 71.1 us, 16.5 sy,  0.0 ni,  8.9 id,  0.3 wa,  0.0 hi,  3.1 si,  0.0 st
    KiB Mem :  8008964 total,   173104 free,  2266508 used,  5569352 buff/cache
    KiB Swap:        0 total,        0 free,        0 used.  5433884 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    31288 root      20   0 4624912 536084  12736 S 100.3  6.7  19:48.18 java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=1100 +
     7931 root      20   0 4637452 697772  12728 S  60.5  8.7  90:39.72 java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=1100 +
     1473 root      20   0  675600  94608  26768 S  16.6  1.2 540:03.39 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
     1894 root      20   0 1729636  90460  35948 S   2.3  1.1 618:52.03 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network+
    21598 root      10 -10  197132  27972  15480 S   2.3  0.3  10:07.67 /usr/local/aegis/aegis_client/aegis_11_17/AliYunDun
    31271 root      20   0  107688   3380   2556 S   2.3  0.0   0:27.37 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/e15c7ab19edcf9e3e02a3a03f2f8c4dc80232b6af2795eb70f4c12b0dd821f11 -addre+
     7913 root      20   0  109096   5620   2716 S   1.7  0.1   3:33.94 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/4516faf8c4c2f8545e63224a793f60c17a21eee0ef5a4585cba2842063c78067 -addre+
        9 root      20   0       0      0      0 R   0.3  0.0  11:05.99 [rcu_sched]
      609 root      20   0  835660  26056   7852 S   0.3  0.3  58:34.33 CmsGoAgent-Worker start
     2927 1000      20   0  141496  29604  12708 S   0.3  0.4  13:10.48 /metrics-server --cert-dir=/tmp --secure-port=4443 --kubelet-insecure-tls=true --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,externalDNS
    ................

通过top中的process table，我们看到上面有两个Java的进程，由于名字太长看不全，不知道是什么具体的服务。这种情况是有多个服务跑在了一个2C的s6上。接下来，我们查看一下s6上有什么Pod：

[root@s5 runMall]# kubectl get pods -n default -o wide | grep s6
    kafka-1                                   1/1     Running     48         13d     10.100.1.3       s6     <none>           <none>
    node-exporter-rqgrx                       1/1     Running     0          3d4h    172.31.184.226   s6     <none>           <none>
    svc-mall-cart-dd5db86d7-dcwdd             1/1     Running     0          3d23h   10.100.1.14      s6     <none>           <none>
    svc-mall-order-67cd58db5-ht5mb            1/1     Running     0          12m     10.100.1.15      s6     <none>           <none>
    [root@s5 runMall]#

果然，这里有两个服务，还都是重要的服务。对一个2C的虚拟机来说，能跑近600的TPS，我觉得已经挺好的了，不能再指望更高的TPS了。为了让TPS再高一些，我把Order服务移到s8上去，因为s8感觉没用上。

把Order服务从s6移到s8之后，再执行一会场景，查看压力数据：

看起来不错哦，TPS从600左右上升到了960左右。

接着我们再回来看一下全局监控数据：

资源使用率也比之前高了不少。

看起来，我们的系统已经要进入到正常的系统状态了，到这里，预压测也就可以结束了。下节课，我们就可以上更大一些的压力接着玩了。

总结

好了，这节课就讲到这里。刚才，我们对容量场景进行了预压测。

其实这个过程和正式的容量场景没有什么区别，只是压力线程少一点而已。预压测可以验证场景设置、参数化数据、网络环境、硬件环境等内容。它可以让我们在执行正式的场景的时候，不至于出现耗时的问题。像这节课讲的“索引”这种基础问题，就应该在预压测的时候就解决掉，不应该出现在大压力的场景之中。

在很多人的性能思路中，基准场景就是拿三五个压力线程运行一下，而预压测的过程则根本不存在。但是在我的RESAR性能工程的理念中，在真正模拟生产峰值的容量场景之前，是有必要加上预压测的部分的。预压测使用的是生产的业务模型，是混合的业务场景。预压测的存在可以给容量场景做好充分的铺垫。

课后题

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

预压测是不是必须的呢？
不做预压测会带来什么问题？

欢迎你在留言区与我交流讨论。当然了，你也可以把这节课分享给你身边的朋友，他们的一些想法或许会让你有更大的收获。我们下节课见！

大师兄