1. 性能测试面经TPS/QPS 压测配置与结果验证性能测试面试里TPS 和 QPS 几乎是必问的一对概念但很多人背得出定义真让你搭一套可复现的压测环境、把 TPS/QPS 指标采出来、再验证结果是否可信就卡壳了。这篇就按面试高频考点来拆什么是压力测试、什么是负载测试TPS 和 QPS 在什么场景下不相等以及怎么用一套统一的 Key/API 通道把压测脚本跑通、把指标采准。适合正在准备测开/性能方向面试的同学也适合日常需要做接口容量评估的后端和测试同学。核心检索词先摆出来性能测试是统称压力测试压的是极端和恢复能力负载测试找的是最大处理能力TPS 是每秒完整事务数QPS 是每秒请求数。下面从场景、配置、验证到排障一步步来配置骨架可以直接复制改。2. 先厘清概念压力测试、负载测试、TPS 与 QPS面试官问“什么是性能测试”标准回答是性能测试是统称指在正常或特定系统负载下验证响应时间、吞吐量和资源利用率是否达标。负载测试是逐步加并发观察指标变化直到出现瓶颈目的是找系统最大处理能力这条安全边界。压力测试则是把负载拉到超负荷甚至压崩看容错、降级、熔断和降压后能否自恢复属于破坏性测试。TPS 和 QPS 的区别是高频追问点。QPS 是每秒查询率指服务器每秒处理的单个请求数TPS 是每秒事务数一个事务代表一次完整业务操作可能包含多个请求。单接口压测时一个事务等于一个请求TPS 等于 QPS多接口复合业务下就不相等。比如“下单”事务后台要连续调校验库存、扣减余额、生成订单三个请求三个都成功才算一个 TPS而服务器处理了三个请求算三个 QPS此时 QPS 等于 3 倍 TPS。注意全链路业务压测以 TPS 为准因为用户体验基于完整业务单机容量评估或接口防刷以 QPS 为准因为要探某台机器或某段代码的请求极限。并发用户数和吞吐量的关系可以用三阶段模型记增涨期并发增加、TPS 线性上升、RT 稳定拐点期资源打满、TPS 到顶不再涨、RT 开始飙升崩溃期并发继续加、开始报错、TPS 断崖下跌。利特尔法则的简化公式是并发数等于 TPS 乘以响应时间比如 RT 200ms、目标 TPS 1000理论并发就是 1000 乘 0.2 等于 200。3. TaoToken 前置统一 Key/API 通道准备压测脚本里最烦的一件事是鉴权。每个接口一套 Key、Token 过期、环境切换脚本还没跑起来先被 401 拦住。我习惯用一个统一的 API 通道来收敛这件事TaoToken 就是干这个的它把模型对话、编码类接口的调用统一到一个 Key 和一套 API 地址上压测时脚本只需要维护一份鉴权配置换环境只改 base_url 和 Key不用逐个接口改。你需要准备的东西不多一个可用的 API Key一个统一的 base_url以及要压的目标接口路径。API 地址是 https://taotoken.net/api 注意这个不带查询参数直接作为请求前缀用。Key 在控制台生成入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 生成后复制保存压测脚本里通过变量注入别硬编码进 JMX 文件否则分布式压测分发脚本时容易泄露。如果你压的是模型对话类接口可以先用模型对话页面手动发一条请求确认 Key 和链路是通的入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。确认通了再写压测脚本能省掉大量“到底是脚本错还是 Key 错”的排查时间。长期做编码类或 Agent 类压测的可以看下 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 配额和调用方式更适合持续压。提示压测前先在低并发下跑通一次完整链路确认返回结构和字段名再上高并发。直接上高压最容易把配置错误误判成性能瓶颈。4. 可复制配置JMeter 压测骨架与 TPS/QPS 采集项下面给一份可以直接改的 JMeter 配置骨架用非 GUI 命令行方式跑方便复现和进 CI。核心是三块线程组控制并发、HTTP 请求头带统一鉴权、聚合报告采 TPS/QPS 和分位响应时间。先看线程组和请求头配置用 JMX 片段表示关键参数!-- 线程组200 并发 ramp-up 20 秒循环 10 次 -- ThreadGroup guiclassThreadGroupGui testclassThreadGroup testnameload-test intProp nameThreadGroup.num_threads200/intProp intProp nameThreadGroup.ramp_time20/intProp boolProp nameThreadGroup.schedulertrue/boolProp stringProp nameThreadGroup.duration600/stringProp elementProp nameThreadGroup.main_controller elementTypeLoopController intProp nameLoopController.loops10/intProp /elementProp /ThreadGroup !-- HTTP 信息头管理器统一鉴权 -- HeaderManager guiclassHeaderPanel testclassHeaderManager testnameauth-header collectionProp nameHeaderManager.headers elementProp name elementTypeHeader stringProp nameHeader.nameAuthorization/stringProp stringProp nameHeader.valueBearer ${__P(api_key)}/stringProp /elementProp elementProp name elementTypeHeader stringProp nameHeader.nameContent-Type/stringProp stringProp nameHeader.valueapplication/json/stringProp /elementProp /collectionProp /HeaderManager请求体用 JSONbase_url 通过命令行参数注入方便换环境{ model: your-model-name, messages: [ {role: user, content: ping} ], stream: false }命令行执行方式把 Key 和地址作为属性传进去避免写死在脚本里jmeter -n -t load-test.jmx \ -Japi_keysk-你的Key \ -Jbase_urlhttps://taotoken.net/api \ -l result.jtl \ -e -o report/TPS/QPS 采集项在聚合报告里对应关系要记牢Throughput 就是吞吐量单接口场景下等于 QPS复合事务场景下按事务控制器统计才是 TPSAverage 是平均响应时间95% Line 和 99% Line 是分位响应时间代表长尾用户的最差体验线Error% 是错误率。重点看三组Throughput 看吞吐极限95% Line 看延迟Error% 看稳定性三者同时达标才算通过。指标聚合报告字段含义达标参考TPS/QPSThroughput每秒成功处理请求/事务数达到目标值且不随并发上升而下降平均 RTAverage所有请求耗时算术平均易被长尾拉偏仅作参考95% RT95% Line95% 请求低于此值核心接口通常要求低于 200-500ms错误率Error %失败请求占比容量测试要求小于 0.1% 甚至为 0如果你要压的是复合事务用事务控制器把多个 HTTP 请求包起来这样 Throughput 统计的就是 TPS 而不是 QPS面试时能讲清这个区别很加分。5. 验证请求与成功结果从单请求到阶梯加压配置写完别急着上高压按三步验证。第一步单请求验证把线程数设成 1循环 1 次跑一遍看返回是否 200、响应体结构是否符合预期。这一步是排除配置错误不是测性能。第二步低并发验证线程数设 10ramp-up 10 秒跑 1 分钟看聚合报告里 Error% 是否为 0、Throughput 是否稳定。如果这一步就报错先查鉴权和 URL别往下走。第三步阶梯加压从 50 并发开始每轮加 50每轮跑 3-5 分钟记录每轮的 Throughput、95% Line、Error%。把数据整理成表找拐点# 从 jtl 结果文件提取每轮吞吐和分位快速看趋势 awk -F, NR1 {print $1, $2, $8} result.jtl | head -20成功的结果长这样并发从 50 加到 200 的过程中Throughput 线性上升95% Line 基本稳定在 200ms 以内Error% 为 0到 250 并发时 Throughput 不再涨、95% Line 跳到 800ms、Error% 开始出现说明 200-250 之间就是拐点200 附近是安全边界。这个边界值就是面试里能拿出来的实测数据比背定义有说服力得多。注意压测机自身也会成为瓶颈。如果压测机 CPU 打满或网卡跑满TPS 抖动是施压端造成的不是被测系统的问题。分布式压测就是为了解决这个。6. 本篇常见错排查错误一压测开始瞬间错误率 100%、TPS 为 0。这基本不是性能问题而是配置或环境问题。先查 URL、端口、路径是否写错再查 Key 是否过期或格式不对导致网关全部拦截返回 401/403最后确认被测环境本身是否存活。用单请求先跑通能快速定位。错误二TPS 卡在固定值不再上升95% Line 成倍暴涨。这是到达性能瓶颈拐点的信号固定值就是当前配置下的最大吞吐极限。底层某些关键资源比如连接池、线程池、CPU 已被占满新请求只能排队排队时间变长导致 RT 线性上涨。此时该做的是定位瓶颈资源而不是继续加并发。错误三平均 RT 很低但 99% Line 很高。这是长尾效应绝大多数请求快1% 请求极慢。常见原因是 JVM 周期性 Full GC 停顿、偶发慢查询或锁等待、线程池/连接池爆满导致排队。排查方向按应用层、数据层、中间件三层走。错误四TPS 锯齿状抖动。先排除压测机自身 Full GC 或网络丢包再查被测服务是否在频繁 Full GC 导致 Stop The WorldTPS 归零后回升就形成锯齿。用 jstat 连续监控 GC 计数变化可以确认。错误五分布式压测时部分 Slave 线程启动失败。多半是 CSV 参数化文件没分发到每台 Slave 机器Slave 本地找不到文件直接抛异常。正确做法是提前把数据文件复制到每台 Slave 的相同路径并把数据源切分避免多台读到同一段账号引发互斥报错。错误六限流阈值设了但没生效高压全打穿后端。检查限流节点位置是否被负载均衡绕过、动态规则是否推送到配置中心、限流维度是否只绑了单 IP 而分布式压测分散了来源 IP。7. 继续深入接入文档与 Coding Plan把上面的骨架跑通后下一步是把压测脚本接入持续流程用命令行加参数的方式跑结果文件归档方便对比不同版本的性能回归。接入相关的接口说明和参数细节可以看接入文档入口在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有请求格式、鉴权方式和返回字段的完整说明写断言和提取器时对着看能少踩坑。如果你压的是编码类或 Agent 类长链路接口调用频次高、需要稳定配额Coding Plan 更合适入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。Key 管理统一在控制台入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 生成、轮换、查看用量都在这里。压测前把 Key 和 base_url 通过命令行属性注入脚本里只留变量引用这样同一份 JMX 能在测试、预发、生产多环境复用也方便在面试时展示一套可复现的压测方案。