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 主流压测工具参数对比下面这张表是我自己整理过很多次的选型时直接对照看。工具脚本语言分布式支持资源占用上手难度适合场景ab无纯命令不支持极低极低单接口快速摸底wrkLua不支持低中高并发HTTP基准JMeterGUIXML支持高中复杂业务流程、老牌团队LocustPython支持中中需要写逻辑的接口串联k6JavaScript支持云或自建低中低脚本化、CI集成k6这两年在团队里普及得很快一个原因是它把脚本、阈值断言、CI集成做得很顺。你可以在脚本里直接写“P95响应时间超过500毫秒就算失败”跑完自动退出码非零直接卡住流水线。这个特性对做持续性能测试的团队非常友好。Locust的优势在于Python生态需要复杂逻辑、需要调外部库、需要读测试数据的时候写起来比JMeter的XML舒服太多。它的Web UI也是我见过最直观的之一实时RPS、响应时间、失败数一目了然。JMeter依然是很多传统企业的默认选择插件生态成熟能测的协议最全。但它的GUI在高并发配置下会卡通常建议用命令行模式跑GUI只用来编辑脚本。注意不管你选哪个工具发压端自身的资源必须监控。我见过太多次“压测结果上不去”最后发现是发压机的CPU先跑满了被测系统根本还没到瓶颈。发压机的CPU使用率建议控制在70%以下。2.3 我的选型决策顺序实际做决定时我按这个顺序问自己目标接口需不需要登录态、需不需要多接口串联需要就别用ab/wrk直接上k6或Locust。压测要不要进CI流水线要就选k6命令行友好阈值断言原生支持。数据能不能出内网不能就自建别碰SaaS。团队有没有人会写代码都不会就JMeter会一点Python就Locust会JS就k6。这个顺序走下来基本不会选错。3. 看懂压测报告TPS、响应时间分位数、错误率到底怎么读工具选对了脚本跑起来了真正的难点才刚开始——报告怎么看。我见过太多人盯着一个平均值下结论这是压测里最常见的坑。3.1 TPS、QPS、RPS先分清再谈指标这三个词经常被混用严格说QPSQueries Per Second每秒查询数偏向数据库或查询类接口。TPSTransactions Per Second每秒事务数一个事务可能包含多个请求比如“下单”这个事务里包含查库存、扣库存、生成订单三个请求。RPSRequests Per Second每秒请求数最贴近HTTP接口的计量方式。做Web接口压测时如果每个“事务”就是一个请求那三者数值接近混用问题不大。但如果有接口串联就必须说清楚统计口径。报告里写“TPS 800”到底是800个完整业务事务还是800个HTTP请求含义差好几倍。我自己的习惯是对外汇报统一用RPS因为最好解释内部看业务流程用TPS因为更贴近用户体验。报告里一定标注口径避免扯皮。3.2 平均值是骗人的P95和P99才是真相响应时间的平均值有个致命问题它会被大量快请求拉低掩盖长尾。举个例子100个请求里99个是50毫秒1个是5秒平均值大概是99毫秒看起来还行。但那1个5秒的请求对应的就是真实用户里“页面卡死了”的那批人。所以看响应时间必须看分位数P50中位数一半请求快于这个值代表典型用户体验。P9090%的请求快于这个值开始触及慢请求。P9595%的请求快于这个值业界常用的SLA基准线。P9999%的请求快于这个值长尾的极端情况。一个健康的系统P50和P95的差距不应该太大。如果P50是50毫秒、P95是2秒说明系统里存在明显的慢路径可能是缓存偶尔击穿、可能是锁竞争、可能是某个下游接口抖动。设置阈值时我个人常用的基准是核心接口P95控制在500毫秒以内P99控制在1秒以内。这不是通用标准要根据业务调整。金融交易类要求更严内容展示类可以放宽。关键是这个阈值要写进脚本里自动判定而不是靠人肉看曲线。3.3 错误率和并发用户数的关系曲线错误率单独看没意义必须和并发数一起看。典型曲线是这样的并发从0加到某个点错误率一直是0响应时间缓慢上升过了某个拐点响应时间开始陡增错误率随之冒头再往上加错误率直接飙升。这个拐点就是系统的最佳吞吐点也是压测真正要找到的东西。很多在线测压网站提供“阶梯加压”模式自动画这条曲线你要做的就是找到那个转折位置然后对比它和你预期的业务峰值之间还有多少余量。余量怎么定我的经验是至少留2倍。也就是说如果压测显示系统在每秒1000请求时开始劣化那业务峰值最好不超过每秒500请求。线上流量有突发性压测环境又和生产环境有差异留够缓冲才不会翻车。注意错误率里要区分“业务错误”和“系统错误”。返回200但业务码表示“库存不足”这不算系统故障返回502、超时、连接拒绝这才是真错误。混在一起统计会得出错误结论。4. 从零搭一套可复用的在线压测流程讲完理论进入能直接抄的部分。这一节我用k6和Locust两套方案从环境准备到脚本落地讲完整。4.1 环境准备与压测目标确认第一步不是装工具是确认压测目标。我要求团队填一张表把下面这些问题回答清楚项目说明示例被测地址完整URL区分环境staging内网地址授权确认谁授权的有无书面记录项目负责人邮件确认业务峰值预估预计最大并发/每秒请求500 RPS核心接口要重点保障的接口下单、查询列表成功标准P95阈值、错误率阈值P95500ms错误率1%测试环境差异与生产的配置差异数据库规格低一档这张表看着简单但能挡掉一大堆扯皮。特别是“授权确认”这一栏必须有记录。没有授权的压测一律不跑。环境准备上k6最简单单个二进制文件Linux、macOS、Windows都能装# macOS brew install k6 # LinuxDebian系 sudo apt-get install k6 # 验证 k6 versionLocust需要Python环境pip install locust locust --version4.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: [rate0.01], business_errors: [rate0.01], }, }; export default function () { const res http.get(https://your-staging.example.com/api/items?page1, { 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?page1, headers{Authorization: fBearer {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: fBearer {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浏览器打开对应端口就能看到实时曲线手动调整并发数和加压速率。无界面模式适合CIlocust -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?page1 done结果平均在40毫秒左右说明单请求本身很快。但单请求快不代表并发下快因为并发会触发连接池、缓存、数据库锁这些共享资源的竞争。接着确认环境2台应用服务器各4核8G数据库4核16G缓存2G。生产是4台8核16G数据库8核32G。也就是说测试环境大约只有生产的一半容量。这个差异必须记录在报告里否则结论会失真。5.2 阶梯加压与瓶颈定位用k6跑阶梯从50并发爬升到400并发。同时开三个监控窗口应用服务器CPU、数据库连接数、缓存命中率。跑到200并发时RPS稳定在约600P95是180毫秒一切正常。跑到300并发时RPS开始上不去卡在650左右P95跳到450毫秒。继续加到400并发RPS反而掉到580P95超过1秒错误率升到3%。初步判断瓶颈出现在300并发附近。接下来要定位到底卡在哪一环。排查顺序是应用层看应用日志有没有大量超时、GC日志有没有频繁Full GC。数据库看慢查询日志、连接数是否打满、活跃连接是否堆积。缓存看命中率是否下降、有没有大量穿透。下游依赖看第三方接口调用耗时是否增加。这次发现数据库连接池最大只有50300并发下连接全部占满请求在排队等连接。把连接池调到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 常见问题速查表现象可能原因排查方向处理办法RPS上不去两端CPU都低网络或连接数限制查带宽、TIME_WAIT开长连接、调内核参数响应时间阶梯式上涨连接池或线程池打满查池配置和使用率合理扩容、优化等待逻辑错误率突然飙升触发限流或熔断查网关、应用日志确认是否预期行为调整阈值P99远高于P95存在慢路径或锁竞争看慢查询、GC日志优化慢查询减少锁持有时间长时间压测内存持续上涨内存泄漏看堆内存曲线dump内存分析定位对象压测后系统恢复慢连接未释放、缓存堆积看连接数和缓存检查连接归还逻辑6.4 几个我踩过的坑第一个坑忘了关调试日志。测试环境日志级别是DEBUG压测时磁盘IO直接打满性能数据全废。压测前把日志级别调到WARN或ERROR。第二个坑用了带随机参数的脚本。每次请求参数都不同缓存完全命中不了测出来的是最悲观的情况。要么固定参数要么在报告里说明这是无缓存场景。第三个坑压测完直接下线环境。没等连接自然释放直接把服务停了导致下一次启动时一堆异常。压测结束后等一两分钟让连接超时自然回收再操作环境。第四个坑只压单接口。单接口漂亮不代表整条链路没问题。用户真实路径是多个接口串联串联后的耗时和失败率会放大。有条件的话做链路级压测。7. 实操心得与我一直坚持的几条原则做压测这些年方法学了很多工具换了好几轮但有几条原则一直没变。7.1 压测环境要尽可能贴近生产测试环境和生产环境差多少结论的置信度就低多少。理想情况下压测环境应该是生产环境的等比缩小版配置比例一致。如果做不到至少在报告里明确标注差异并给出保守的换算系数。我通常会在报告开头写一句“本次压测环境约为生产容量的50%结论中的容量数字需按比例折算并额外保留2倍安全余量。”这句话能省掉后面无数次解释。7.2 每次压测只改一个变量这是科学实验的基本要求但实际项目里经常被违反。有人一次改了代码、调了配置、换了数据库然后跑压测说性能提升了根本说不清是哪个改动起的作用。正确的做法是基线跑一次改一个点再跑一次对比差异。这样得到的数据才能指导决策。7.3 报告要写“所以呢”不是只贴数字我见过太多压测报告一堆曲线和表格最后没有结论。看的人只想知道三件事能扛多少、瓶颈在哪、要不要优化。报告结构我一般这么写一句话结论 → 关键指标表 → 瓶颈分析 → 优化建议 → 附录原始数据。让决策者三十秒能看完结论需要细节的人再往下翻。最后分享一个小技巧。压测脚本写完后先用极低并发比如1个用户跑一遍确认所有请求都是成功的、参数都是对的。这一步花不了一分钟但能避免拿一个本身就有问题的脚本跑了几十分钟最后发现全是错误请求。这个习惯我强烈建议你从第一次压测就开始养。