企业官网建设流程全解析

做性能测试这么多年，我经常被问到两个问题：你这个压测并发数是怎么定的？这个TPS指标又是怎么算出来的？很多刚入行的同学拿着JMeter就开压，线程数随手填个500，5000，问为什么用这个数，答不上来。也有不少测了几年的人，一直停留在“用工具跑脚本”的层面，对并发量公式和TPS计算背后的逻辑没有系统梳理过，一旦场景换成就不知道怎么下手了。这篇文章我打算把这两块掰开了讲透，包括并发量怎么从业务指标推导、TPS怎么估算和验证，以及我踩过的一些坑，希望能给正在做性能测试的同学一个能直接用的参考框架。

本文适合刚接触性能测试的新手，也适合正在带团队做压测方案的老手作为参考。我不会堆理论，尽量用实际压测场景里经常遇到的情况来讲解，最后附上我实操中的经验教训，以及常见问题的排查思路。

1. 先搞清楚：并发量和TPS究竟在测什么

1.1 并发量不是“同时在线人数”

这是新手最容易混淆的一个概念。很多人一上来就说，“我们系统有5万用户在线，所以并发要模拟5万”，这个理解是有问题的。在性能测试场景里，并发量指的是同一时刻真正向服务器发起请求的用户数量，不是系统里有5万在线用户，而是这5万人里有多少人此刻正在“按下按钮”或者正在等待响应。

举个例子，一个视频App有100万日活，但用户大部分时间在浏览视频流、阅读文案，真正触发后端接口的频率很低。假设平均每个用户每小时只触发10次接口请求，那么算下来每秒的请求数就很有限，并发模型完全不是100万这个量级。如果直接拿日活当并发数去压，压测机先被自己压垮了，数据也没参考价值。

在线用户数（Online Users）和并发用户数（Concurrent Users）是两个完全不同的统计口径。我们在压测工具里填的线程数，其实更接近“同时在发请求的用户数”，线程越多，同时发给服务器的请求数就越多。这里还有一个容易混乱的概念叫“并发连接数”，比如TCP连接数，比并发请求数大不少，因为很多连接是Keep-Alive挂着的，并不代表有业务请求在跑，这也要区分开。

1.2 TPS才是衡量系统能力的“硬指标”

TPS全称是Transactions Per Second，每秒事务数，在性能测试领域，可以粗略理解为每秒完成的业务请求数。它不像并发量那样“看起来很大”，但它直接反映系统处理能力。你并发设计得再漂亮，最终服务器能不能扛住，看的是TPS曲线：能撑到多少、稳定在哪、什么时候开始下跌。

举一个日常生活的例子，一个银行柜台，排队人数很多不等于柜员办理业务很快，真正衡量柜员能力的指标是他每分钟办完几笔业务。并发用户数就是“排队窗口人数”，TPS就是“每分钟办完的业务笔数”。所以你看到系统并发用户数高，不代表它处理能力一定强，如果每笔业务都要十几秒，哪怕堆了一大堆并发请求，TPS也上不去。

1.3 两者之间的换算关系：Little's Law

并发量和TPS不是割裂的，它们之间有一个非常实用的关系式，叫Little's Law，公式很简洁：

[ C = TPS \times RT ]

其中C是并发用户数（并发请求数），TPS是每秒事务数，RT是平均响应时间（单位秒）。这个公式在性能测试里非常常用，它的意思是：系统里同时存在的请求数量，等于每秒新到的请求数乘以每个请求在系统里逗留的时间。

举个例子，如果TPS是100，平均响应时间是0.5秒，那系统里任意时刻在处理的请求数就是50。如果响应时间涨到2秒，TPS还是100，并发数就要到200。这从直觉上也说得通：请求处理得慢，单位时间内堆在系统里的请求就越多。反过来，给定目标并发数C和期望RT，也能够推算出需要达到的TPS目标。这个公式在我们设计场景时非常好用，下文会反复用到。

1.4 常见认知误区速查

结合我带团队的经验，下面这些观点经常在评审会上出现，容易把方案带偏：

记住一个表象：成千上万的在线用户只是“池子”，并发量和TPS是从池子里“舀水”的节奏和速度。理解了这一点，后文的公式才不会用错。

2. 并发量计算公式：从业务需求反推压力

