前回の記事でhttpxの検討を進めた後にこんな気になる記事を見かけたので現状を調査しました。
結論から言うと、これは httpx を async で利用する時の問題で、現状ではまだ解決されていません。同期APIを使っていれば問題ありません。
原因は、httpxの低レイヤーライブラリであるhttpcoreがanyio.Lockを使っていたのですが、その実装がasyncio.Lockよりも大幅に遅いことです。httpcoreに提案されている解決策は3つあります。
- anyio依存排除 https://github.com/encode/httpcore/pull/922
- anyioに追加された fast_acquire を利用する https://github.com/encode/httpcore/pull/953
- コネクションプールの実装見直し https://github.com/encode/httpcore/pull/927
残念ながら a も b も、cの方が良いからという理由でマージされていません。 b は一度マージされたのですが revert されてしまいました。 https://github.com/encode/httpcore/pull/1002
cも開発が止まっているように見えますが、開発者の Kim Christie さんは2週間前から httpx のほとんどリライトとなる v1 ブランチをスタートしています。 https://github.com/encode/httpx/commits/v1/
ということで、開発が止まっているわけではないものの、asyncio利用時のパフォーマンス問題がいつ頃解決されるかは全く目処が立ちません。asyncioを使っていてパフォーマンスを無視できないのであれば aiohttp を使う他なさそうです。 httpxの機能が必要でaiohttpへの移行が大変な場合は、httpxの下位レイヤーをaiohttpにするためのコードがコメント欄で書かれていたので参考にしてください。 https://github.com/encode/httpx/issues/3215#issuecomment-2522013017
追記
httpxのパフォーマンス問題について - methaneのブログb.hatena.ne.jp“結論から言うと、これは httpx を async で利用する時の問題で、現状ではまだ解決されていません。同期APIを使っていれば問題ありません” / コネクションプーリングしない、でもいいと思います。
2025/09/29 12:29
そうですね。その場合はSSLContextの生成に時間がかかるのですが、次のようにSSLContextを使い回す方法があります。
