企业官网建设流程全解析

1. 先搞清楚“在线测压网站”到底在测什么

“在线测压网站”这六个字，我第一次看到的时候也愣了一下——是测血压的？还是给网站做体检的？放到开发和运维的语境里，答案很明确：它指的是通过浏览器界面就能发起并发压力测试的平台或工具，被测对象是网站、Web服务、API接口这类跑在网络上的系统。说白了，就是把过去要装一堆客户端、写一堆脚本、开几台机器才能干的压测活儿，搬到一个网页里点点按钮就能跑起来。

我最早接触压测是十年前，那时候为了测一个活动页能扛多少并发，得在本地装JMeter、配线程组、导CSV参数、再找几台闲置机器当压测机，折腾大半天。现在的情况不一样了，很多团队希望打开一个网页、填个URL、设个并发数、点开始，就能看到实时曲线。这种需求催生了一大批“在线测压”形态的产品：有的是纯SaaS服务，有的是开源工具自带的Web控制台，有的是自建平台对外提供Web入口。

它能解决的问题其实就三类。第一类是容量评估：上线前想知道系统能扛多少用户，活动峰值会不会挂。第二类是瓶颈定位：系统变慢了，到底是数据库、缓存、还是某个接口拖后腿。第三类是回归验证：改了一版代码，性能有没有退化，拿数据说话。

适合看这篇内容的人，我大致分成三种。第一种是刚接手性能测试任务的开发或测试同学，之前没系统做过压测，需要一个能落地的入门路径。第二种是中小团队的技术负责人，预算有限，想在自建工具和在线服务之间做取舍。第三种是已经用过在线压测平台、但只会点按钮、看不懂报告、出了问题不知道怎么排查的人。这三类人关心的点不一样，但底层逻辑是同一套：你得先知道自己在测什么，再谈怎么测。

这里必须先划一条红线，也是我这些年反复跟团队强调的：压测只能针对你自己拥有、或者已经拿到书面授权的系统。随便拿一个在线工具去压别人的网站，轻则被封IP，重则涉及法律问题。在线测压网站降低了操作门槛，但没有降低责任门槛，这一点心里要非常清楚。

1.1 压力测试、负载测试、并发测试，别再混着叫

很多人把这几个词当同义词用，实际含义差别不小，搞混了会导致测试目标跑偏。

负载测试关注的是“在预期负载下系统表现如何”。比如你预估活动峰值是每秒500个请求，那就按这个量级去跑，看响应时间、错误率是否在可接受范围。它的核心是验证“正常范围内不出问题”。

压力测试是往死里压，一直加量，直到系统崩溃，目的是找到极限点和崩溃后的表现。比如从每秒100请求一路加到5000，看它在哪个点开始报错、是优雅降级还是直接雪崩。

并发测试更聚焦于“同一时刻有多少请求同时打进来”，常用于验证锁、连接池、线程池这类共享资源在高并发下会不会出问题。比如秒杀场景，1000个人同时点下单，库存扣减会不会超卖，这属于并发测试的范畴。

稳定性测试则是长时间跑，比如连续压8小时、24小时，看内存有没有泄漏、连接有没有堆积、日志会不会把磁盘写满。这个最容易被忽略，但线上事故里占比很高。

在线测压网站通常把这几种模式做成预设模板，比如“阶梯加压”“持续负载”“峰值冲击”。你点之前要想清楚自己要的是哪一种，否则跑出来的数据没法解释。我见过有人想做稳定性测试，结果选了个持续5分钟的模板，跑了三轮就下结论说系统很稳，这就属于目标和方法不匹配。

1.2 为什么越来越多团队选择“在线”这种形态

自建压测能力不是不行，而是成本结构变了。以前一台压测机就能产生足够压力，现在很多系统的入口带宽、连接数、TLS握手开销都上来了，单机往往压不出真实瓶颈，需要多台机器分布式发压。分布式压测的编排、时钟同步、结果聚合，本身就是一套不小的工程。

在线测压网站把这部分复杂度接过去了。你通过浏览器配置，后台自动调度多台发压节点，结果统一汇总展示。对没有专职性能测试团队的公司来说，这省下来的不只是机器钱，更是人力。

另一个现实原因是协作。压测报告如果只存在某个人本地，过两周就找不到了。在线平台天然带历史记录、对比曲线、分享链接，产品、运维、开发能看同一份数据，沟通成本低很多。

但“在线”也有代价。你的测试目标地址、请求参数、甚至部分响应内容，会经过第三方平台。如果是内部系统或者涉及敏感数据的接口，这一点必须提前评估。我的建议是：对外部可访问的、非敏感的接口，用在线平台提效；涉及内部系统或敏感数据的，老老实实自建。这条线不能糊。

