三台服务器一起压测TPS，不是把三台单机结果简单相加，而是先用一台压出单机基线，再上三台看集群实测值，最终以负载均衡入口处的聚合TPS为准，同时盯住每台机器的资源水位，谁先到瓶颈谁就是那个“天花板”。
很多团队刚开始都以为“3台 = 3倍”，配好环境就满怀期待地开跑，结果一测，发现总TPS只有单机的2倍出头，甚至更低，然后就开始怀疑配置、怀疑网络、怀疑工具，其实这背后是压测方法论的问题，不是服务器“不努力”，下面我用实战视角把这套计算逻辑拆开，讲清楚怎么算、怎么测、怎么判断。
三台服务器压TPS的核心计算逻辑
单机基线是起步，不是天花板
先把三台机器全部停掉接入，单独对其中一台施加压力，压出这台机器在当前业务模型下的稳定TPS，比如单机实测800 TPS，这就是你的基线值，这个数值要保证是在CPU、内存、磁盘IO都没出现严重瓶颈的前提下测出来的，最好连续跑5分钟，取稳定区间平均值,而不是盯着瞬时峰值看。
集群TPS不是求和，是“共享同一条链路”的结果
一个常见的计算误区是拿单机800乘以3，觉得应该有2400，但实际上三台服务器一般会挂在同一个负载均衡（Nginx、SLB、LVS均可）后面,集群总TPS取决于三个因素：
- 负载均衡的转发能力本身有没有成为瓶颈
- 三台机器的资源是否均衡分配（若存在热点不均,总TPS会被最弱的那台拖住）
- 业务本身是否存在共享资源争抢，例如数据库连接数、缓存带宽
行业共识认为，无状态服务在三台水平扩展时，合理预期是单机TPS的8到2.8倍，只有少数纯计算型、缓存友好的场景能跑到接近3倍的线性扩展,这属于公开的性能工程常识。
计算方式：以端到端入口侧为统计口径
假设你用JMeter压测，压的是负载均衡的VIP地址，那么TPS统计应该直接看聚合报告里的 Throughput（吞吐量） 这一列，单位是/sec，这个值本身就是三台机器共同处理的总TPS，如果你想验证每台机器的实际处理量，可以分别登录三台服务器，在Nginx日志里统计每秒请求数,加在一起应该约等于JMeter报告里的总TPS。
正确的“计算”思路是：
- 压测入口：负载均衡地址（三台的统一入口）
- 统计出口：JMeter聚合报告的总吞吐量
- 验证口径：对比三台机器各自access_log每秒请求量之和
- 修正因子：若数据库或Redis成为热点，总TPS还要扣除等待时间导致的部分失败或超时
三台服务器压TPS的实操流程
第一步：确认压测环境与目标接口
压测前先确定好是压HTTP接口还是RPC服务，接口类型不同，压出来的TPS含义天差地别，这里我以最常见的HTTP短连接请求为例，同时要明确是有状态会话还是无状态请求,无状态场景下的水平扩展是最顺畅的。
第二步：配置JMeter或压测工具的参数
JMeter线程组设置是大多数人踩坑的地方，三台服务器跑集群，不等于压测机也要开三倍并发，启动线程组时，先用200线程、1秒拉起跑一轮，观察响应时间中位数，如果P95在100ms以下，再逐步增加线程数，每次增加100，持续加压到报错率超过1%为止。
关键参数参考：
- Ramp-Up Period（爬坡时间）：建议至少5秒
- Loop Count（循环次数）：改成确保压测总时长不低于300秒
- Timeout（超时时间）：建议连接超时5秒、响应超时10秒
第三步：执行压测并记录每台服务器的水位
压测过程中，除了看TPS，还要同时开三个SSH窗口，分别登录三台服务器，执行top、vmstat、iostat来观察资源使用率，因为集群总TPS本质上是受限于最先耗尽的那种资源,建议每5秒记录一次以下数据：
- CPU us+sy是否超过80%
- 内存可用量是否持续下降
- 磁盘util是否超过70%
- 网络带宽入口流量是否接近打满（用
iftop看一眼）
如果三台机器的CPU使用率都在70%以下但TPS已经不再增长，那瓶颈几乎可以断定不在后端服务器上,而在负载均衡层或压测机本身的线程池上。
第四步：汇总数据，算出集群TPS的修正值
举个例子，假设在压测入口测得的聚合TPS是2100，但三台机器各自的access log统计分别是720、710、704，加总为2134，两者基本吻合，此时单机基线为800，那么集群的真实扩展效率就是2100 ÷ (800×3) = 87.5%，这个数字是评估“三台服务器一起压TPS算不算正常”的硬指标，高于80%就算健康。
三台服务器的常见压测场景差异对比
| 场景类型 | 单机基线TPS | 三台期望TPS | 主要瓶颈点 |
|---|---|---|---|
| 纯静态资源服务 | 1200 | 3400~3600 | 网卡带宽 |
| 动态接口/数据库读写 | 800 | 1900~2300 | 数据库连接池 |
| 大量本地日志落盘 | 550 | 1200~1500 | 磁盘IO |
| 高CPU密集计算 | 400 | 1100~1200 | CPU核心数 |
从上表可以看到，三台服务器一起压TPS怎么算，核心逻辑始终是“找到瓶颈，再看扩展效率”，不同业务的差异往往比服务器数量的差异还大，这正是很多团队表示“加了机器但TPS没翻倍”的原因，如果问压测tps看哪个指标，答案就是聚合报告里的Throughput,以及后端每台机器的CPU和外网带宽。
集群TPS上不去的典型原因与排查路径
数据库连接数被打满
三台服务的线程池此时还在等待数据库响应，TPS曲线就会趋于平坦，排查方法很直接，登录数据库执行show processlist;，看有没有大量Sleep连接，或者执行show status like 'Threads_connected';，如果连接数已经逼近max_connections，则加机器没用,得先加连接数或上缓存。
负载均衡出口带宽不够
三台服务器都是千兆网卡，但入口带宽只有200Mbps，那整体TPS到一定值就会卡死，这种场景下，继续加大并发只是增加延迟，总吞吐量纹丝不动，排查方法是登录负载均衡机器看ip -s link里的RX/TX字节数,基本超过900Mbps时就已经到上限了。
压测机自己先崩溃了
这个容易被忽略，JMeter跑分布式压测，如果单台压测机开几千个线程反而会让压测机CPU被上下文切换塞满，发出的请求不再均匀，导致后端TPS惨不忍睹，一般建议三台服务器对应三台压测机,或者用一台高配压测机但限制线程数到800以内。
KeepAlive与连接复用参数混乱
HTTP短连接场景会造成大量TIME_WAIT，消耗本地端口资源，最终表现为间歇性连接超时，如果压了30分钟之后TPS突然掉了一半，第一步就检查netstat -s | grep TIME_WAIT，数量超过3万就要在处理端开启KeepAlive，把连接复用起来,你会发现单机TPS就能涨三成。
如何验证“三台服务器一起压TPS”的结果是否可靠
压测结束时别急着下结论,先看两个数据：
- 错误率是否保持0%，如果超过了1%，这个TPS数值只能算参考值
- 响应时间的P95是否在预期范围内，如果P95从80ms涨到500ms，虽然TPS数字没降太多，但用户体验已无法接受，不能算有效结果
还有一种情况值得注意：核对三台机器在压测时间内的实际请求分担比例，好的负载均衡策略应该让三台请求量比例接近1:1:1，若出现某台机器只承受了20%的请求，先查权重配置是否一致、连接是否均匀,再考虑这一台是不是有健康检查问题。
关于三台服务器压TPS的常见疑问
单机压测TPS多少合适？是否有个行业参考值？
不存在统一标准，但可以给一个经验区间作参考，一台4核8G的普通云服务器，压短平快的JSON接口，通常单机TPS在300到1000之间，如果是8核16G加上异步非阻塞模型，2000以上也不奇怪，关键是你的基线值要基于自身业务实测,而不是网上随便找一篇别人的压测数据来对标。
压测三台服务器时，是用一台压测机还是多台压测机？
建议用多台压测机分摊压力，尤其是当目标TPS预期超过1万时，单台JMeter压测机在几千并发时可能出现性能瓶颈，产生不真实的瞬时尖刺，导致后端集群收到的流量忽高忽低，最终得出的“总TPS”缺乏参考意义,还会被误判为集群性能不稳定。
三台服务器压出的TPS结果低于单机加总预期，应该先调什么？
先调超时参数与连接池配置，很多情况下这三台的资源并没有跑满，而是接口里调用了外部服务，例如数据库、Redis、第三方API，这些依赖服务的连接数上限把TPS锁死了，先确认高频依赖的瓶颈，再去动服务器的内核网络参数，比如net.core.somaxconn和net.ipv4.tcp_tw_reuse，循序渐进，每一步改完都重新压一轮，留好前后对比记录,不要一次性全改。
三个实例一起压TPS这件事，说到底就一句话，先有单机基准值，再看入口聚合值，最后用资源水位解释差异，掌握这套流程后，你不仅能算出具体数字，还能解释这个数字为什么是这个样,这就比单纯跑个报告有意义得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/628047.html
