正文
用
jmeter
压测的时候，如果压测时间过长，记得关掉
监听器->图形结果
面板，因为那个渲染如果时间太长基本会假死，误以为会是内存的问题，其实是渲染问题。
在开发做基准压测的时候有一个问题就是办公网络与压测服务器的网络之间的带宽问题，压力过大会导致办公网络出现问题。所以需要错开时间段。
大致梳理好后，我们需要通过一些工具来查看下基本配置是否正常。比如，
ethtool
网络适配器信息、
nload
流量情况等等，当然还有很多其他优秀的工具用来查看各项配置，这里就不罗列了。
使用
ethtool
查看网络适配器信息前需要先确定当前机器有几个网络适配器，最好的办法是使用
ifconfig
找到你正在使用的网络适配器。
![]()
排除
127.0.0.1
的适配器外，还有三个适配器信息，只有第一个
bond0
才是我们正在使用的，然后使用
ethtool
查看当前
bond0
的详细适配器信息。重点关注下
speed
域，它表示当前网络适配器的带宽。
![]()
虽然网络适配器可能配置的没有问题，但是整个网络是否没问题还需要咨询相关的运维同事进行排查下，中间还可能存在限速问题。
要确定网络带宽确实没有问题，我们还需要一个实时的监控网络流量工具，这里我们使用
nload
来监控下进出口流量问题。
![]()
这个工具还是很不错的，尤其是在压测的过程中可以观察流量的进出口情况，尤其是排查一些间隙抖动情况。
如果发现进口流量一直很正常，出口流量下来了有可能系统对外调用再放慢，有可能是下游调用
block
，但是
request
线程池还未跑满，也有可能内部是纯
async
，
request
线程根本不会跑满，也有可能是压测工具本身的压力问题等等。但是我们至少知道是自己的系统对外调用这个边界出了问题。
Linux openfiles limit 设置
工作环境中，一般情况下
linux
打开文件句柄数上限是不需要我们设置的，这些初始化的值运维同事一般是设置过的，而且是符合运维统一标准的。但是有时候关于最大连接数设置还要根据后端系统的使用场景来决定。
以防万一我们还是需要自己检查下是否符合当前系统的压测要求。
在
Linux
中一切都是文件，
socket
也是文件，所以需要查看下当前机器对于文件句柄打开的限制，查看
ulimit -a
的
open files
域，也可以直接查看
ulimit -n
。
![]()
如果觉得配置的参数需要调整，可以通过编辑
/etc/security/limits.conf
配置文件。
排查周边依赖
要想对一个服务进行压测，就需要对这个服务周边依赖进行一个排查，有可能你所依赖的服务不一定具备压测条件。并不是每个系统的压测都在一个时间段内，所以你在压测的时候别人的服务也许并不需要压测等等。
还有类似中间件的问题，比如，如果我们依赖中间件
cache
，那么是否有本地一级
cache
，如果有的话也许对压测环境的中间件
cache
依赖不是太大。如果我们依赖中间件
mq
，是不是在业务上可以断开对
mq
的依赖，因为我们毕竟不是对
mq
进行压测。还有我们所依赖服务也不关心我们的压测波动。
整理出来之后最好能画个草图，再重新
git branch -b
重新拉一个性能压测的
branch
出来根据草图进行调整代码依赖。然后压测的时候观察流量和数据的走向，是否符合我们梳理之后的路线。
空接口压测检测
为了快速验证压测服务一个简单的办法，就是通过压测一个空接口，查看下整个网络是否通畅，各个参数是否大体上正常。
![]()
一般在任何一个后端服务中，都有类似
health_check
的
endpoint
，方便起见可以直接找一个没有任何下游依赖的接口进行压测，这类接口主要是为了验证服务器的
online
、
offline
状态。
如果当前服务没有类似
health_check
新建一个空接口也可以，而且实践证明，一个服务在生产环境非常需要这么一个接口，必要情况下可以帮助来排查调用链路问题。
《发布！软件的设计与部署》Jolt 大奖图书 第17章 透明性 介绍了架构的透明性设计作用。
聚合报告中 throughput 计算
我们在用
jmeter
进行压测的时候关于
聚合报告
中的
throughput
理解需要统一下。
