<p>요청에 성능이 좋지 않은 스트리밍 큰 바이너리 응답</p>

오버헤드가 예상외로 큽니다. 그러나 그것을 피하는 것은 까다로울 수 있습니다.

큰 문제는 우리가 청크당 꽤 많은 처리를 한다는 것입니다. 이것이 스택의 모든 것입니다: requests, urllib3 및 httplib. 누가 비효율성을 유발하는지 알아내기 위해 시간을 어디에 소비하는지 보는 것은 매우 흥미로울 것입니다.

다음 단계는 httplib / urllib3을 프로파일링하여
거기 성능?

케빈 버크
전화: 925.271.7005 | 20밀리초.com

2014년 12월 4일 목요일 오후 5:01 Cory Benfield 알림 @github.com
썼다:

오버헤드가 예상외로 큽니다. 그러나 그것을 피하는 것은 까다로울 수 있습니다.

큰 문제는 우리가 청크당 꽤 많은 처리를 한다는 것입니다. 그건
스택 아래로: requests, urllib3 및 httplib. 그것은
누가 시간을 소비하는지 확인하는 것은 매우 흥미 롭습니다.
비효율을 초래하고 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65732050
.

urllib3으로 벤치마크를 실행했습니다.

파이파이: 120MB/s
CPython: 70MB/s

그리고 CPython + 요청을 다시 실행했습니다. 35MB/s

(내 기계는 벤치마크에서 약간의 소음을 경험하는 것 같습니다. 누군가가 더 조용한 시스템을 가지고 있다면 굉장할 것입니다.)

나는 다른 모든 것을 종료 한 후 내 컴퓨터에서 이것을 실행하려고 시도했습니다.
응용 프로그램 및 터미널 창과 상당한 양의 소음이 발생했습니다.
소켓 벤치마크는 30mb/s에서 460mb/s 사이였습니다.

케빈 버크
전화: 925.271.7005 | 20밀리초.com

2014년 12월 4일 목요일 오후 9시 24분, Alex Gaynor [email protected]
썼다:

urllib3으로 벤치마크를 실행했습니다.

파이파이: 120MB/s
CPython: 70MB/s

그리고 CPython + 요청을 다시 실행했습니다. 35MB/s

