Python HTTP 客户端调优3 个让请求快 3 倍的关键参数做 HTTP 高并发业务的时候你有没有这种感觉——代码逻辑没问题单机测试也通但放到生产环境就是慢。单机一天只能处理几万请求离百万级还差一个数量级。其实很多时候问题不在业务逻辑而在 requests 库的使用姿势。今天说 3 个被忽视的关键参数把它们配好性能直接拉满。参数 1Session连接复用这是最重要的一招但也是最容易被忽视的。每次调用requests.get(url)库内部都要做这些事DNS 解析TCP 三次握手TLS 握手HTTPS发送请求等待响应保持连接HTTP/1.1 默认会保持但很多库用完就关你每发一次请求这套流程跑一遍。一次没事几千次、几万次下来开销就上来了。用 Session 复用连接省掉 1-3 步。实测下来简单业务能提速 2-3 倍。importrequests# 错误示范每次新建连接forurlinurls:resprequests.get(url)# ... 处理响应# 正确示范复用 Sessionsessionrequests.Session()forurlinurls:respsession.get(url)# ... 处理响应就这一行差别速度差 3 倍。参数 2连接池大小HTTPAdapterSession 帮你复用了连接但默认的连接池很小。requests 默认HTTPAdapter的pool_connections10、pool_maxsize10。10 个连接池意思是同时只能有 10 个保持连接。如果你开 50 个线程大部分线程在排队等连接。调大它importrequestsfromrequests.adaptersimportHTTPAdapter sessionrequests.Session()# 单 host 最多 50 个连接adapterHTTPAdapter(pool_connections20,# 连接不同 host 的池子数量pool_maxsize50,# 每个池子最大连接数max_retries3,# 失败重试次数)session.mount(http://,adapter)session.mount(https://,adapter)50 个并发请求处理 50 个不同页面连接池够用不会排队。参数 3超时设置看似与性能无关其实非常关键这一条很多人觉得奇怪超时不是防卡死的吗跟性能有什么关系关系很大。我见过太多 HTTP 客户端代码timeout 不设或者设得很大。一个慢接口就挂住整个线程100 个线程并发1 个慢接口就能让整个队列卡半天。正确做法连接超时和读取超时分开设# 错误示范超时太长或者干脆没设resprequests.get(url)# 默认无超时可能挂死# 错误示范超时太短resprequests.get(url,timeout1)# 正常接口被误伤成超时# 正确示范分阶段超时resprequests.get(url,timeout(3.05,10))# 连接超时 3.05 秒读取超时 10 秒3.05这个数是 requests 官方文档里推荐的连接超时抄就行。为什么分开连接超时设短3 秒连不上就快速失败。读取超时设长10 秒给慢接口一些余量。实战组合拳把上面 3 个参数组合起来就是一个高性能 HTTP 客户端的最小骨架importrequestsfromrequests.adaptersimportHTTPAdapterdefmake_session()-requests.Session:sessionrequests.Session()adapterHTTPAdapter(pool_connections20,pool_maxsize50,max_retries3,)session.mount(http://,adapter)session.mount(https://,adapter)returnsessiondeffetch(session:requests.Session,url:str)-str:respsession.get(url,timeout(3.05,10))resp.raise_for_status()returnresp.text# 使用sessionmake_session()forurlinurls:try:htmlfetch(session,url)# ... 处理 htmlexceptrequests.exceptions.RequestExceptionase:print(f请求{url}失败:{e})20 行不到的代码比裸跑快 3 倍。生产环境跑过稳定处理几十万请求没问题。写在最后性能优化这件事容易陷入无限优化——加缓存、加并发、加分布式……但其实对大多数中小规模 HTTP 业务上面 3 个参数调好就够用 90% 的场景。真的不够用了再考虑换 aiohttp / httpx异步并发上 Scrapy 这种成熟框架拆任务队列 分布式部署但那是另一个故事了。今天先把这 3 个参数用起来。最后给个速查表遇到性能问题按顺序查现象优先检查单机处理到几万请求就卡住没用 Session高并发时大量超时连接池太小pool_maxsize偶发挂死、不报错缺超时或超时太长单个请求成功率 90%服务端限流或网络异常看监控如果你正在被 HTTP 请求性能卡住、却又不知道从哪里下手从 Session 那个改动开始——改动一行效果立竿见影。