企业官网建设流程全解析

1. 为什么单机压测会“卡脖子”：分布式到底解决什么问题

1.1 单机压测的瓶颈到底在哪

做性能测试时间长了，你会发现一个特别真实的现象：脚本在本机跑得好好的，线程数一加到上千，JMeter进程自己先把宿主机的CPU吃满了，网卡也打满了，最后压出来的曲线跟心电图似的，跳得没法看。这不是目标服务扛不住，而是压测工具自己先趴下了。JMeter的分布式性能测试，就是解决这个问题的标准姿势——把压力生成从一台机器拆到多台机器上，用一组Worker节点去分担负载，再用一个Controller节点统一下发脚本和收拢结果。

为什么会这样？JMeter本质是一个Java进程，它发起请求时，每个虚拟用户对应一个线程，每个线程在内存里要维护自己的上下文、结果采样、聚合数据。线程数上去之后，JVM堆内存、GC、线程上下文切换、socket文件描述符这些资源都会被快速吃掉。我实测过一个8核16G的压测机，压一个很轻量的JSON接口，单机跑到1000并发，JMeter进程的CPU已经飙到85%以上，GC停顿明显，目标服务的响应时间波动反而比低并发时更大——这个数据根本没法用。

很多人这时候以为目标服务到了瓶颈，其实完全不是。压测机自己先到瓶颈了，给目标服务制造的压力从“一个巨大的稳定流量”变成了“一阵一阵的毛刺流量”，后面的分析全得推翻。要判断压测机是不是瓶颈，最简单的方法就是一边压一边看压测机的资源占用：CPU超过80%、内存占用持续攀升、网络打满，那就说明压测端饱和了。还有一个更直观的方式，用top看JMeter进程所在CPU是不是一直在user态非常高，同时目标服务所在机器的CPU可能还不到50%，这种对比反差，基本就是压测机瓶颈的实锤。

1.2 什么时候该上分布式，什么时候不该上

我见过不少团队把分布式当成压测的“银弹”，脚本还没调好就直接开10台机器压，结果问题出在参数化数据没分发、每台机器都在用同一个账号并发，甚至因为结果汇总机制理解错了，最后导出的数据对不上。分布式压测引入了新的复杂度和新的故障点，它不是用来弥补脚本缺陷的。

我的建议是出现下面几种情况再考虑分布式：第一，单机压测时压测机自身CPU或内存已经超过80%，继续加并发会出现明显的抖动；第二，要模拟的并发用户量很大，比如成千上万，单台机器无论如何开不出这么多稳定线程；第三，需要从多个来源入口同时发起流量，模拟真实世界的多节点访问。前两条是最常见的，第三条属于高级场景。

但如果你的接口只是压200并发、单机CPU只用了40%，那根本没必要上分布式。先优化脚本、减少无用监听器、关掉不必要的断言，调过一轮之后再判断。注意，这里说的监听器优化是个大坑：聚合报告、察看结果树这类GUI组件在命令行压测时应该去掉，它们会占用大量内存和IO，尤其结果树会在取样时做额外序列化。先做这些低成本的优化，再考虑架构层面的扩容，是我一直坚持的顺序。

2. 分布式压测原理与架构：Master-Slave到底怎么工作

2.1 Master和Slave的分工

分布式JMeter用的是典型的Master-Slave架构，也叫Controller-Worker。Master就是那台你用命令行发起压测的机器，Slave是被远程拉起的worker节点。Master不直接执行测试逻辑，它负责三件事：把jmx脚本分发给所有Slave、通知Slave开始执行、接收Slave回传的采样结果；Slave才是真正干活的人，每个Slave加载完整的测试计划副本，在自己本机创建指定数量的线程组并发请求。

这里有个大家容易理解的误区：不是Master和Slave把线程拆开平分、然后各自负责一部分接口。实际上每个Slave都会完整地跑一遍脚本，也就是说，如果你在Master上配置了一个线程组，里面有500个线程，那么每一台Slave都会起500个线程。3台Slave加起来就是1500并发。这个数量认知非常重要，设计测试方案的时候，先定好“每台Slave的线程数”，再乘以Slave数量，才是真正的总并发量。

Worker回传结果的方式也值得说一句。JMeter从4.0开始改进过RMI通信的配置方式，每个Slave的采样结果会打包后异步回传给Master，Master再统一聚合输出。所以在Master上看到的聚合报告、生成的HTML报告，都是集群级的总览。如果中途某个Slave掉线了，Master日志里会体现出来，但已有的结果依然会保留，不会被全部重置。