2.1 核心公式的推导

并发量不是一个拍脑袋的数字，它可以从业务指标一步步推导出来。我的做法一般是这样：先明确目标业务场景和时间窗口，再估算这个窗口内的请求总量，最后除以时间得到平均请求速率，再乘平均响应时间得到并发数。

最常见的一个基础公式是这样的：

[ C = n \times p \times r \times t ]

• C：目标并发用户数
• n：系统活跃用户总数（日活、月活或特定业务用户数）
• p：用户活跃比例，也就是在某个时间段内实际会操作用户的占比
• r：单个活跃用户在单位时间内的平均请求频率（次/秒）
• t：平均事务响应时间（秒）

这个公式的本质是：任何时刻正在服务器上处理的那批请求数，等于总请求到达速率乘以每个请求平均耗时。它和Little's Law是同一个道理的另一种写法。

举个例子。某电商系统日活80万人，在晚上8点到10点属于访问高峰，假设这个时间段会有30%的用户访问（p=0.3），每个活跃用户平均每10分钟触发一个核心业务请求（比如加购、下单、支付），相当于r=1/600次/秒，系统平均响应时间目标是0.8秒。那么：

[ C = 800000 \times 0.3 \times (1/600) \times 0.8 = 320 ]

算下来并发用户数大约是320。这个数字远小于80万，但逻辑是对的：日活80万的系统，真正的并发压力可能只有几百。很多刚做压测的同学会觉得这个数太小了，但压测时你用320线程跑出来的效果，往往比随便填2000线程更接近真实生产压力。

2.2 不同场景下的并发估算变体

上面的基础公式适用于一般业务系统，但现实中的业务形态差异很大，不同场景需要调整参数。我把常遇到的几类列一下。

有明确业务流程的场景：比如用户平均每次访问会依次打开首页、搜索、详情页、加购、下单，共5个步骤，每个步骤耗时不同。此时应该先算出每个步骤的请求速率，再分别计算并发数，取各步骤中最大的作为压测目标。因为瓶颈往往出现在某一个接口上，而不是所有接口平均分配。

轮询类场景：比如消息推送、订单状态刷新，App端每3秒轮询一次。这种场景的并发模型是周期性脉冲，而不是均匀到达。轮询用户越多，对服务器的瞬间冲击越明显。估算时要把轮询周期考虑进去，例如10万在线用户，每3秒轮询一次，平均每秒约3.3万个轮询请求，按0.2秒响应时间估算，并发约6600，这个量级比普通业务接口大得多，设计时要注意接口的RT预算。

秒杀类场景：这类场景的特点是瞬时流量远大于日常，不能用日活和平均频率来算。常用的简化思路是根据“放量数量”和“预计抢完时间”反推。假设秒杀10万件商品，预计1分钟内抢完，那么TPS至少需要1667；如果单次请求RT是0.5秒，根据Little's Law，对应的并发数约为834。这个并发数适用于压测中模拟秒杀接口的线程组。更严谨的做法用排队论M/M/c模型计算，但工程上没那么复杂，按峰值流量给一个1.5到2倍冗余就够。

高并发消息推送场景：如果系统向大量用户推送消息，用户会集中打开App，产生“羊群效应”。这种场景的峰值往往出现在推送发出后的前几分钟，估算时要抓住“瞬间到达率”，而不是全天平均值。可以按推送触达用户数乘以预期打开比例再除以高峰窗口时间来计算。

2.3 参数取值的一些经验值

公式里最让人犹豫的就是p和r到底该取多少。参数取错了，整个估算也就失真了。根据我多年项目经验，给一个参考区间：

• 活跃比例p：一般业务系统取10%到20%；对特定活动页可以到30%甚至更高；对后台管理类系统，通常取全部在线人员的80%以上，因为后台用户操作反而更密集。
• 请求频率r：普通浏览类业务，一个人平均每1到3分钟一个操作；强交互类业务，比如在线编辑、交易系统，可能每10到30秒一个操作；纯轮询类按周期直接换算。
• 响应时间t：可以先取目标响应时间，比如要求RT小于1秒，就把t取为1，预留一定余量。如果已经有线上监控数据，最好取P95而不是平均值。

