<p>リクエストのパフォーマンスが低下し、大きなバイナリ応答をストリーミングする</p>

そのオーバーヘッドは予想外に大きいです。 ただし、それを回避するのは難しいかもしれません。

大きな問題は、チャンクごとにかなり多くの処理を行うことです。 それはスタックのずっと下にあります：リクエスト、urllib3とhttplib。 誰が非効率を引​​き起こしているのかを解明するためにどこで時間が費やされているかを知ることは非常に興味深いでしょう。

次のステップは、httplib / urllib3のプロファイリングを試して
そこのパフォーマンス？

ケビン・バーク
電話番号：925.271.7005 | 20milliseconds.com

5時01分PMに木、2014年12月4日には、コーリーベンフィールド[email protected]
書きました：

そのオーバーヘッドは予想外に大きいです。 ただし、それを回避するのは難しいかもしれません。

大きな問題は、チャンクごとにかなり多くの処理を行うことです。 それは
スタックの最後まで：リクエスト、urllib3、httplib。 それはそのようになります
誰が誰であるかを解明するためにどこで時間が費やされているかを見るのは非常に興味深い
非効率を引​​き起こしています。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65732050
。

urllib3でベンチマークを実行しただけです。

PyPy：120MB /秒
CPython：70MB /秒

そして、CPython +リクエストを再実行しました：35MB /秒

（私のマシンはベンチマークでかなりのノイズを経験しているようです、誰かがこれらを使用できるより静かなシステムを持っているなら、それは素晴らしいでしょう）

他のすべてをシャットダウンした後、自分のマシンでこれらを実行してみました
アプリケーションとターミナルウィンドウ、そしてかなりの量のノイズもありました-
ソケットベンチマークは30mb / sから460mb / sの範囲でした。

ケビン・バーク
電話番号：925.271.7005 | 20milliseconds.com

21:24の木、2014年12月4日には、アレックス・ゲイナー[email protected]
書きました：

urllib3でベンチマークを実行しただけです。

PyPy：120MB /秒
CPython：70MB /秒

そして、CPython +リクエストを再実行しました：35MB /秒

（私のマシンは、ベンチマークでかなりのノイズが発生しているようです。
誰もがこれらを使用できるより静かなシステムを持っています、それは素晴らしいでしょう）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65748982
。

ベンチマークを実行しやすくしたので、他の人が私の数値を確認できるようになりました。

CPython：

BENCH SOCKET:
   8GiB 0:00:22 [ 360MiB/s] [======================================================>] 100%