2.2 RMI通信和两个关键的端口

JMeter的分布式通信底层是Java RMI。别看它是个老协议，实践里面出坑基本都出在“没搞清楚它到底要用哪些端口”上。

一台Slave对外至少需要两个端口：RMI注册端口（默认是1099），这是Master找到Slave的入口；还有数据交换端口，需要通过server.rmi.port来固定。在大规模压测场景下，如果你没有固定server.rmi.port，Java会随机挑一个可用端口来传输数据，防火墙一开，Master和Slave之间的数据回传就会失败，表现就是Slave启动了、Master也连上了，但压测开始后迟迟收不到结果。

所以标准做法是在每台Slave的jmeter.properties里显式设置：

server.rmi.port=10991 server.rmi.ssl.disable=true

然后把1099和10991都放行。注意，这里的放行是双向的：Master能访问Slave的两个端口，Slave回应Master时，Master本地的随机高位端口也需要能进出。最粗暴但有效的排查姿势是：先在Slave上启动jmeter-server，然后单独开一个JMeter客户端GUI，在“运行-远程启动”里逐个试连，能看到结果就说明网络通了。GUI模式下其实就是分布式压测最直观的验证方式，虽然压测时不推荐开GUI，但第一次联调用它非常合适。

3. 环境准备与实操配置：从零跑起一套分布式集群

3.1 版本、JDK、hostname这些硬前提

先说版本。Master和所有Slave的JMeter版本必须一致，最好连JDK版本都保持一致，我踩过最深的坑就是Master装的是JDK11、Slave还留在JDK8，远程启动报各种莫名的序列化错误。建议直接统一用JMeter 5.6.3配JDK11，官方下载包解压即用，安装配置教程网上到处都是，但版本一致这个原则很少被强调。JMeter没有动态兼容老版本Slave的机制，老版本脚本文件虽然能打开，远程协议却未必兼容。

然后是hostname解析。很多人启动jmeter-server看到日志里写的是“server listening on /127.0.0.1:1099”就很开心，以为起来了，结果Master远程创建引擎时连不上。原因是Slave机器没有把自身hostname解析到内网IP，RMI回绑时用了回环地址。解决办法很简单：编辑/etc/hosts，把当前机器的hostname映射到内网IP，让JMeter知道该对外广播哪个地址。

# /etc/hosts 192.168.1.11 jmeter-worker-01

改完重启jmeter-server，再留意日志里监听地址是否变成了192.168.1.11。这个细节排查起来特别费时间，但处理成本极低，属于必须提前做的基础动作。

3.2 jmeter.properties里到底要改哪几项

打开bin目录下的jmeter.properties，我习惯只关注这几项，其它的保持默认：

# 控制端：指定所有worker地址，用逗号分隔 remote_hosts=192.168.1.10,192.168.1.11,192.168.1.12 # 数据交换固定端口 server.rmi.port=10991 # 内网压测直接关闭RMI SSL，证书不一致太折腾 server.rmi.ssl.disable=true # 压测结束后强制退出JVM，避免残留进程占端口 jmeterengine.force.system.exit=true # 结果传输模式 mode=Standard

remote_hosts这行，如果只用命令行-R参数可以不写，二者选一；我的习惯是都写上，因为某些JMeter版本在UI远程启动时只认配置项。

关于mode，这里解释清楚：Standard代表每个采样结果生成后立即回传，实时性最好，但Master的IO压力大；StrippedBatch是异步攒一批再回传，能明显降低网络和Master的负载，但结果统计会有滞后。短时间高并发压测用Standard，长时间稳定压测用StrippedBatch，别反过来用。

所有Slave机器都要把jmeter.properties改好，尤其server.rmi.port和ssl.disable。控制端单独改remote_hosts就够了。改完之后，在每台Slave的bin目录执行：

# 前台启动，便于看日志 ./jmeter-server

如果有很多台Slave，用nohup后台启动：

nohup ./jmeter-server > /tmp/jmeter-server.log 2>&1 &

启动成功的标志是日志出现类似“Creating rmiregistry server bound to port 1099”和“Server started ...”。

4. 脚本改造、参数调优与一次完整实操

4.1 分布式下必须改的脚本细节：CSV、断言、依赖jar

