图片上传同步vs异步压测 — 高频面试深挖问答（精简版）
约 857 字大约 3 分钟
2026-08-06
1. 你这个压测脚本的核心测试原理是什么？
简答：
用多线程固定并发、固定时长，对比两套上传链路性能。
同步：HTTP 全程做完压缩+审核+落盘，响应返回即业务结束，统计真实 QPS 和延迟。
异步：HTTP 只受理请求、返回 taskId，耗时业务交给后台 Worker；客户端轮询任务结果，区分「受理性能」和「实际处理性能」。
2. 异步为什么要分两个 QPS？为什么不能和同步直接比？
简答：
异步有两个 QPS：
1. 受理 QPS：只代表接口收下请求，队列里可能堆满了没处理，虚高，不能对比。
2. 完成 QPS：Worker 真正处理完图片的数量，这是唯一能和同步 QPS 对比的指标。
核心结论：异步抗突发强，但真实处理能力受限于后台 Worker 数量。
3. 异步的端到端延迟为什么不准？有什么误差？
简答：
脚本用客户端轮询（0.2s 一次），任务完成后要等下一轮轮询才感知结果，会自带最多 0.2s 的轮询误差，导致 p95 延迟偏高。
最精准的方式是：用服务端任务完成时间戳计算耗时，不用客户端轮询时间。
4. 同步、异步压测出来的性能差异本质是什么？
简答：
同步：瓶颈在 HTTP 链路，所有耗时堵在请求里，并发一高延迟直接爆炸、QPS 上不去。
异步：解耦接收和处理，HTTP 极快、抗突发流量；但真实处理能力由 Worker 池决定，流量大会队列堆积、端到端延迟升高。
5. 你这个脚本有什么明显 Bug / 不严谨的地方？
简答（面试必问）：
原脚本的截止时间只限制「发起上传」，不限制轮询。压测时间结束后，线程还在继续轮询，导致部分超长耗时被统计进来，拉高 p95 延迟。
修复：轮询内部增加时间截止判断，超时直接终止。
6. P50、P95 简单解释，怎么算的？
简答：
把所有请求耗时从小到大排序。
P50（中位数）：一半请求比它快，一半比它慢，代表常规性能。
P95：95% 的请求都低于这个耗时，只有 5% 慢于它，专门反映尾部慢请求性能，压测重点看 P95。
面试终极总结（背这一段就够）
我通过固定并发、固定时长的多线程压测，对比图片同步和异步上传的性能。同步链路耗时全部挤压在 HTTP 流程里，并发升高延迟恶化明显，QPS 瓶颈靠前。异步将请求受理和业务处理解耦，接口瞬时吞吐更强、抗突发更好，但真实处理能力受后台 Worker 限制，队列积压会导致端到端尾部延迟升高。测试中我区分了异步受理 QPS 和完成 QPS，保证和同步指标对比公平，同时也发现了客户端轮询、时间窗口不严谨等测试误差问题。
（注：部分内容可能由 AI 生成）