参数设定不可能一步到位。我的习惯是先按经验值估算第一版，然后用压测实测数据反过来校验：看按公式算出来的并发数能不能撑住预期TPS。如果实测和预期差得比较远，说明p或r的取值偏离实际，再去查线上日志做校准。这套“先估算，再校准”的闭环，比任何公式都管用。

2.4 计算示例：以某电商订单系统为例

我把一个完整案例走一遍，这样大家可以直接套用步骤。

假设某电商平台要做大促前的容量评估，已知数据：日活300万、大促当天预计有60%用户会访问、核心下单接口单用户日均调用1.5次、大促主要集中在上午10点到12点的2小时高峰。首先算高峰窗口内的总请求量：300万x60%=180万人会访问，其中假设有40%的人会下单尝试，那就是72万人会触发下单请求，再考虑部分用户会取消重试，乘以1.2的冗余系数，大约是86.4万次下单请求。这2小时内平均每秒请求速率是864000/7200=120次/秒。

如果我期望下单接口的RT不超过1.5秒，根据Little's Law，并发数大约为120x1.5=180。如果目标压测场景只测下单接口，用180线程就够了。但要加上其他接口混合比例，比如查询、加购流量更大，并发数要重新按各环节比例加权计算。

有一个容易被忽视的点：真实压测下，如果服务端开始出现排队，RT可能会从1.5秒涨到5秒，此时即使TPS不变，并发线程里堆积的请求也会暴涨，压测工具的活跃线程数会远高于180这个数。这就是为什么压测时不光要设目标并发，还要关注RT在过载点之后的变化形态。

3. TPS计算：需求推导、日志统计、实测反推

3.1 TPS的定义与统计口径

和并发量不同，TPS更直观，但统计口径容易出问题。一个“事务”在不同系统里定义差别很大：可能是整个下单流程（从提交订单到返回成功），也可能是单次数据库查询。定义不清楚，后面的所有计算都没有意义。

我在做方案时，会先把“事务”的定义在评审会上敲定。一般推荐把“用户可感知的业务操作”作为一个事务，例如“登录事务”“下单事务”“支付事务”。如果是技术层面的一个连接或者一次内部调用，可以用单独的名字如QPS（每秒查询数）去统计，避免和TPS混在一起。

TPS指标还可以拆成很多角度：数据库TPS、中间件TPS、应用服务器TPS，但业务侧最关注的通常是“端到端TPS”，即从负载机发起请求到完整收到响应的每秒事务完成数。在做瓶颈定位时，再逐层拆到组件TPS，这是后话。

3.2 路径一：从业务需求倒推TPS

在没有线上日志的情况下，只能从业务指标倒推。公式很简单：

[ TPS = \frac{总请求量}{时间窗口(秒)} ]

沿用电商大促案例，下单业务高峰2小时请求量是86.4万，平均TPS就是864000/7200=120。但这是“平均”TPS，大促的流量不是均匀的，往往在整点附近出现尖峰，例如10点开始的前10分钟流量可能是平均值的2到3倍。因此不能只用平均值定目标，要按峰值系数放大。若峰值系数为2.5，则设计目标TPS为300。

有人会提出“二八原则”，说80%的请求集中在20%的时间段里。这是一个统计经验，不适用于精确容量规划。我看到不少方案直接套用2/8，最后压测目标定得太高或太低，原因就是没有结合实际业务的流量分布。更可靠的做法是直接看线上监控的分钟级请求量曲线，取高峰期的最高分钟值来算目标TPS。没有监控数据时，再退一步用2/8原则做粗估。

3.3 路径二：从生产日志统计修正

如果你的系统已经上线并有日志系统，那么生产日志是最好的数据源，比任何估算都准。具体做法是：导出高峰时段某一天的Nginx或者应用访问日志，按接口聚合统计每秒请求数，取P95或者最大值作为压测TPS基线。

举个例子，从日志统计出某下单接口在高峰期最大分钟请求量是24000次/分钟，也就是400 TPS，一天的平均TPS是80。压测目标就可以设为400，再乘以1.2到1.3的冗余系数得到500。这里要注意的是生产日志统计出来的是“实际到达量”，如果系统已经出现过限流或拒绝请求，统计结果偏低，直接拿去做目标会导致压测强度不够。所以最好选一个没有明显丢弃请求的正常日作为基准。

