分类标签归档：性能测试
导读：本文用一次完整实践回答 LLM/Agent 服务压测最常被问的三个问题——同时能撑多少人聊、瓶颈在哪、容量承诺怎么给。核心方法是 JMeter 阶梯加压逐档找软拐点（P95 抬头、稳定仍绿）与硬拐点（错误率抬头、连接层开始拒绝），并强调 SSE 流式接口"HTTP 200 但无可用 content 一律记失败"的判定口径（本次实测曾出现 3 并发档的空心 200）；关键结论是共享 LLM 配额下不能按节点数线性扩容（"10×3=30"仅在瓶颈全在本机时成立），最终以"常态 ≤10 并发/单实例、发版门禁错误率 ≤1%、
导读：本文对比同一套 Agent 服务走 A2A 协议通道与 HTTP 会话通道两种接入方式的阶梯压测结果，核心教训是"跨协议对比之前必须先对齐指标口径"：A2A 的 TTFT 指 task 帧到达（P50 约 1～2s，仅为服务端受理信号），HTTP 的 TTFT 指"首字"到达（P50 约 4～8s），两者直接比数字会得出"HTTP 慢三四倍"的假结论；真正可比的是完整时延，实测同阶梯下 HTTP 路径中位系统性快约 6s（约 -30%～-40%），且断连需区分 client 主动断与超时断，帧间隔要说明是相邻哪类帧。适合做跨
导读：本文解决"服务商只给 RPM/TPM 限流配额，业务却想知道能支撑多少用户与对话"的容量估算问题。核心方法是先用观测数据统计每轮对话的平均调用次数与 token 消耗，再按"容量 = min(RPM/每轮调用数, TPM/每轮token)"两个维度各除一次、取较小者；关键结论是长 prompt 场景下 token 维度几乎总是先撞墙（示意示例中 token 上限约 250 轮/分 vs 请求上限 2,500 轮/分），只看 RPM 会严重高估容量、上线后提早吃到 429。适合所有接入第三方 LLM API、需要做配额容
导读：这篇讲容量评估的完整方法链:先不做"没有目标的压测",而是用线上近 1 日真实调用量反推目标 QPS(以最高频接口约 4.1 万次/天为基准,分钟峰值约 350,秒级约 6 QPS,放大 10 倍定为 60 QPS),再在测试、线上环境做 1/15/30/60/90 并发的阶梯加压,结果测试环境 90 并发约 270 QPS 轻松达标、线上约 467 QPS。最宝贵的部分是线上压测才碰得到的两个坑——服务治理层的限流、前端中间件的 CPU 告警都先于被测服务真实瓶颈出现,提醒要区分"到底是哪个组件先到瓶颈"。适合用
导读：本文给出接口压测目标的可执行推导方法：有线上 QPS 的接口按"正常流量 10 倍且响应时间 200ms 内"设定目标，没有监控的接口用 80/20 法则从日访问量反推基准 TPS（TPS = 日访问量×80% /（活跃时长×3600×20%），如日访问 100 万约 46 TPS），再按 3 倍、10 倍分档加压直到报错以探明容量上限。适合需要为接口设定压测档位并同步盯机器、数据库、中间件指标的性能测试工程师。
分类：性能测试 ｜ 标签：性能测试、压测、QPS
做接口压测时，最常被问到的两个问题就是：压到多少 QPS 才算达