国庆闲来无事，跑了一下 wreq-python 和其他 Python HTTP 客户端的 HTTPS 性能基准，发现自己的结果不太理想，于是顺着火焰图查了一下瓶颈。
项目地址：
https://github.com/0x676e67/wreq-python
之前通过 PyO3 和 pyo3-async-runtimes 做异步桥接，性能其实已经不错，但在这套实现里，反复获取 GIL 带来的额外开销和争用，还是影响了性能。
后来请 Claude 帮忙分析火焰图和几个主要耗时点，再把自己的思路和 PyO3 原生协程的实现作为参考，重写并优化了这部分桥接逻辑。咱也用 AI ，分析这些确实能省不少精力。
优化方向是有预期的，不过最后提升这么大，还是有点意外。下面贴一下基准结果，其中 ry 和 pyreqwest 也都是 Rust reqwest HTTP 客户端的 Python 绑定。
HTTP/1.1 的基准看看就好。wreq/reqwest 的连接池默认不限制连接数，并发时会打开很多连接； ry/pyreqwest 的默认配置有没有类似限制，我不确定。所以这部分结果就图个乐。
HTTP/2 这部分则都是在单个连接上并发请求。
完整的基准测试数据与源码：
https://python.wreq.org/en/latest/benchmark/
项目地址：
https://github.com/0x676e67/wreq-python
之前通过 PyO3 和 pyo3-async-runtimes 做异步桥接，性能其实已经不错，但在这套实现里，反复获取 GIL 带来的额外开销和争用，还是影响了性能。
后来请 Claude 帮忙分析火焰图和几个主要耗时点，再把自己的思路和 PyO3 原生协程的实现作为参考，重写并优化了这部分桥接逻辑。咱也用 AI ，分析这些确实能省不少精力。
优化方向是有预期的，不过最后提升这么大，还是有点意外。下面贴一下基准结果，其中 ry 和 pyreqwest 也都是 Rust reqwest HTTP 客户端的 Python 绑定。
HTTP/1.1 的基准看看就好。wreq/reqwest 的连接池默认不限制连接数，并发时会打开很多连接； ry/pyreqwest 的默认配置有没有类似限制，我不确定。所以这部分结果就图个乐。
HTTP/2 这部分则都是在单个连接上并发请求。
完整的基准测试数据与源码：
https://python.wreq.org/en/latest/benchmark/
Select Language