2. 技术选型：在线SaaS、自建Web控制台、还是本地工具加脚本

选型这件事，我一般让团队先回答三个问题：被测系统在哪、团队有没有压测经验、压测频率有多高。这三个答案基本能锁定方向。

2.1 三类方案的适用边界

纯SaaS在线测压平台，优点是开箱即用，全球节点、分布式发压、报告美观，适合快速验证和对外接口的基准测试。缺点是数据出境、按量计费、复杂场景（比如需要登录态串联、需要读数据库校验）支持有限。

开源自建加Web控制台，典型代表是JMeter配Web界面、Locust自带Web UI、k6加自定义看板。优点是数据不出内网、脚本灵活、免费。缺点是要自己维护发压机和调度逻辑，分布式压测要额外投入。

本地工具加命令行脚本，比如ab、wrk、hey这类，适合开发本地快速自测，几秒钟就能跑一轮。缺点是不适合长时间、大并发、多接口串联的场景，报告也比较简陋。

我通常的建议是：日常开发自测用命令行工具，版本发布前的基准压测用自建Web控制台，对外接口的横向对比用在线SaaS。三者不是替代关系，是分工关系。

2.2 主流压测工具参数对比

下面这张表是我自己整理过很多次的，选型时直接对照看。

k6这两年在团队里普及得很快，一个原因是它把脚本、阈值断言、CI集成做得很顺。你可以在脚本里直接写“P95响应时间超过500毫秒就算失败”，跑完自动退出码非零，直接卡住流水线。这个特性对做持续性能测试的团队非常友好。

Locust的优势在于Python生态，需要复杂逻辑、需要调外部库、需要读测试数据的时候，写起来比JMeter的XML舒服太多。它的Web UI也是我见过最直观的之一，实时RPS、响应时间、失败数一目了然。

JMeter依然是很多传统企业的默认选择，插件生态成熟，能测的协议最全。但它的GUI在高并发配置下会卡，通常建议用命令行模式跑，GUI只用来编辑脚本。

注意：不管你选哪个工具，发压端自身的资源必须监控。我见过太多次“压测结果上不去”，最后发现是发压机的CPU先跑满了，被测系统根本还没到瓶颈。发压机的CPU使用率建议控制在70%以下。

2.3 我的选型决策顺序

实际做决定时，我按这个顺序问自己：

1. 目标接口需不需要登录态、需不需要多接口串联？需要就别用ab/wrk，直接上k6或Locust。
2. 压测要不要进CI流水线？要就选k6，命令行友好，阈值断言原生支持。
3. 数据能不能出内网？不能就自建，别碰SaaS。
4. 团队有没有人会写代码？都不会就JMeter，会一点Python就Locust，会JS就k6。

这个顺序走下来，基本不会选错。

3. 看懂压测报告：TPS、响应时间分位数、错误率到底怎么读

工具选对了，脚本跑起来了，真正的难点才刚开始——报告怎么看。我见过太多人盯着一个平均值下结论，这是压测里最常见的坑。

3.1 TPS、QPS、RPS，先分清再谈指标

这三个词经常被混用，严格说：

• QPS（Queries Per Second）：每秒查询数，偏向数据库或查询类接口。
• TPS（Transactions Per Second）：每秒事务数，一个事务可能包含多个请求，比如“下单”这个事务里包含查库存、扣库存、生成订单三个请求。
• RPS（Requests Per Second）：每秒请求数，最贴近HTTP接口的计量方式。

做Web接口压测时，如果每个“事务”就是一个请求，那三者数值接近，混用问题不大。但如果有接口串联，就必须说清楚统计口径。报告里写“TPS 800”，到底是800个完整业务事务，还是800个HTTP请求，含义差好几倍。

我自己的习惯是：对外汇报统一用RPS，因为最好解释；内部看业务流程用TPS，因为更贴近用户体验。报告里一定标注口径，避免扯皮。

3.2 平均值是骗人的，P95和P99才是真相

响应时间的平均值有个致命问题：它会被大量快请求拉低，掩盖长尾。举个例子，100个请求里99个是50毫秒，1个是5秒，平均值大概是99毫秒，看起来还行。但那1个5秒的请求，对应的就是真实用户里“页面卡死了”的那批人。

所以看响应时间必须看分位数：

• P50（中位数）：一半请求快于这个值，代表典型用户体验。
• P90：90%的请求快于这个值，开始触及慢请求。
• P95：95%的请求快于这个值，业界常用的SLA基准线。
• P99：99%的请求快于这个值，长尾的极端情况。