另外强烈建议按接口维度拆分统计，而不是只看总TPS。下单接口和查询接口的处理逻辑完全不一样，资源消耗也不同，混合在一起就只能得到一个总盘子，无法指导后续的容量规划。

3.4 路径三：从容量测试反推单机限额

还有一种场景是系统还没上线，或者业务指标本身不可靠，这时候可以用“压测反推”的方式：先测出单机（单个应用实例）能支撑多少TPS，再乘以节点数得到整体容量。比如压测发现单实例在RT达标的情况下最高稳定TPS是800，线上有10个实例，理论上集群容量8000 TPS。但实际应用要打个折扣，因为负载均衡不均、服务依赖瓶颈、单点故障等因素，我一般按0.7到0.8的容量系数来估算，也就是5600到6400 TPS比较稳妥。

这种方式非常适合做容量规划的初步摸底。很多性能测试项目的第一阶段，我都喜欢先做单机基准测试，把每个核心接口的单实例TPS跑出来，再推算集群整体，这样后面的全链路压测有据可依。

3.5 长事务场景的TPS处理

上面讲的都是短事务场景，但在实际业务中，总会混入一些长事务。典型的是报表导出、批量接口、文件生成，这类事务单次耗时可能达到10秒甚至几十秒。如果用统一的TPS和并发数去设计，会非常别扭。

我遇到过这样一个案例：一个管理系统有日常查询接口，RT大约0.3秒，也有一个数据导出接口，RT大约40秒。如果把两个接口放在同一个线程组里，线程被长事务长时间占住，日常接口的TPS就会被拖累，压测结果失真。最终做法是拆成两个线程组，分别按各自的目标并发和TPS来压测，或者单独写一个独立场景。长事务的TPS目标不一定要很高，它的核心指标是“并发完成率”和“时长内最大处理笔数”，比如要求1小时内完成10万笔导出，平均TPS只需要28，但并发线程数因为RT太长，可能要被设为几百才跑得起来。

这种情况下，并发数和TPS的差异就体现得非常明显。你算出来的TPS可能只有30，但只要平均RT是40秒，Little's Law告诉你并发数要求高达1200。这也是为什么我会建议：场景设计时，先按目标TPS估算线程数，实际压测再通过逐步加压来校准，不要只看单一指标。

4. 实操中的压测设计经验与排查指南

4.1 到底先定并发数还是先定TPS

这是很多团队在压测方案评审时经常争论的问题。我的建议是：目标先定TPS，线程数作为手段去调整。因为TPS是业务可以直接感知的指标（每秒能处理多少订单、多少人支付），而并发数是实现这个目标的一种手段，不具备业务可比性。

举个例子，某支付渠道要求峰值支持2000 TPS，平均响应时间小于1秒。压测时，先用少量线程跑起来，然后逐步增加线程，观察TPS是否线性增长，RT是否还在目标范围内。如果线程加到400，TPS达到2000但RT已经上涨到1.8秒，那这个并发数是不合格的；如果线程加到800，TPS稳定在2000，RT还在0.8秒左右，那说明系统的处理能力在并发800这一档能达到指标。此时的“并发数”更多是压测结果，而不是预先设定的输入。真正业务上关注的是：能不能稳定支撑2000 TPS，以及这个能力能持续多久。

4.2 压力递增策略

我见过不少压测方案直接设置3000线程持续压30分钟，结果一上来系统就狂报错，日志刷屏，最后连瓶颈在哪都没看清。正确的做法是阶梯式加压：例如每30秒增加10%的线程数，同时记录每个梯度的TPS、平均RT、错误率。这样你能清楚看到系统在哪个并发点开始“拐弯”——TPS不再增长、RT突然上扬、错误率开始抬头，这个点就是系统的性能拐点。

从拐点往后，再增加并发已经没有意义，系统的处理能力已经耗尽。真正有价值的性能测试不只是“扛住目标压力”，更重要的是找到这个拐点，并分析拐点背后的原因：是数据库连接池满了，还是应用线程池耗尽，又或者是下游第三方接口成为瓶颈。出了问题之后，还要了解问题影响的范围，方便确定优先修复的方向。

这里有一个我常用的压测脚本设计原则：并发线程数从一个低值起步，比如10到20个，然后按固定梯度增加，不要一上去就压满。尤其是第一次压测的任务，更多是为了摸清底数，而不是为了证明系统能扛多少。