BENCH HTTPLIB:
   8GiB 0:02:34 [53.1MiB/s] [======================================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:30 [90.2MiB/s] [======================================================>] 100%
BENCH REQUESTS
   8GiB 0:01:30 [90.7MiB/s] [======================================================>] 100%
BENCH GO HTTP
   8GiB 0:00:26 [ 305MiB/s] [======================================================>] 100%

PyPy：

BENCH SOCKET:
   8GiB 0:00:22 [ 357MiB/s] [======================================================>] 100%
BENCH HTTPLIB:
   8GiB 0:00:43 [ 189MiB/s] [======================================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:07 [ 121MiB/s] [======================================================>] 100%
BENCH REQUESTS
   8GiB 0:01:09 [ 117MiB/s] [======================================================>] 100%
BENCH GO HTTP
   8GiB 0:00:26 [ 307MiB/s] [======================================================>] 100%

ええと...それらの数字は奇妙です。 CPythonのhttplibは、両方のライブラリがhttplibを使用している場合でも、requestsまたはurllib3よりも低速です。 それは正しくありえません。

それらは私のために一貫して再現します-ベンチマークを試してみて、
再現できますか？ できると仮定して、何か問題がありますか
ベンチマーク？

午前11時16分45秒AMコーリーベンフィールドで金2014年12月5日には[email protected]
書きました：

ええと...それらの数字は奇妙です。 CPythonのhttplibはリクエストよりも遅いか
両方のライブラリがhttplibを使用している場合でも、urllib3？ それは正しくありえません。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65821989
。

私は今、既知の静かなマシンをつかんでいます。 それはインストールする必要がある物理的なボックスであるため、利用可能になるまでに数分かかるはずです（私はMAASが大好きです）。

CPython 2.7.8

BENCH SOCKET:
   8GiB 0:00:26 [ 309MiB/s] [================================>] 100%
BENCH HTTPLIB:
   8GiB 0:02:24 [56.5MiB/s] [================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:42 [79.7MiB/s] [================================>] 100%
BENCH REQUESTS
   8GiB 0:01:45 [77.9MiB/s] [================================>] 100%
BENCH GO HTTP
   8GiB 0:00:27 [ 297MiB/s] [================================>] 100%

それが価値があるもののために：

このパッチ、 CPython 3.4.2 ：

BENCH SOCKET:
   8GiB 0:00:27 [ 302MiB/s] [================================>] 100%
BENCH HTTPLIB:
   8GiB 0:00:53 [ 151MiB/s] [================================>] 100%
BENCH URLLIB3:
   8GiB 0:00:54 [ 149MiB/s] [================================>] 100%
BENCH REQUESTS
   8GiB 0:00:56 [ 144MiB/s] [================================>] 100%
BENCH GO HTTP
   8GiB 0:00:31 [ 256MiB/s] [================================>] 100%

Python2でも同じ効果が得られるはずです。
env PYTHONUNBUFFERED=または-uフラグ。

午前11時42分36秒AMコーリーファーウェルで金2014年12月5日には[email protected]
書きました：

それが価値があるもののために：

このパッチhttps://gist.github.com/frewsxcv/1c0f3c81cda508e1bca9、CPython
3.4.2：

ベンチソケット：
8GiB 0:00:27 [302MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:00:53 [151MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:00:54 [149MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:00:56 [144MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:31 [256MiB / s] [================================>] 100％

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65826239
。

@alex興味深いことに、 env PYTHONUNBUFFERED=も-uもPython2に同じ影響を与えません。私のマシンの受信結果。

了解しました。以下のデータは、これらのテストを実行しているだけのマシンからのものです。 最後のテストは、Python -uフラグを設定して実行されましたが、ご覧のとおり、フラグは効果がありません。

Python 2.7.6
go version go1.2.1 linux/amd64
BENCH SOCKET:
   8GiB 0:00:16 [ 500MiB/s] [================================>] 100%
BENCH HTTPLIB:
   8GiB 0:01:32 [88.6MiB/s] [================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:20 [ 101MiB/s] [================================>] 100%
BENCH REQUESTS
   8GiB 0:01:21 [ 100MiB/s] [================================>] 100%
BENCH GO HTTP
   8GiB 0:00:21 [ 385MiB/s] [================================>] 100%

Python 2.7.6
go version go1.2.1 linux/amd64
BENCH SOCKET:
   8GiB 0:00:16 [ 503MiB/s] [================================>] 100%
BENCH HTTPLIB:
   8GiB 0:01:33 [87.8MiB/s] [================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:20 [ 101MiB/s] [================================>] 100%
BENCH REQUESTS
   8GiB 0:01:22 [99.3MiB/s] [================================>] 100%
BENCH GO HTTP
   8GiB 0:00:20 [ 391MiB/s] [================================>] 100%

Python 2.7.6
go version go1.2.1 linux/amd64
BENCH SOCKET:
   8GiB 0:00:16 [ 506MiB/s] [================================>] 100%
BENCH HTTPLIB:
   8GiB 0:01:31 [89.1MiB/s] [================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:20 [ 101MiB/s] [================================>] 100%
BENCH REQUESTS
   8GiB 0:01:20 [ 101MiB/s] [================================>] 100%
BENCH GO HTTP
   8GiB 0:00:21 [ 389MiB/s] [================================>] 100%

これらの数値は非常に安定しており、次の機能を示しています。

1. rawソケットの読み取りは高速です（duh）。
2. Goは、rawソケット読み取りの約80％の速度です。
3. urllib3は、rawソケット読み取りの約20％の速度です。
4. リクエストはurllib3よりも少し遅いです。これは、データが通過するためのスタックフレームをいくつか追加するので意味があります。
5. httplibはrequests / urllib3よりも遅いです。 それは不可能であり、httplibが構成されていない方法でhttplibまたはソケットライブラリを構成している必要があると思います。

FWIW、 @ kevinburkeからbuffering=Trueを追加してマージしました、実行してください
それを含めますか？

12時04分40秒PMコーリーベンフィールドで金2014年12月5日には[email protected]
書きました：

了解しました。以下のデータは、他に何もしていないマシンからのものです。
しかし、これらのテストを実行します。 最後のテストはPython-uフラグを使用して実行されました
を設定すると、ご覧のとおり、フラグは効果がありません。

Python 2.7.6
goバージョンgo1.2.1linux / amd64
ベンチソケット：
8GiB 0:00:16 [500MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:01:32 [88.6MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:01:20 [101MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:01:21 [100MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:21 [385MiB / s] [================================>] 100％

Python 2.7.6
goバージョンgo1.2.1linux / amd64
ベンチソケット：
8GiB 0:00:16 [503MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:01:33 [87.8MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:01:20 [101MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:01:22 [99.3MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:20 [391MiB / s] [================================>] 100％

Python 2.7.6
goバージョンgo1.2.1linux / amd64
ベンチソケット：
8GiB 0:00:16 [506MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:01:31 [89.1MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:01:20 [101MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:01:20 [101MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:21 [389MiB / s] [================================>] 100％

これらの数値は非常に安定しており、次の機能を示しています。

1. rawソケットの読み取りは高速です（duh）。
2. Goは、rawソケット読み取りの約80％の速度です。
3. urllib3は、rawソケット読み取りの約20％の速度です。
4. リクエストはurllib3よりも少し遅いです。
   データが通過するスタックフレームをいくつか追加します。
5. httplibはrequests / urllib3よりも遅いです。 それは不可能です、
   でhttplibまたはソケットライブラリを構成する必要があると思います
   httplibがそうではない方法。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65829335
。

Cory-をオンにするベンチクライアントの最新バージョンを参照してください
buffering = True in httplib（requests / urllib3と同様）

ケビン・バーク
電話番号：925.271.7005 | 20milliseconds.com

10：04 AMで金、2014年12月5日には、コーリーベンフィールド[email protected]
書きました：

了解しました。以下のデータは、他に何もしていないマシンからのものです。
しかし、これらのテストを実行します。 最後のテストはPython-uフラグを使用して実行されました
を設定すると、ご覧のとおり、フラグは効果がありません。

Python 2.7.6
goバージョンgo1.2.1linux / amd64
ベンチソケット：
8GiB 0:00:16 [500MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:01:32 [88.6MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:01:20 [101MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:01:21 [100MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:21 [385MiB / s] [================================>] 100％

Python 2.7.6
goバージョンgo1.2.1linux / amd64
ベンチソケット：
8GiB 0:00:16 [503MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:01:33 [87.8MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:01:20 [101MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:01:22 [99.3MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:20 [391MiB / s] [================================>] 100％

Python 2.7.6
goバージョンgo1.2.1linux / amd64
ベンチソケット：
8GiB 0:00:16 [506MiB / s] [================================>] 100％
ベンチHTTPLIB：
8GiB 0:01:31 [89.1MiB / s] [================================>] 100％
ベンチURLLIB3：
8GiB 0:01:20 [101MiB / s] [================================>] 100％
ベンチリクエスト
8GiB 0:01:20 [101MiB / s] [================================>] 100％
BENCH GO HTTP
8GiB 0:00:21 [389MiB / s] [================================>] 100％

これらの数値は非常に安定しており、次の機能を示しています。

1. rawソケットの読み取りは高速です（duh）。
2. Goは、rawソケット読み取りの約80％の速度です。
3. urllib3は、rawソケット読み取りの約20％の速度です。
4. リクエストはurllib3よりも少し遅いです。
   データが通過するスタックフレームをいくつか追加します。
5. httplibはrequests / urllib3よりも遅いです。 それは不可能です、
   でhttplibまたはソケットライブラリを構成する必要があると思います
   httplibがそうではない方法。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65829335
。

ええ、それははるかに理にかなっているようにhttplibのパフォーマンスの振る舞いを修正します。

新しい結果と結論：

Python 2.7.6
go version go1.2.1 linux/amd64
BENCH SOCKET:
   8GiB 0:00:16 [ 499MiB/s] [================================>] 100%
BENCH HTTPLIB:
   8GiB 0:01:12 [ 113MiB/s] [================================>] 100%
BENCH URLLIB3:
   8GiB 0:01:21 [ 100MiB/s] [================================>] 100%
BENCH REQUESTS
   8GiB 0:01:20 [ 101MiB/s] [================================>] 100%
BENCH GO HTTP
   8GiB 0:00:20 [ 391MiB/s] [================================>] 100%

1. rawソケットの読み取りは高速です（duh）。
2. Goは、rawソケット読み取りの約80％の速度です。
3. httplibは、rawソケット読み取りの25％弱の速度です。
4. urllib3はrawソケット読み取りの約20％の速度であり、httplibにわずかなオーバーヘッドを追加します。
5. リクエストはurllib3よりも少し遅いです。これは、データが通過するためのスタックフレームをいくつか追加するので意味があります。

したがって、おそらくここでの実際のコストはhttplibです。 これを高速化するには、httplibを邪魔にならないようにする必要があります。

httplibのどの部分が私たちにコストをかけているのかを解明することに興味があります。 bench_httplib.pyプロファイリングは次の良いステップだと思います。

bench_socket.pyテストにその行を追加することで、 socket.makefileを介したソケットからファイルオブジェクトへの変換を除外しましたが、速度はまったく低下しません。 奇妙なことに、それはそれをより速くするように見えます。

答えはほぼ確実に転送エンコーディングです：チャンク処理。
参照： https ：
サーバー上のContent-Lengthは、予期しない結果を生成します。

12時24分53秒PMコーリーベンフィールドで金2014年12月5日には[email protected]
書きました：

したがって、おそらくここでの実際のコストはhttplibです。 これをスピードアップするには
httplibを邪魔にならないようにします。

httplibのどの部分が私たちにコストをかけているのかを解明することに興味があります。 私
次のステップとして、bench_httplib.pyのプロファイリングが適切だと思います。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65831653
。

面白い。

チャンク処理はほぼ確実に問題であり、特にチャンクがgoのデフォルトのHTTPモードであるため、goがそれをより適切に処理することにそれほど驚いていません。

ただし、rawソケットよりも高速なリクエストは...予期しないものです。

注目に値することの1つは、ソケットが前のテストでチャンクエンコーディングをデコードしていなかった場合、他の方法よりも実際に読み取るデータが少ないため、不当な利点がありました。 彼らは全員、チャンク化されたヘッダーと8GBのデータを読み取っていました。

これは次の質問につながります：これらのメソッドのすべてが実際に同じ量のデータを読み取っていると私たちはまだ考えていますか？

はい、ソケットレイヤーは不正行為をしていました。チャンク化されたメタデータをデコードしませんでした。
技術的には少し読みにくくなっています。 それは「どれだけ速く」の基礎としてそこにありました
私たちは読むことができますか」、何も証明するためではありません。

午前12時33分10秒PMコーリーベンフィールドで金2014年12月5日には[email protected]
書きました：

面白い。

チャンク処理はほぼ確実に問題であり、私は実際にはそうではありません
特にチャンクがデフォルトであるため、goがそれをより適切に処理することに驚いています
goのHTTPモード。

ただし、rawソケットよりも高速なリクエストは...予期しないものです。

注目に値する1つのこと：ソケットがチャンクエンコーディングをデコードしていなかった場合
以前のテストでは、実際にはそうであったように、それは不公平な利点を得ました
他の方法よりも少ないデータを読み取る！ 彼らは皆読んでいた
チャンク化されたヘッダーと8GBのデータ。

これは次の質問につながります：私たちはまだこれらの方法のすべてを考えていますか？
実際に同じ量のデータを読み取っていますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65833299
。

これが、一度にソケットから読み取っているチャンクサイズに関連していても驚かないでしょう。

非常に役立つ@alexのケーキ：cake：

@nelhageは、さまざまな例のいくつかのストレーシングを行いました（転送で
エンコーディング：チャンクケース） https://gist.github.com/nelhage/dd6490fbc5cfb815f762
結果です。 httplibにバグがあり、その結果、
常にソケットから完全なチャンクを読み取るとは限りません。

午前9時05分14秒AMケネスReitz氏で月2014年12月8日には[email protected]
書きました：

@alexのケーキhttps://github.com/alex非常に役立つ[画像：
：ケーキ：]

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -66147998
。

では、ここにあるのは、誰も実際に保守していない標準ライブラリのバグですか？ （ @Lukasaには、1年以上開いているパッチセットが少なくとも2つあります。）たぶん、今夜どこかでリストに悪臭を

誰か（私はそれに到達するかもしれませんが、不明です）はおそらくpdbでドリルダウンする必要があります
または何かをして、それらの20バイトを生成している正確なコードを把握します
良いバグレポートをまとめられるように読みます。

午前九時14分09秒AMイアンCordascoで月2014年12月8日には[email protected]
書きました：

つまり、ここにあるのは、標準ライブラリのバグであり、実際には誰もいないということです。
維持しますか？ （ @Lukasahttps ：//github.com/Lukasaには少なくとも2つのパッチがあります
1年以上オープンしているセットです。）たぶん私はリストに悪臭を放ちます
今夜どこか

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kennethreitz/requests/issues/2371#issuecomment -66149522
。

誰もそれに到達しない場合、私は今夜または明日にそれを適合させようとします。

それで、根本的な原因に関するニュースはありますか？ これらの短い読み取りを生成しているのは何ですか？また、それらがないと状況はどの程度改善されますか？

@kislyuk私が知る限りではありません。 うまくいけば、私はこのクリスマス休暇を追いかける時間があります。

@Lukasaに感謝します。 urllib3 / requestsを使用したチャンク化された応答のダウンロード速度がcurlや他のライブラリよりもはるかに遅いというパフォーマンスの問題に対処しており、これが原因かどうかを理解しようとしています。

私はこれを少し突っついていました。 短い読み取りは、httplibの_read_chunked関数から取得されます

https://fossies.org/linux/misc/Python-2.7.9.tgz/Python-2.7.9/Lib/httplib.py#l_585

2バイトの読み取りは、主に622行目からのもののようです。

以前に投稿したものとは少し異なるstraceパターンを取得しました。
recvfrom（3、 "400 \ r \ n \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 "...、8192、0、NULL、NULL）= 8192
recvfrom（3、 "\ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 "...、54、0、NULL、NULL）= 54
recvfrom（3、 "\ r \ n"、2、0、NULL、NULL）= 2

このパターンは次のように説明できます。

• self.fp.readline（591行目）は、8192バイト（socket.readline内）のバッファ読み取りをトリガーします
• 消費される各チャンクは1031バイトです（5バイトのチャンク長（ "400 \ r \ n"）+ 1024バイトのデータ+2バイトのターミネーター）
• バッファリングされた8192バイトからこのようなチャンクを7つ消費できるため、975バイトが残ります。
• 次に、970バイトを残す次のチャンク長（5バイト）を読み取ります
• 現在のチャンク（1024）を満たすには不十分な970バイトしかないため、54バイトの不足のためにネットワークに戻ります。
• これを実現するために、httplibは未処理のバイトに対してsock.read（54）を実行します。 この場合（明示的な長さの）socket.readは、（別の8192をバッファリングするのではなく）指定された54バイトのネットワークに移動することを選択します。
• 次に、2バイトのチャンクターミネーターを読み取ります。これも上記と同じシナリオです。

その後、パターンが繰り返されます（ステップ1に戻ります）

FWIW、ここでは、2バイトのチャンクターミネーターの読み取りをチャンク本体の読み取りにロールインすることで、適度な（20％程度）高速化が可能であることがわかりました。

            value.append(self._safe_read(chunk_left)) 
            amt -= chunk_left

        self._safe_read(2)  # toss the CRLF at the end of the chunk

代わりにこれを行います：

            value.append(self._safe_read(chunk_left + 2)[:-2]) 
            amt -= chunk_left

ただし、実際には、54バイトの読み取りで54バイト（つまり8192バイト）よりも多くのバイトをバッファリングできれば、おそらくより良いでしょう。つまり、2バイトの読み取りに関してはバッファリングされたソケットが空にならないということです。

これに加えて。 小さな読み取りがスループットの損失の主な要因であるかどうかはわかりません（またはローカルホストではありません）。 ソケットバッファサイズを1031バイトの倍数になるように試してみましたが、straceの読み取りが小さくなったにもかかわらず、スループットに大きな影響はありませんでした。

スループットの低下は、socket.pyが小さな読み取りを処理する方法に関係している可能性があると思います。 関連するコードは次のとおりです（socket.readから）：

https://fossies.org/linux/misc/Python-2.7.9.tgz/Python-2.7.9/Lib/socket.py#l_336

明示的な長さをsocket.readに渡し、既存のバッファリングされたデータからそれを実行できる場合、これはコードパスです。

        buf = self._rbuf
        buf.seek(0, 2)  # seek end

        #.....

        # Read until size bytes or EOF seen, whichever comes first
        buf_len = buf.tell()
        if buf_len >= size:
            # Already have size bytes in our buffer?  Extract and return.
            buf.seek(0)
            rv = buf.read(size)
            self._rbuf = StringIO()
            self._rbuf.write(buf.read())
            return rv

ここで私が認識している問題は、2バイトの読み取りでさえ、未読の残りを新しいStringIOにコピーすることを意味するということです。 これは、多くの小さな読み取りでは非常に高価になるようです。 未読の残りを新しいStringIOにコピーする現在のパターンではなく、特定のStringIOが読み取りごとに何らかの形で排出される可能性がある場合は、スループットに役立つと思います。

@gardenia私はこれらすべてを吸収する機会がありませんでしたが、あなたの努力とここでの仕事に感謝します。 @shazowおそらく、 @ gardeniaの研究は興味深いと思うでしょう。

：+1：@gardeniaに感謝します。 ちなみに、私のユースケースでのパフォーマンスに関する私自身の調査では、私の場合、応答はチャンク化されていないことがわかりましたが、urllib3は要求よりも20％以上高速であるため、特徴づけたいオーバーヘッドがいくつか導入されています。 まだこの問題のタイトルと一致していますが、根本的な原因は異なります。

魅力的です、共有してくれてありがとう！ :)

@LukasaのHyperが取り組む思えます。

@ alex-私はあなたが言及したチャンクされていないパフォーマンスの問題に対してurllib3vsrequestsを少しいじりました。 リクエストも同様に20％減少すると思います。

リクエストでは、self.raw.streamの呼び出しを（urllib3からの）stream（）のインライン実装に置き換えようと推測しました。 少なくとも私のマシンでは、リクエストとurllib3の間でスループットが大幅に近くなるようでした。

--- requests.repo/requests/models.py    2015-03-06 16:05:52.072509869 +0000
+++ requests/models.py  2015-03-07 20:49:25.618007438 +0000
@@ -19,6 +19,7 @@
 from .packages.urllib3.fields import RequestField
 from .packages.urllib3.filepost import encode_multipart_formdata
 from .packages.urllib3.util import parse_url
+from .packages.urllib3.util.response import is_fp_closed
 from .packages.urllib3.exceptions import (
     DecodeError, ReadTimeoutError, ProtocolError, LocationParseError)
 from .exceptions import (
@@ -652,8 +654,12 @@
             try:
                 # Special case for urllib3.
                 try:
-                    for chunk in self.raw.stream(chunk_size, decode_content=True):
-                        yield chunk
+                    while not is_fp_closed(self.raw._fp):
+                        data = self.read(amt=chunk_size, decode_content=True)
+
+                        if data:
+                            yield data
+
                 except ProtocolError as e:
                     raise ChunkedEncodingError(e)
                 except DecodeError as e:

たぶん、あなたはそれがあなたにも違いをもたらすかどうか見るためにあなたのマシンで同じことを試みることができます。

（はい、is_fp_closedの呼び出しはカプセル化の無効化であることがわかっています。これは、単なるデータポイントである重大なパッチを意味するものではありません）

@shazowハイパーが使用するBufferedSocketが、本質的に小さな読み取りを防ぐことによって、その非効率性の多くに対処することを願っています。 Py3のhttplibは、 io.BufferedReader広範囲に使用するため、この問題があるのではないかと思います。これは、 BufferedSocketとほぼ同じ種類の利点を提供するはずです。

ただし、確かに、 hyperが十分にHTTP / 1.1機能を拡張して役立つようになったら、これらの他の実装と一緒にベンチマークを行い、 hyperをできるだけ速くするように努力する必要があります。

ほぼ1年間非アクティブ。 閉鎖。

私は10倍以下使用してrequestsと比較して、 urllib3 。

この問題はurllib3のHTTPResponseクラス内にあると思います。イテレータとして読み取られると、スループットが非常に悪くなります。 コードを非常に醜いハックで動作させました。urllib3で使用されている下線付きのhttplib.HTTPResponseオブジェクトを返します。これで、スループットの問題が解決したようです。

興味深い事実：urllib3のHTTPResponseスーパークラスはio.IOBaseです。 Python3のhttplib.HTTPResponseスーパークラスはio.BufferedIOBaseです。 これと関係があるのか​​しら。