一个健康的系统，P50和P95的差距不应该太大。如果P50是50毫秒、P95是2秒，说明系统里存在明显的慢路径，可能是缓存偶尔击穿、可能是锁竞争、可能是某个下游接口抖动。

设置阈值时，我个人常用的基准是：核心接口P95控制在500毫秒以内，P99控制在1秒以内。这不是通用标准，要根据业务调整。金融交易类要求更严，内容展示类可以放宽。关键是这个阈值要写进脚本里自动判定，而不是靠人肉看曲线。

3.3 错误率和并发用户数的关系曲线

错误率单独看没意义，必须和并发数一起看。典型曲线是这样的：并发从0加到某个点，错误率一直是0，响应时间缓慢上升；过了某个拐点，响应时间开始陡增，错误率随之冒头；再往上加，错误率直接飙升。

这个拐点就是系统的最佳吞吐点，也是压测真正要找到的东西。很多在线测压网站提供“阶梯加压”模式，自动画这条曲线，你要做的就是找到那个转折位置，然后对比它和你预期的业务峰值之间还有多少余量。

余量怎么定？我的经验是至少留2倍。也就是说，如果压测显示系统在每秒1000请求时开始劣化，那业务峰值最好不超过每秒500请求。线上流量有突发性，压测环境又和生产环境有差异，留够缓冲才不会翻车。

注意：错误率里要区分“业务错误”和“系统错误”。返回200但业务码表示“库存不足”，这不算系统故障；返回502、超时、连接拒绝，这才是真错误。混在一起统计会得出错误结论。

4. 从零搭一套可复用的在线压测流程

讲完理论，进入能直接抄的部分。这一节我用k6和Locust两套方案，从环境准备到脚本落地讲完整。

4.1 环境准备与压测目标确认

第一步不是装工具，是确认压测目标。我要求团队填一张表，把下面这些问题回答清楚：

这张表看着简单，但能挡掉一大堆扯皮。特别是“授权确认”这一栏，必须有记录。没有授权的压测，一律不跑。

环境准备上，k6最简单，单个二进制文件，Linux、macOS、Windows都能装：

# macOS brew install k6 # Linux（Debian系） sudo apt-get install k6 # 验证 k6 version

Locust需要Python环境：

pip install locust locust --version

4.2 用k6写第一个压测脚本

k6脚本就是一个JS文件，结构非常清晰。下面是一个可直接跑的模板：

import http from 'k6/http'; import { check, sleep } from 'k6'; import { Rate } from 'k6/metrics'; // 自定义错误率指标 const errorRate = new Rate('business_errors'); export const options = { // 阶梯加压：30秒爬到50并发，再1分钟爬到200并发，最后30秒降下来 stages: [ { duration: '30s', target: 50 }, { duration: '1m', target: 200 }, { duration: '30s', target: 0 }, ], // 阈值断言：不满足就判定失败 thresholds: { http_req_duration: ['p(95)<500', 'p(99)<1000'], http_req_failed: ['rate<0.01'], business_errors: ['rate<0.01'], }, }; export default function () { const res = http.get('https://your-staging.example.com/api/items?page=1', { headers: { 'Accept': 'application/json', 'X-Test-Source': 'k6-load-test', }, timeout: '10s', }); const ok = check(res, { 'status is 200': (r) => r.status === 200, 'body is not empty': (r) => r.body && r.body.length > 0, 'response is json': (r) => (r.headers['Content-Type'] || '').includes('application/json'), }); errorRate.add(!ok); // 模拟用户思考时间，1到3秒随机 sleep(Math.random() * 2 + 1); }

跑起来：

k6 run script.js

几个关键点解释一下。stages定义的是并发用户数随时间的变化，不是RPS。k6会根据你脚本里的sleep和响应耗时，自动换算出实际RPS。thresholds里的断言是k6最有价值的部分，跑完如果P95超过500毫秒，进程退出码非零，CI流水线直接失败，非常适合做性能门禁。

X-Test-Source这个请求头是我习惯加的，方便后端日志里过滤出压测流量，避免污染真实监控数据。这个习惯强烈建议你养成。

4.3 用Locust做需要业务逻辑的压测

如果压测需要登录、需要串联多个接口，Locust的Python脚本会更顺手：

