Requests ライブラリと PyCurl のパフォーマンスはどのように比較されますか?
私の理解では、Requests は urllib の python ラッパーであるのに対し、PyCurl はネイティブの libcurl の python ラッパーであるため、PyCurl のパフォーマンスは向上するはずですが、どの程度かはわかりません。
比較するベンチマークが見つかりません。
Requests ライブラリと PyCurl のパフォーマンスはどのように比較されますか?
私の理解では、Requests は urllib の python ラッパーであるのに対し、PyCurl はネイティブの libcurl の python ラッパーであるため、PyCurl のパフォーマンスは向上するはずですが、どの程度かはわかりません。
比較するベンチマークが見つかりません。
gUnicorn/meinheld + nginx (パフォーマンスと HTTPS 用) に裏打ちされた簡単な Flask アプリケーションを使用して、10,000 件のリクエストを完了するのにかかる時間を確認する完全なベンチマークを作成しました。テストはアンロードされた c4.large インスタンスのペアで AWS で実行され、サーバー インスタンスは CPU 制限されていませんでした。
TL;DR の要約:多くのネットワーキングを行っている場合は PyCurl を使用し、それ以外の場合はリクエストを使用します。PyCurl は、大きなリクエスト (ここでは約 520 MBit または 65 MB/秒) で帯域幅の制限に達するまで、リクエストの 2 倍から 3 倍の速さで小さなリクエストを終了し、3 倍から 10 倍少ない CPU パワーを使用します。これらの図は、接続プーリングの動作が同じ場合を比較しています。デフォルトでは、PyCurl は接続プールと DNS キャッシュを使用しますが、リクエストは使用しません。そのため、素朴な実装は 10 倍遅くなります。
関係する桁数が大きいため、二重対数プロットは以下のグラフにのみ使用されていることに注意してください。
完全な結果は、ベンチマークの方法論とシステム構成とともに、リンクにあります。
警告:結果が科学的な方法で収集されるように苦労しましたが、1 つのシステム タイプと 1 つのオペレーティング システム、およびパフォーマンスと特に HTTPS オプションの限られたサブセットのみをテストしています。