脚本是另一个大坑。你辛辛苦苦录好的JMX脚本，在单机跑得好好的，丢到分布式环境里经常出现“文件找不到”或者“每台跑的数不一样”。

先说CSV参数化。CSV Data Set Config默认读取的是相对路径，而不同节点的JMeter工作目录可能不一样。最稳妥的方式是把CSV文件放到每台Slave的JMeter bin目录下，脚本里填写相对路径，或者拷贝到一致的绝对路径。压测前逐台检查文件是否存在，别只检查Master自己的。还有Shared Mode，分布式环境下这个选项表示的是“在同一台Slave的同一进程内共享”，不是跨Slave共享，所以不同Slave会各自从CSV头部按顺序读取。要避免一个账号被多台Slave同时使用，可以把每台Slave的CSV文件做错位处理，或者给CSV加上动态参数拼接。

再说道监听器和断言，尤其经常被搜到的beanshell断言。Beanshell是JMeter里默认内置的脚本语言，但它是解释执行的，性能非常差。我之前压了一个带复杂校验的接口，用Beanshell断言在每轮采样里做字符串匹配，单机压测CPU多花了30%，分布式的成本会按机器数翻倍放大。正确的做法是用JSR223取样器或JSR223断言，语言选Groovy，预编译执行，性能好一个数量级。Groovy脚本里能用到的类，注意要把依赖jar放到所有Slave的lib目录下，否则你在Master本地写的引用到了Slave上就是NoClassDefFoundError。

还有一个特别隐蔽的坑：取样器里依赖的外部文件，比如jks证书、上传的文件附件。上传文件接口的路径每台Slave都要存在，否则部分节点会直接报错，但其它节点还在正常压测，最终数据混杂在一起，非常难排查。我的做法是在压测前的检查清单里明确列出一项“所有外部依赖文件已同步到所有Slave”，宁可多花几分钟，也不要跑完发现数据没法用。

4.2 一次完整的分布式压测实操记录

下面用一个实际案例串一遍完整流程。假设目标接口是一个简单的GET接口，需要模拟1500并发，准备3台2核4G的Slave和1台控制机。

第一步，先确认脚本在单机环境下能用。本机100并发跑一遍，看接口响应正常、吞吐量数据稳定，再进行后续步骤。这一步能过滤掉90%的脚本问题。

第二步，配置环境。三台Slave按上面的方法改好jmeter.properties，启动jmeter-server。控制机上写好remote_hosts。验证连通性可以这样登录控制机执行：

jmeter -n -t test.jmx -R 192.168.1.10,192.168.1.11,192.168.1.12 \ -l result.jtl -e -o report

第一次跑建议线程组里每个Slave设置500线程，循环次数设个1次或2次，先看能不能跑通、结果能不能正常回传。

第三步，跑完整压测。真实场景下线程组一般设置循环次数为持续时间，比如300秒，方便观察曲线。压测启动命令加上-g参数可以在结束后直接用GUI打开聚合报告：

jmeter -n -t test.jmx -R 192.168.1.10,192.168.1.11,192.168.1.12 \ -l result.jtl -e -o report -g result.jtl

压测完成后直接用浏览器打开report目录下的index.html即可。JMeter 5.6.3生成的HTML报告里，需要重点看三个地方：第一个是Summary里的吞吐量，第二个是响应时间的90%、95%、99%分位线，第三个是按线程组分开的详情页里的错误率。

如果你需要在linux压测过程中直接查看压测接口的响应内容，我建议给脚本加一个简单的Sample Result Save Config或者“察看结果树”并勾选保存响应字段，然后压测结束后在JTL文件里搜索关键字。这里有一个经验：不要在持续压测时开着“察看结果树”来实时看响应，它会把你压测机的内存直接拖垮。正确的方式是把响应保存到文件，压测完再查，不影响压测过程。

4.3 聚合报告和命令行报告，怎么读才准

最后说结论解读。聚合报告里的Samples是集群所有采样点的总和，Errors是所有Slave的失败总数，Throughput是Master端统计的集群总吞吐。注意，如果你的压测脚本里定义了多个请求，聚合报告会把每个请求单独列出来，也会有一个ALL汇总。常用指标我放了一张速查表：