from locust import HttpUser, task, between import random class ApiUser(HttpUser): wait_time = between(1, 3) host = "https://your-staging.example.com" def on_start(self): # 每个虚拟用户启动时登录一次，拿到token res = self.client.post("/api/login", json={ "username": "test_user", "password": "test_password", }) if res.status_code == 200: self.token = res.json().get("token") else: self.token = None @task(3) def list_items(self): if not self.token: return self.client.get( "/api/items?page=1", headers={"Authorization": f"Bearer {self.token}"}, name="/api/items", ) @task(1) def view_detail(self): if not self.token: return item_id = random.randint(1, 100) self.client.get( f"/api/items/{item_id}", headers={"Authorization": f"Bearer {self.token}"}, name="/api/items/[id]", )

@task(3)和@task(1)表示权重，前者执行频率是后者的3倍，用来模拟真实的流量比例。name参数很重要，它把动态URL归并成同一个统计项，否则每个item_id都会生成一条独立记录，报告会被撑爆。

启动带Web界面的模式：

locust -f locustfile.py --web-host 0.0.0.0 --web-port 8089

浏览器打开对应端口，就能看到实时曲线，手动调整并发数和加压速率。无界面模式适合CI：

locust -f locustfile.py --headless -u 500 -r 50 --run-time 10m

-u 500是500个虚拟用户，-r 50是每秒启动50个，--run-time 10m是跑10分钟。

4.4 压测数据的隔离与清理

这一条最容易被忽略，但后果最严重：压测产生的脏数据必须能识别、能清理。

我见过一个团队压测下单接口，往生产库写了三万多条假订单，最后靠人工一条条删。正确的做法是：

• 压测账号用专门前缀，比如用户名统一带loadtest_。
• 压测请求带专门header，后端可以据此标记数据。
• 压测结束跑清理脚本，按标记批量删除。
• 绝不在生产环境跑写操作压测，除非有完整的回滚方案并经过审批。

读接口的压测相对安全，写接口的压测一定要慎之又慎。如果业务不允许产生脏数据，就在测试环境用影子表或者mock下游。

5. 一次完整的接口压测实操记录

光讲方法还是虚，我把最近一次压测的完整过程还原一遍，包括参数怎么算、瓶颈怎么定位。

5.1 压测前的基线确认

这次的目标是一个商品列表接口，业务方预估大促峰值500 RPS，要求P95低于300毫秒。

先做单请求基线：本地用curl连发10次，看响应时间。

for i in $(seq 1 10); do curl -o /dev/null -s -w "%{time_total}\n" \ "https://staging.example.com/api/items?page=1" done

结果平均在40毫秒左右，说明单请求本身很快。但单请求快不代表并发下快，因为并发会触发连接池、缓存、数据库锁这些共享资源的竞争。

接着确认环境：2台应用服务器，各4核8G；数据库4核16G；缓存2G。生产是4台8核16G，数据库8核32G。也就是说，测试环境大约只有生产的一半容量。这个差异必须记录在报告里，否则结论会失真。

5.2 阶梯加压与瓶颈定位

用k6跑阶梯，从50并发爬升到400并发。同时开三个监控窗口：应用服务器CPU、数据库连接数、缓存命中率。

跑到200并发时，RPS稳定在约600，P95是180毫秒，一切正常。跑到300并发时，RPS开始上不去，卡在650左右，P95跳到450毫秒。继续加到400并发，RPS反而掉到580，P95超过1秒，错误率升到3%。

初步判断瓶颈出现在300并发附近。接下来要定位到底卡在哪一环。排查顺序是：

1. 应用层：看应用日志有没有大量超时、GC日志有没有频繁Full GC。
2. 数据库：看慢查询日志、连接数是否打满、活跃连接是否堆积。
3. 缓存：看命中率是否下降、有没有大量穿透。
4. 下游依赖：看第三方接口调用耗时是否增加。

这次发现数据库连接池最大只有50，300并发下连接全部占满，请求在排队等连接。把连接池调到100后重测，300并发下P95降到210毫秒，RPS提升到约850。

继续加压到500并发，P95又上去了，这次是应用服务器CPU打满。因为测试环境只有2台机器，这就是环境容量上限，不是代码问题。记录结论：在现有测试环境配置下，接口可稳定支撑约400并发、约800 RPS。

5.3 参数换算：并发数、RPS和响应时间的关系

这里有一个非常实用的公式，叫利特尔法则：

并发数 = RPS × 平均响应时间（秒）

反过来推：如果你知道目标RPS和预期响应时间，就能算出需要多少并发来压。

比如目标1000 RPS，预期平均响应时间200毫秒：

并发数 = 1000 × 0.2 = 200

也就是说，200个并发用户，在平均响应200毫秒的情况下，能产生1000 RPS。这个数字对配置压测脚本非常关键。很多人设并发数是拍脑袋，设小了压不出目标量，设大了直接把系统压垮。

再看一个反向推导：如果测试发现平均响应时间涨到了500毫秒，并发还是200，那RPS只有：

