1. 项目背景业务场景某 API 聚合平台需要同时调用 5 个下游微服务来组装一个用户 Profile 页面。这 5 个服务的响应时间差异巨大用户基础信息服务 20ms、订单服务 150ms、推荐服务 300ms、好友服务 100ms、会员等级服务 50ms。最初方案是串行调用——总耗时 2015030010050 620ms远超过 200ms 的 P99 SLA 目标。团队决定改为并发调用但优化完成后需要客观地衡量优化效果。架构师要求回答三个问题1当前 QPS 瓶颈在哪里2从串行改为并发后 P99 降低了多少3CPU 和内存的资源消耗增长是否在可接受范围内没有数据支撑的优化只是猜测——需要性能基准测试。痛点问题一我觉得慢了不是有效的性能评估。很多团队的性能优化基于主观感受——“这个接口好像比以前快了”。没有基准测试benchmark你无法量化优化效果也无法在上线前预测新版本是否会引入性能回退。问题二性能瓶颈的多层性。一次 HTTP 请求的延迟由多层组成DNS 解析~5-50ms、TCP 握手~10-50ms、TLS 握手~50-200ms首次、HTTP 请求发送~1ms、服务器处理变化最大、响应体接收取决于大小。如果你不测量每一层的耗时你就不知道瓶颈在哪——是网络问题SSL 问题还是服务端处理慢问题三requests、httpx、urllib3 原生——不同的使用场景。这三个库在不同场景下的性能特征差异很大。requests 的同步模型适合 IO 密集型的中低并发场景httpx 同时支持同步和 async适合高并发urllib3 是 requests 的底层直接使用可以获得更精细的控制但也更复杂。选型需要数据支撑。性能分析分层图总延迟 620ms ├── DNS 解析: 5ms (0.8%) ├── TCP 握手: 15ms (2.4%) ├── TLS 握手: 50ms (8.1%) ├── 网络传输: 20ms (3.2%) ├── 服务器处理: 500ms (80.6%) ← 瓶颈在这里! └── 响应解析: 30ms (4.8%)2. 项目设计小胖望着监控大屏上的 P99 红线“大师优化了一周的代码P99 从 600ms 降到了 400ms——但老板问我具体优化了多少、哪个优化最有效、还能不能再优化我答不上来。优化前我没跑基准测试现在没有对比数据”大师叹了口气“你这就像减肥前后没拍照——你说你瘦了 10 斤但没有’减肥前’的照片谁信性能优化第一条铁律——优化前先跑 benchmark优化后再跑一次对比数据说话。”小胖挠头“那怎么跑 benchmark用time.time()手动计时”大师“手动计时是最粗糙的方式。专业的 benchmark 需要固定迭代次数、去掉热身阶段JIT 编译/DNS 缓存、多次运行取中位数、控制变量法只改一个因素。Python 有timeit、perf_counter、以及专业的 benchmark 框架如pytest-benchmark、locust。”小白推了推眼镜“大师我怎么知道性能瓶颈在哪里一个请求 500ms是 DNS 慢、TLS 慢、还是服务端慢”大师在白板上画出多层模型“用’分阶段计时法’——把一次 HTTP 请求拆成几个阶段分别计时”importrequestsimporttime# 分别在 DNS、TCP、TLS、Request、Response 阶段计时# 方法1在 requests 的 hooks 中分阶段打点# 方法2用 pycurl/curl 的详细时间输出# curl 的时间分解输出# time_namelookup: DNS 解析时间# time_connect: TCP 连接建立时间# time_appconnect: TLS/SSL 握手时间# time_starttransfer: 收到第一个字节的时间# time_total: 总时间小胖追问“那 requests、httpx、aiohttp 怎么选它们性能差异大吗”大师这三者的应用场景完全不同——选型不看绝对性能看场景匹配度requests同步、易用、生态最成熟。适合 IO 密集但并发量中低的场景 100 并发线程。httpx同时支持同步和 asyncAPI 类似 requests。适合需要渐进式迁移到 async 的项目。aiohttp纯 async性能最高。适合高并发 IO 场景 1000 并发。urllib3 原生性能略优于 requests少了上层包装但 API 更底层。“在同等条件下单线程、同步、100 次请求这三者的延迟几乎一样——瓶颈在网络和服务器不在客户端库。真正的差异在于并发模型async 可以让你在等待 IO 时做其他事情。”生活比喻技术映射减肥前后拍照优化前后 benchmark 对比医院体检分科室检查分阶段计时DNS/TCP/TLS/HTTP小轿车 vs 货车 vs 赛车requests vs httpx vs aiohttp多人一起排队串行慢串行 vs 并发高速公路收费站限流QPS 瓶颈分析3. 项目实战环境准备pipinstallrequests httpx aiohttp matplotlib分步实现步骤一自定义 Benchmark 框架目标实现一个可复用的 HTTP Benchmark 工具。importrequestsimporttimeimportstatisticsfromtypingimportCallable,Dict,Anyfromfunctoolsimportwrapsdefbenchmark(name:str,warmup:int5,iterations:int50,)-Callable:Benchmark 装饰器——自动测量函数的性能指标 用法: benchmark(nameAPI请求, warmup5, iterations50) def fetch_data(): return requests.get(https://httpbin.org/get) defdecorator(func:Callable):wraps(func)defwrapper(*args,**kwargs)-Dict[str,Any]:times[]errors0# 热身阶段预热 DNS 缓存、JIT 编译等for_inrange(warmup):try:func(*args,**kwargs)exceptException:pass# 正式测量for_inrange(iterations):starttime.perf_counter()try:func(*args,**kwargs)elapsedtime.perf_counter()-start times.append(elapsed)exceptException:errors1ifnottimes:return{error:所有请求均失败}sorted_timessorted(times)totalsum(times)avgtotal/len(times)p50statistics.median(sorted_times)p90sorted_times[int(len(sorted_times)*0.9)]p99sorted_times[int(len(sorted_times)*0.99)]qpsiterations/totalreturn{name:nameorfunc.__name__,iterations:iterations,errors:errors,total_time_s:round(total,3),avg_ms:round(avg*1000,2),p50_ms:round(p50*1000,2),p90_ms:round(p90*1000,2),p99_ms:round(p99*1000,2),min_ms:round(sorted_times[0]*1000,2),max_ms:round(sorted_times[-1]*1000,2),qps:round(qps,1),}returnwrapperreturndecorator# 使用演示 # 对比 Session vs 无 Session 的性能sessionrequests.Session()benchmark(name无Session,warmup3,iterations30)deffetch_without_session():returnrequests.get(https://httpbin.org/get,timeout10)benchmark(name有Session,warmup3,iterations30)deffetch_with_session():returnsession.get(https://httpbin.org/get,timeout10)result_no_sfetch_without_session()result_sfetch_with_session()session.close()print( Benchmark 结果 )forrin[result_no_s,result_s]:print(f\n{r[name]}:)print(f 样本:{r[iterations]}次, 错误:{r[errors]})print(f Avg:{r[avg_ms]}ms | P50:{r[p50_ms]}ms)print(f P90:{r[p90_ms]}ms | P99:{r[p99_ms]}ms)print(f Min:{r[min_ms]}ms | Max:{r[max_ms]}ms)print(f QPS:{r[qps]})# 对比总结ifresult_no_sandresult_s:improvement((result_no_s[avg_ms]-result_s[avg_ms])/result_no_s[avg_ms]*100)print(f\nSession 提升:{improvement:.1f}%)运行输出预期 Benchmark 结果 无Session: 样本: 30 次, 错误: 0 Avg: 425.32ms | P50: 415.10ms P90: 510.25ms | P99: 580.45ms Min: 320.12ms | Max: 620.33ms QPS: 2.3 有Session: 样本: 30 次, 错误: 0 Avg: 180.15ms | P50: 170.22ms P90: 220.12ms | P99: 260.11ms Min: 145.08ms | Max: 280.56ms QPS: 5.5 Session 提升: 57.6%步骤二分阶段计时——精确定位瓶颈目标测量请求各阶段的耗时找到性能瓶颈。importrequestsimporttimeimportstatisticsfromurllib.parseimporturlparseimportsocketdefdetailed_timing(url:str,iterations:int5)-dict:分阶段测量 HTTP 请求的各层耗时parsedurlparse(url)hostnameparsed.hostname portparsed.portor(443ifparsed.schemehttpselse80)stages{dns_lookup:[],tcp_connect:[],tls_handshake:[],request_send:[],server_processing:[],total:[],}for_inrange(iterations):# DNS 解析阶段starttime.perf_counter()ipsocket.getaddrinfo(hostname,port)[0][4][0]stages[dns_lookup].append(time.perf_counter()-start)# TCP TLS HTTP用 requests 测量整体resp_starttime.perf_counter()resprequests.get(url,timeout10)total_timetime.perf_counter()-resp_start stages[total].append(total_time)# 尝试从 urllib3 级别的连接时间推算# 这些在 requests 层面无法直接获取需要用 pycurl 或自定义 adapterreturn{stage:{avg_ms:round(statistics.mean(times)*1000,2)iftimeselse0,pct:round((statistics.mean(times)/statistics.mean(stages[total])*100),1)iftimesandstages[total]else0,}forstage,timesinstages.items()}# 执行 timingdetailed_timing(https://httpbin.org/get,iterations5)print( 请求耗时分解 )total_mstiming[total][avg_ms]print(f总耗时:{total_ms}ms)forstagein[dns_lookup,tcp_connect,tls_handshake,server_processing]:mstiming[stage][avg_ms]pcttiming[stage][pct]bar#*int(pct/2)print(f{stage:20s}:{ms:7.1f}ms ({pct:4.1f}%){bar})步骤三requests vs httpx vs urllib3 对比目标对比三个库在同一场景下的性能差异。importrequestsimporturllib3importtimeimportstatisticsdefbench_requests_vs_urllib3(url:str,n:int30):对比 requests 和 urllib3 原生的性能差异# ---- requests 方式 ----requests_times[]srequests.Session()for_inrange(5):# 热身s.get(url)for_inrange(n):starttime.perf_counter()s.get(url)requests_times.append(time.perf_counter()-start)s.close()# ---- urllib3 原生方式 ----urllib3_times[]poolurllib3.PoolManager()for_inrange(5):pool.request(GET,url)for_inrange(n):starttime.perf_counter()pool.request(GET,url)urllib3_times.append(time.perf_counter()-start)return{requests:{avg_ms:round(statistics.mean(requests_times)*1000,2),p50_ms:round(statistics.median(requests_times)*1000,2),min_ms:round(min(requests_times)*1000,2),},urllib3:{avg_ms:round(statistics.mean(urllib3_times)*1000,2),p50_ms:round(statistics.median(urllib3_times)*1000,2),min_ms:round(min(urllib3_times)*1000,2),},}resultbench_requests_vs_urllib3(https://httpbin.org/get,n30)print( requests vs urllib3 )forlib,statsinresult.items():print(f\n{lib}:)print(f Avg:{stats[avg_ms]}ms)print(f P50:{stats[p50_ms]}ms)print(f Min:{stats[min_ms]}ms)avg_diff(result[requests][avg_ms]-result[urllib3][avg_ms])print(f\nrequests 比 urllib3 多:{avg_diff:.1f}ms/请求)print(差异来源: requests 的 header 合并、Cookie 处理、Hook 执行等上层开销)可能遇到的坑及解决方法坑1Benchmark 结果受网络波动影响# 解决多次运行取中位数 去掉热身阶段# 避免在一次 Benchmark 就下结论# 对结果使用统计方法标准差、置信区间坑2QPS 计算忽略并发场景# QPS iterations / total_time 只在串行场景有效# 并发场景需要 QPS concurrent_users / avg_response_time# 不要用串行的 QPS 公式来估算并发 QPS坑3热身阶段不足导致结论偏差# 前几次请求包含 DNS 查询、TCP 握手、TLS 握手等一次性成本# 如果不去掉热身数据会严重高估平均延迟# 建议前 5-10 次请求为热身不计入统计测试验证importpytestimportrequestsimporttimeclassTestBenchmark:验证 Benchmark 功能deftest_benchmark_decorator_returns_metrics(self):# 使用自定义的 benchmark 装饰器benchmark(nametest,warmup1,iterations5)deftest_func():returnrequests.get(https://httpbin.org/get)resulttest_func()assertresultisnotNoneassertavg_msinresultassertp50_msinresultassertresult[errors]0deftest_session_faster_than_no_session(self):验证 Session 比无 Session 平均更快srequests.Session()# 无 Sessiontimes_no_s[]for_inrange(10):starttime.perf_counter()requests.get(https://httpbin.org/get)times_no_s.append(time.perf_counter()-start)# 有 Sessiontimes_s[]for_inrange(10):starttime.perf_counter()s.get(https://httpbin.org/get)times_s.append(time.perf_counter()-start)importstatistics avg_no_sstatistics.mean(times_no_s[3:])# 去掉前 3 个热身avg_sstatistics.mean(times_s[3:])print(f\n无Session avg:{avg_no_s*1000:.0f}ms)print(f有Session avg:{avg_s*1000:.0f}ms)# Session 应该更快连接复用# assert avg_s avg_no_s # 在慢网络下不一定成立s.close()4. 项目总结核心知识点指标说明QPS每秒请求数 并发数 / 平均响应时间P50中位数延迟——50% 的请求快于此值P90长尾延迟——90% 的请求快于此值P99极端长尾——只有 1% 的请求慢于此值Avg平均延迟——受极端值影响大优点 缺点对比维度requestshttpxurllib3 原生易用性★★★★★★★★★☆★★☆☆☆同步性能★★★★☆★★★★☆★★★★★异步支持无★★★★★无功能完整性★★★★★★★★★☆★★★☆☆适用场景性能回归测试每次发版前跑 benchmark选型决策requests vs httpx vs aiohttp瓶颈定位分阶段计时找到延迟大头容量规划通过 QPS 测试估算需要的 Pod 数量注意事项Benchmark 前必须做热身warmup去掉 DNS 和 TLS 首次开销多次运行30 次取统计值单次结果不可靠关注 P90/P99 而不仅是平均值——平均值掩盖了长尾问题本地 benchmark 和线上环境差异巨大网络延迟不同常见踩坑经验案例一用平均值掩盖长尾问题。某团队优化后 Avg 延迟降了 200ms但 P99 反而升了 500ms。原因优化方案增加缓存对大多数请求生效但缓存未命中时多了一层查询。根因只看 Avg 不看 P99。修复基准测试必须同时报告 Avg/P50/P90/P99。案例二Benchmark 中的 DNS 缓存欺骗。开发在本地跑 benchmark50 次请求全在 50ms 内。上生产后 P50 150msP99 800ms。原因本地 benchmark 只测了一个 hostDNS 和连接都被缓存了。生产环境有几十个不同的 host。根因benchmark 的控制变量与生产不匹配。修复benchmark 场景应模拟生产环境的负载特征多个 host、多种请求方法、不同响应大小。案例三QPS 指标的错误解读。某 API 单线程 Benchmark 显示 QPS20团队估算 10 线程能到 QPS200。实际部署后 QPS 只有 80——原因是后端服务在 10 个并发请求下响应变慢了数据库锁竞争。根因QPS 不随并发数线性增长。修复benchmark 需要测试多种并发度下的 QPS画出 QPS-concurrency 曲线找到拐点。思考题设计题设计一个持续性能监控系统——在 CI/CD 流水线中每次提交都跑 Benchmark自动对比基线数据如果 P99 退化超过 10% 则告警。请设计数据存储方案存储哪些指标、如何对比历史数据和告警规则。分析题你的服务 P99 延迟在每天 10:00-10:05 突然从 200ms 飙升到 2000ms。你怀疑是某个下游 API 变慢了但没有分阶段计时数据。如何设计一个黑盒诊断方案——在不修改代码的情况下推断出延迟增加发生在哪个阶段DNS/TCP/TLS/Server延伸阅读与资源Milvus向量数据库实战修炼从 0 到 1精通向量检索与生产落地后端工程师的 AI 转型第一课Ollama 与私有化大模型实战10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析