4.3 常见问题与排查速查表

下面的表格整理了我实际排查中遇到的高频问题，压测出现问题不要慌，先按表里思路过一遍：

除了这些方向，还有几个容易踩的坑。一是压测机的性能受限，尤其是用笔记本跑高并发，线程数一高CPU先满了，压测结果失真，这种情况下建议分布到多台压测机去跑。第二是没用独立的网络带宽，压测流量和办公流量混在一起，网络延迟忽高忽低，数据根本没法看。第三是忽略“思考时间”，真实的用户操作之间有停顿，如果压测脚本完全不设思考时间，压力会比实际大好几倍，做出来的报告往往偏保守。大部分压测工具都支持调度器延迟或者固定定时器，要根据业务操作习惯合理设置。

4.4 关于全链路压测与实际容量评估

如果条件允许，我会建议做一次“全链路压测”，即模拟真实用户访问完整业务链路的压测。传统的接口级压测侧重于单点容量，但实际生产环境里的瓶颈往往在多个服务之间的依赖关系上。比如下单接口本身没问题，但支付回调服务或消息队列消费能力跟不上，最终业务照样受损。全链路压测能暴露这一类服务间协作的瓶颈。

全链路压测的实施门槛比接口级压测高很多。它需要独立的压测环境或完整的流量标记方案，流程上要改造中间件，确保压测数据不会污染生产数据。对于没有改造条件的团队，退一步做“核心链路压测”也可以：把下单链路涉及的核心服务串起来，用Mock替代非关键依赖，重点验证依赖顺序和超时表现。这类压测能帮团队提前发现架构上的单点，比单纯测接口容量更有价值。

4.5 报告撰写与分析要点

压测做完之后，数据整理和报告其实也很考验水平。一份好的报告，不应该是把图表粘贴进去就结束。我一般会包含几个核心部分：测试环境拓扑、压测模型与指标口径、目标指标与实际结果对比、性能拐点截图、瓶颈分析与调优建议、后续复测计划。最关键的是“结论对业务可读”，运维、开发负责人、业务方都能从自己的角度获得信息，而不只是一堆技术参数。

在报告里还要明确“影响范围”。这个点经常被忽略，但其实很重要：在测试中发现的性能缺陷，要说明影响范围，比如影响特定地区用户、特定接口、特定时间段的业务，还是全链路问题。只有充分说明影响范围，业务领导才能判断需要多高的处理优先级，这也是性能测试结果能真正推动业务决策的关键。有条件的话，我还会附带容量预估结论：当前架构能支撑多少日常用户，增长多少以后需要扩容，让报告从“测试结果汇报”变成“容量规划输入”。

5. 最后分享一点这十几年攒下来的体会

5.1 公式是起点，不是终点

从入行到现在，我很长一段时间都在追求“更精确的并发量公式”，后来发现方向有点偏。再精确的公式也只是建立在业务假设的基础上，假设错了，公式再严谨也没意义。真正靠得住的，是估算加实测的循环：用公式拿到初始值，用压测校准假设，再用校准后的数据指导下一次估算。这个循环跑得越多次，估算的准确度就越高，团队的经验也会沉淀下来。

5.2 数据造假是压测的大忌

这个问题我必须拿出来说，因为它直接毁掉性能测试的价值。有些团队为了汇报好看，压测时报喜不报忧，或者把目标定得很低，测试结果“轻松通过”。这样的压测不仅浪费人力，更可怕的是给业务带来虚假的安全感，上线后真正遇到故障时反而没有准备。我个人的原则是：压测数据要经得起复看，怎么测的、什么环境、用什么参数，每一步都可以追溯。数据是脏的，比没有数据更糟。

5.3 性能测试的最终价值是容量规划

做了十几年性能测试，我自己的体会是，高性能测试做得好不好，不看你能跑多高的TPS，而是看你能不能回答“系统还能撑多久、什么时候需要扩容、哪些业务增长会先压垮系统”这些问题。并发量和TPS的计算只是工具，透过数据看懂系统的容量边界，帮助业务提前做规划，才是这项工作的价值所在。希望这篇文章的公式、案例和踩坑经验，能让大家在实际项目中少走一些弯路。