RPS = 200 / 0.5 = 400

响应时间翻倍，吞吐直接腰斩。这就是为什么性能劣化会呈现“非线性崩塌”——响应慢导致并发被占住，吞吐进一步下降，形成恶性循环。

这个公式我在每次压测前都会算一遍，用来确认脚本里的并发数设置是否合理。你也可以用它来判断报告里数据是否自洽：如果报告显示200并发、平均响应200毫秒、RPS却只有200，那数据肯定有问题。

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

这一节是踩坑总结，都是在真实项目里遇到的。

6.1 压测结果每次都不一样怎么办

同一套脚本跑三次，RPS能差30%，这种情况先别怀疑系统，先排查这几个点：

发压端是否稳定。发压机的CPU、内存、网络带宽是否成为瓶颈。我遇到过一次，发压机跑在共享的CI机器上，旁边有别的任务抢CPU，结果压测数据完全没有参考价值。

测试数据是否固定。如果每次随机查不同的数据，命中缓存的比例不同，结果自然波动。固定测试数据集，能显著提升可复现性。

下游是否也在波动。如果接口依赖第三方服务，第三方本身的抖动会传导进来。压测时尽量mock掉不稳定的下游。

是否有定时任务干扰。数据库备份、日志切割、定时同步这些任务如果刚好在压测期间跑，会严重污染数据。压测前确认好时间窗口。

6.2 怎么判断瓶颈在发压端还是在被测端

这是最经典的问题。判断方法很简单：看两端资源。

在被测服务器上监控CPU、内存、连接数、磁盘IO；在发压机上监控同样的指标。

• 发压机CPU接近100%，被测机CPU很低 → 瓶颈在发压端，加机器或换工具。
• 两端CPU都不高，但RPS上不去 → 可能在网络带宽、连接数限制，或被测系统内部有锁等待。
• 被测机CPU打满，发压机很闲 → 瓶颈在被测端，继续细分是哪个进程、哪个线程。

还有一个技巧是在发压端看TIME_WAIT连接数。如果大量连接处于TIME_WAIT，可能是端口耗尽，需要调整内核参数或者开启长连接复用。

6.3 常见问题速查表

6.4 几个我踩过的坑

第一个坑：忘了关调试日志。测试环境日志级别是DEBUG，压测时磁盘IO直接打满，性能数据全废。压测前把日志级别调到WARN或ERROR。

第二个坑：用了带随机参数的脚本。每次请求参数都不同，缓存完全命中不了，测出来的是最悲观的情况。要么固定参数，要么在报告里说明这是无缓存场景。

第三个坑：压测完直接下线环境。没等连接自然释放，直接把服务停了，导致下一次启动时一堆异常。压测结束后等一两分钟，让连接超时自然回收，再操作环境。

第四个坑：只压单接口。单接口漂亮不代表整条链路没问题。用户真实路径是多个接口串联，串联后的耗时和失败率会放大。有条件的话做链路级压测。

7. 实操心得与我一直坚持的几条原则

做压测这些年，方法学了很多，工具换了好几轮，但有几条原则一直没变。

7.1 压测环境要尽可能贴近生产

测试环境和生产环境差多少，结论的置信度就低多少。理想情况下，压测环境应该是生产环境的等比缩小版，配置比例一致。如果做不到，至少在报告里明确标注差异，并给出保守的换算系数。

我通常会在报告开头写一句：“本次压测环境约为生产容量的50%，结论中的容量数字需按比例折算，并额外保留2倍安全余量。”这句话能省掉后面无数次解释。

7.2 每次压测只改一个变量

这是科学实验的基本要求，但实际项目里经常被违反。有人一次改了代码、调了配置、换了数据库，然后跑压测说性能提升了，根本说不清是哪个改动起的作用。

正确的做法是：基线跑一次，改一个点再跑一次，对比差异。这样得到的数据才能指导决策。

7.3 报告要写“所以呢”，不是只贴数字

我见过太多压测报告，一堆曲线和表格，最后没有结论。看的人只想知道三件事：能扛多少、瓶颈在哪、要不要优化。

报告结构我一般这么写：一句话结论 → 关键指标表 → 瓶颈分析 → 优化建议 → 附录原始数据。让决策者三十秒能看完结论，需要细节的人再往下翻。

最后分享一个小技巧。压测脚本写完后，先用极低并发（比如1个用户）跑一遍，确认所有请求都是成功的、参数都是对的。这一步花不了一分钟，但能避免拿一个本身就有问题的脚本跑了几十分钟，最后发现全是错误请求。这个习惯，我强烈建议你从第一次压测就开始养。