(내 컴퓨터는 벤치마크에서 약간의 소음이 발생하는 것 같습니다.
누구든지 사용할 수 있는 더 조용한 시스템을 가지고 있습니다.

—
이 이메일에 직접 답장하거나 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%

파이파이:

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%

어...숫자가 이상하네요. 두 라이브러리가 모두 httplib를 사용하더라도 CPython의 httplib는 요청 또는 urllib3보다 느립니다. 그것은 옳을 수 없습니다.

그들은 나를 위해 일관되게 재생산합니다. 벤치마크를 시도하고
재현할 수 있습니까? 당신이 할 수 있다고 가정하고, 당신은 어떤 문제가
벤치마크?

2014년 12월 5일 금요일 오전 11:16:45 Cory Benfield [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 플래그.

2014년 12월 5일 금요일 오전 11:42:36 Corey Farwell [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%
벤치 GO HTTP
8GiB 0:00:31 [ 256MiB/s] [================================>] 100%

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65826239
.

@alex 흥미롭게도 env PYTHONUNBUFFERED= 또는 -u 는 Python 2에서 동일한 효과를 나타내지 않습니다. 내 컴퓨터에서 들어오는 결과입니다.

좋습니다. 아래 데이터는 이 테스트를 실행하는 것 외에는 아무 것도 하지 않는 시스템에서 가져온 것입니다. 마지막 테스트는 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. 원시 소켓 읽기는 빠릅니다.
2. Go는 원시 소켓 읽기 속도의 약 80%입니다.
3. urllib3은 원시 소켓 읽기 속도의 약 20%입니다.
4. 요청은 urllib3보다 약간 느립니다. 이는 데이터가 통과할 몇 개의 스택 프레임을 추가하기 때문에 의미가 있습니다.
5. httplib는 requests/urllib3보다 느립니다. 그것은 불가능하며 httplib가 아닌 방식으로 httplib 또는 소켓 라이브러리를 구성해야 한다고 생각합니다.

FWIW, 방금 @kevinburke 에서 buffering=True 를 추가하여 병합했습니다. 실행하세요.
그것을 포함?

2014년 12월 5일 금요일 오후 12:04:40 Cory Benfield [email protected]
썼다:

좋아, 아래 데이터는 다른 작업을 수행하지 않는 기계에서 가져온 것입니다.
하지만 이러한 테스트를 실행합니다. 마지막 테스트는 Python -u 플래그로 실행되었습니다.
설정하고 플래그가 영향을 미치지 않는 것을 볼 수 있습니다.

파이썬 2.7.6
go 버전 go1.2.1 linux/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%
벤치 GO HTTP
8GiB 0:00:21 [ 385MiB/s] [================================>] 100%

파이썬 2.7.6
go 버전 go1.2.1 linux/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%
벤치 GO HTTP
8GiB 0:00:20 [ 391MiB/s] [================================>] 100%

파이썬 2.7.6
go 버전 go1.2.1 linux/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%
벤치 GO HTTP
8GiB 0:00:21 [ 389MiB/s] [================================>] 100%

이 수치는 매우 안정적이며 다음과 같은 기능을 보여줍니다.

1. 원시 소켓 읽기는 빠릅니다.
2. Go는 원시 소켓 읽기 속도의 약 80%입니다.
3. urllib3은 원시 소켓 읽기 속도의 약 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 | 20밀리초.com

2014년 12월 5일 금요일 오전 10:04 Cory Benfield 알림 @github.com
썼다:

좋아, 아래 데이터는 다른 작업을 수행하지 않는 기계에서 가져온 것입니다.
하지만 이러한 테스트를 실행합니다. 마지막 테스트는 Python -u 플래그로 실행되었습니다.
설정하고 플래그가 영향을 미치지 않는 것을 볼 수 있습니다.

파이썬 2.7.6
go 버전 go1.2.1 linux/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%
벤치 GO HTTP
8GiB 0:00:21 [ 385MiB/s] [================================>] 100%

파이썬 2.7.6
go 버전 go1.2.1 linux/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%
벤치 GO HTTP
8GiB 0:00:20 [ 391MiB/s] [================================>] 100%

파이썬 2.7.6
go 버전 go1.2.1 linux/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%
벤치 GO HTTP
8GiB 0:00:21 [ 389MiB/s] [================================>] 100%

이 수치는 매우 안정적이며 다음과 같은 기능을 보여줍니다.

1. 원시 소켓 읽기는 빠릅니다.
2. Go는 원시 소켓 읽기 속도의 약 80%입니다.
3. urllib3은 원시 소켓 읽기 속도의 약 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. 원시 소켓 읽기는 빠릅니다.
2. Go는 원시 소켓 읽기 속도의 약 80%입니다.
3. httplib는 원시 소켓 읽기 속도의 25% 미만입니다.
4. urllib3은 원시 소켓 읽기 속도의 약 20%이며 httplib에 약간의 오버헤드가 추가됩니다.
5. 요청은 urllib3보다 약간 느립니다. 이는 데이터가 통과할 몇 개의 스택 프레임을 추가하기 때문에 의미가 있습니다.

따라서 여기에서 실제 비용은 틀림없이 httplib입니다. 속도를 높이려면 httplib를 제거해야 합니다.

나는 httplib의 어떤 부분이 우리에게 비용을 발생시키는지 알아내고 싶습니다. bench_httplib.py 프로파일링하는 것이 좋은 다음 단계라고 생각합니다.

bench_socket.py 테스트에 해당 줄을 추가하여 socket.makefile 를 통해 소켓을 파일 개체로 변환하는 것을 배제했지만 전혀 속도가 느려지지 않았습니다. 이상하게도 속도가 빨라지는 것 같습니다.

대답은 거의 확실하게 전송 인코딩: 청크 처리입니다.
참조: https://github.com/alex/http-client-bench/pull/6 , 전환
서버의 Content-Length는 예기치 않은 결과를 생성합니다.

2014년 12월 5일 금요일 오후 12:24:53 Cory Benfield [email protected]
썼다:

따라서 여기에서 실제 비용은 틀림없이 httplib입니다. 이를 가속화하려면 다음이 필요합니다.
httplib를 방해하지 않도록 합니다.

나는 httplib의 어떤 부분이 우리에게 비용을 발생시키는지 알아내고 싶습니다. NS
bench_httplib.py를 프로파일링하는 것이 좋은 다음 단계라고 생각하십시오.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65831653
.

흥미로운.

청크 처리는 거의 확실히 문제이며, 특히 청크가 go의 기본 HTTP 모드이기 때문에 go가 더 잘 처리한다는 사실에 그다지 놀랍지 않습니다.

그러나 원시 소켓보다 빠른 요청은...예기치 않습니다!

주목할 가치가 있는 한 가지: 소켓이 이전 테스트에서 청크 인코딩을 디코딩하지 않았다면 실제로 다른 방법보다 더 적은 데이터를 읽기 때문에 불공정한 이점을 얻었습니다! 그들은 모두 청크 헤더와 8GB의 데이터를 읽고 있었습니다.

이것은 후속 질문으로 이어집니다. 우리는 여전히 이러한 모든 방법이 실제로 동일한 양의 데이터를 읽고 있다고 생각합니까?

예, 소켓 레이어가 부정 행위를 했고 청크된 메타데이터를 디코딩하지 않았습니다.
기술적으로 조금 덜 읽습니다. 그것은 "얼마나 빨리
우리가 읽을 수 있습니까?", 아무것도 증명하지 마십시오.

2014년 12월 5일 금요일 오후 12:33:10 Cory Benfield [email protected]
썼다:

흥미로운.

청크 처리는 거의 확실히 문제이며 나는 실제로
특히 청크가 기본값이므로 go가 더 잘 처리한다는 사실에 놀랐습니다.
이동을 위한 HTTP 모드.

그러나 원시 소켓보다 빠른 요청은...예기치 않습니다!

주목할 가치가 있는 한 가지: 소켓이 청크 인코딩을 디코딩하지 않는 경우
이전 테스트에서 실제로는 불공정한 이점을 얻었습니다.
다른 방법보다 적은 데이터를 읽습니다! 그들은 모두 읽고 있었다
청크 헤더와 8GB 데이터.

이것은 후속 질문으로 이어집니다. 우리는 여전히 이러한 모든 방법을 생각합니까?
실제로 같은 양의 데이터를 읽고 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65833299
.

이것이 우리가 한 번에 소켓에서 읽는 청크 크기와 관련이 있다고 해도 놀라지 않을 것입니다.

도움이 많이 된 @alex를 위한 케이크 :cake:

@nelhage 는 다양한 예제를 추적했습니다(전송에서
인코딩: 청크 케이스) https://gist.github.com/nelhage/dd6490fbc5cfb815f762
결과입니다. httplib에 버그가 있는 것 같습니다.
항상 소켓에서 전체 청크를 읽는 것은 아닙니다.

2014년 12월 8일 월요일 오전 9:05:14 Kenneth Reitz [email protected]
썼다:

@alex를 위한 케이크 https://github.com/alex 매우 도움이 되었습니다 [이미지:
:케이크:]

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2371#issuecomment -66147998
.

그래서 우리가 여기에 있는 것은 아무도 실제로 유지 관리하지 않는 표준 라이브러리의 버그입니까? ( @Lukasa 에는 1년 이상 열린 패치 세트가 2개 이상 있습니다.) 오늘 밤 어딘가에서 목록에 악취를 올릴 수도 있습니다.

누군가 (나는 그것을 얻을 수 있습니다, 불분명) 아마도 pdb로 드릴 다운해야 할 것입니다
또는 무언가를 만들고 정확한 코드가 20바이트를 생성하는지 알아내십시오.
좋은 버그 보고서를 작성할 수 있도록 읽습니다.

2014년 12월 8일 월요일 오전 9:14:09 Ian Cordasco [email protected]
썼다:

그래서 우리가 여기에 있는 것은 표준 라이브러리의 버그입니다.
유지? ( @Lukasa https://github.com/Lukasa 에는 최소 2개의 패치가 있습니다.
1년 이상 열린 세트
오늘 밤 어딘가

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kennethreitz/requests/issues/2371#issuecomment -66149522
.

오늘 밤이나 내일 아무도 안 오면 맞추도록 노력하겠습니다.

근본 원인에 대한 소식이 있습니까? 이 짧은 읽기를 생성하는 것은 무엇이며, 그것들이 없으면 상황이 얼마나 개선됩니까?

@kislyuk 내가 아는 한

@루카사 감사합니다. 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(명시적 길이)는 지정된 54바이트(다른 8192를 버퍼링하는 대신)에 대해 네트워크로 이동하도록 선택합니다.
• 그런 다음 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바이트 읽기와 관련하여 버퍼링된 소켓이 비어 있지 않음을 의미합니다.

이에 더하여. 작은 읽기가 처리량 손실의 주요 요인인지(또는 localhost가 아닌) 확실하지 않습니다. 나는 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도 해결해야 할 훌륭한 목표인 것 같습니다.

@ 알렉스 - 나는 당신이 언급 한 비 청크 성능 문제 요청에 대 urllib3으로 조금 주위 놀았다. 비슷한 요청이 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 가 본질적으로 작은 읽기를 방지하여 많은 비효율성을 해결하기를 바랍니다. io.BufferedReader 광범위하게 사용하기 때문에 Py3의 httplib 에 이 문제가 있는지 궁금합니다. 이는 BufferedSocket 와 거의 동일한 종류의 이점을 제공해야 하기 때문입니다.

그러나 hyper HTTP/1.1 기능을 유용하게 사용할 만큼 성장하면 이러한 다른 구현과 함께 벤치마킹하고 hyper 최대한 빨리 만들기 위해 노력해야 합니다.

거의 1년 동안 비활성 상태입니다. 폐쇄.

나는 10 배 덜 사용하여 requests 에 비해 urllib3 .

문제가 urllib3의 HTTPResponse 클래스 내에 있다고 생각합니다. iterator로 읽을 때 처리량은 정말 나쁩니다. 내 코드가 매우 추악한 해킹으로 작동하고 있습니다. urllib3에서 사용하는 밑줄이 그어진 httplib.HTTPResponse 개체를 반환하고 처리량 문제를 해결하는 것 같습니다.

흥미로운 사실: urllib3의 HTTPResponse 슈퍼클래스는 io.IOBase 입니다. Python3의 httplib.HTTPResponse 슈퍼클래스는 io.BufferedIOBase 입니다. 이와 관련이 있는지 궁금합니다.