这里还有一个很多人都没注意的点：聚合报告是间隔取样汇总的，它的统计间隔默认比较粗，所以用命令行执行压测后，最好再单独生成HTML报告，里面的时序图、分位数都比聚合报告可靠得多。我早期做分布式压测，直接用GUI聚合报告里的吞吐量当最终结果，跟后来用命令行报告一对比，差了10%以上，就是因为取样间隔导致的统计差异。数据采集方式不同，结论就可能不同，这比压测本身更值得警惕。

5. 常见问题与排查技巧实录

5.1 启动与连接类问题

分布式压测的问题，我按照出现频率整理了一份排查清单。

第一类是远程启动失败。日志里出现“Remote-Disconnect, ensure to remove the property”或者“Failed to create the engine”，大概率是：版本不一致、hostname解析错误、防火墙没放行1099。按前面说的三步走：统一版本、改hosts、放行端口。如果还不行，加上-server的日志参数跑一次看Slave端的具体报错，基本都能定位。

第二类是RMI的SSL握手失败。报错里能看到“SSL”关键字。内网压测直接把server.rmi.ssl.disable=true加进去就行，不用重复生成证书。

第三类是端口被占用。特别是频繁重启压测机之后，java进程没退干净，1099或10991被占，启动jmeter-server时日志会明确报“Address already in use”。用jps或netstat找出残留进程，kill掉再重启。这正是上面配置jmeterengine.force.system.exit=true的原因，压测结束自动退出，省得手动清。

5.2 压测过程中的数据类问题

真正解决起来最费时间的是压测运行中的问题。这里我把搜索里那个典型的报错单独挑出来讲：org.apache.http.conn.httphostconnectexception: connect to。出现这个报错，意思是JMeter在向目标接口建立TCP连接时失败了。有两种情况：一种是目标服务本身连接数打满，连接池耗尽，点开错误时间窗口去看服务端的监控指标；另一种是压测机侧在大量新建连接时，触发了系统的文件描述符上限，导致部分socket创建失败。

排查时先在Slave上看看当前连接状态：

netstat -an | grep 目标IP | grep SYN_RECV | wc -l

如果SYN_RECV数量巨大，说明服务端backlog队列已满，客户端请求排不上队，这时优先看服务端配置；如果Slave本地报“too many open files”，那就是ulimit -n不够，调大文件描述符上限：

ulimit -n 65535

结果数据对不上也是高频问题。压测完发现总请求数比预期的“Samples = 线程数 x 循环次数 x Slave数”少，大概率是某个Slave中途掉线，回传数据不完整。排查思路是去每台Slave的日志里看有没有OOM、GC或socket异常，如果有Slave挂了，Master的jtl里对应的那部分数据就是缺失的。所以分布式压测做完后，把每台Slave的本地结果都保留一下，别只依赖Master的汇总，合并出现偏差时还能对比。

5.3 压测机侧的资源调优建议

分布式压测虽然拆了压力，但每台Slave本身还有优化空间。记住几个关键点：文件描述符要放开，ulimit -n至少65535；JVM堆内存不要无脑调大，容易触发Full GC，建议两台4G内存的Slave就配-Xms1g -Xmx2g，8G内存配3G左右；压测机上如果跑着太多无关服务，先停掉，尤其是那种自动更新的守护进程，会让压测曲线莫名抖动。

还有一个很重要的事：第一次压测时在每台Slave上单独跑一遍脚本，把线程数压到目标值，看单个Slave的CPU是否接近100%。如果单台Slave就CPU 100%了，说明脚本里的监听器、断言、日志输出消耗太大，先回4.1节做脚本优化。反之，如果单台Slave CPU才20%，却还要继续加机器，那就不是在解决瓶颈，只是把数据变得更复杂而已。

系统内核相关的网络参数调整，我的建议是压测专用的Slave再改，共用机器别动内核。核心就几个：net.ipv4.tcp_tw_reuse=1解决TIME_WAIT复用问题，net.core.somaxconn适当调大解决连接排队，net.ipv4.ip_local_port_range建议扩大段。改完sysctl -p生效，不要在每个压测周期反复改，改了之后前后数据就不具可比性了。

最后再分享一个小技巧：我在每次分布式压测前，都会在脚本的线程组里加一个极短循环的验证任务，只用1个线程跑2次，用来检查集群连接、数据文件、断言是否都正常。跑通了再把循环次数调回真实压测值。这个习惯帮我省了大量返工时间，比任何一种排查技巧都管用。毕竟分布式压测一分钟的机器成本不低，跑一通无效数据，后面所有分析都要从头再来。