requests 🚀 - अनुरोधों में खराब प्रदर्शन स्ट्रीमिंग बड़ी बाइनरी प्रतिक्रियाएं हैं

वह ओवरहेड अप्रत्याशित रूप से बड़ा है। हालांकि, इससे बचना मुश्किल हो सकता है।

बड़ी समस्या यह है कि हम प्रति खंड काफी प्रसंस्करण करते हैं। यह ढेर के नीचे है: अनुरोध, urllib3 और httplib। यह देखना बेहद दिलचस्प होगा कि अक्षमता का कारण कौन बना रहा है, इस पर काम करने के लिए समय कहां खर्च किया जा रहा है।

Lukasa 5 दिस॰ 2014

अनुमान लगाएं कि अगला कदम यह देखने के लिए httplib / urllib3 को प्रोफाइल करने का प्रयास करना होगा
वहां प्रदर्शन?

केविन बर्क
फोन: 925.271.7005 | ट्वेंटीमिलीसेकंड्स.कॉम
गुरु, 4 दिसंबर 2014 को शाम 5:01 बजे, कोरी बेनफील्ड नोटिफिकेशन @github.com
लिखा था:
वह ओवरहेड अप्रत्याशित रूप से बड़ा है। हालांकि, इससे बचना मुश्किल हो सकता है।
बड़ी समस्या यह है कि हम प्रति खंड काफी प्रसंस्करण करते हैं। वह है
ढेर के नीचे सभी तरह से: अनुरोध, urllib3 और httplib। यह होगा
यह देखने के लिए बेहद दिलचस्प है कि कौन काम करने के लिए समय व्यतीत कर रहा है
अक्षमता पैदा कर रहा है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65732050
.

kevinburke 5 दिस॰ 2014

urllib3 के साथ बस बेंचमार्क चलाया:

पीपीपी: 120 एमबी / एस
सीपीथॉन: 70MB/s

और मैंने CPython + अनुरोधों को फिर से चलाया: 35MB/s

(मेरी मशीन बेंचमार्क में बहुत कम शोर का अनुभव कर रही है, अगर किसी के पास एक शांत प्रणाली है तो वे इन पर कर सकते हैं, यह बहुत अच्छा होगा)

alex 5 दिस॰ 2014

मैंने हर दूसरे को बंद करने के बाद इन्हें अपनी मशीन पर चलाने की कोशिश की
एप्लिकेशन और टर्मिनल विंडो और साथ ही साथ उचित मात्रा में शोर मिला - the
सॉकेट बेंचमार्क 30mb/s से 460mb/s तक कहीं भी था।

केविन बर्क
फोन: 925.271.7005 | ट्वेंटीमिलीसेकंड्स.कॉम
गुरु, 4 दिसंबर 2014 को रात 9:24 बजे, एलेक्स गेन्नोर सूचनाएं @github.com
लिखा था:
urllib3 के साथ बस बेंचमार्क चलाया:
पीपीपी: 120 एमबी / एस
सीपीथॉन: 70MB/s
और मैंने CPython + अनुरोधों को फिर से चलाया: 35MB/s
(मेरी मशीन बेंचमार्क में बहुत कम शोर का अनुभव कर रही है, अगर
किसी के पास एक शांत प्रणाली है जिस पर वे ये कर सकते हैं, यह बहुत अच्छा होगा)
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65748982
.

kevinburke 5 दिस॰ 2014

मैंने बेंचमार्क को अब चलाना आसान बना दिया है, इसलिए अन्य लोग उम्मीद से मेरे नंबरों को सत्यापित कर सकते हैं:

सीपीथॉन:

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%

alex 5 दिस॰ 2014

उह ... वे नंबर अजीब हैं। CPython का httplib अनुरोध या urllib3 से धीमा है, भले ही दोनों पुस्तकालय httplib का उपयोग करते हैं? यह सही नहीं हो सकता।

Lukasa 5 दिस॰ 2014

वे मेरे लिए लगातार पुनरुत्पादन करते हैं -- क्या आप बेंचमार्क आज़मा सकते हैं और देख सकते हैं कि क्या
आप पुनरुत्पादन कर सकते हैं? यह मानते हुए कि आप कर सकते हैं, क्या आपको इसमें कुछ गलत दिखाई देता है
बेंचमार्क?

शुक्र पर दिसंबर 05 2014 11:16:45 कोरी Benfield पर [email protected]
लिखा था:

उह ... वे नंबर अजीब हैं। CPython का httplib अनुरोधों की तुलना में धीमा है या
urllib3, भले ही दोनों पुस्तकालय httplib का उपयोग करते हैं? यह सही नहीं हो सकता।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65821989
.

alex 5 दिस॰ 2014

मैं अभी एक ज्ञात-शांत मशीन को पकड़ रहा हूँ। उपलब्ध होने में कुछ मिनट लगने चाहिए क्योंकि यह एक भौतिक बॉक्स है जिसे स्थापित करना है (भगवान मैं MAAS से प्यार करता हूँ)।

Lukasa 5 दिस॰ 2014

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%

frewsxcv 5 दिस॰ 2014

हांलांकि इसकी कीमत के बारे निश्चित नहीं हूँ:

यह पैच , 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%

frewsxcv 5 दिस॰ 2014

आपको Python2 पर समान प्रभाव प्राप्त करने में सक्षम होना चाहिए
env PYTHONUNBUFFERED= या -u झंडा।

शुक्रवार 05 दिसंबर 2014 को 11:42:36 पूर्वाह्न पर कोरी फ़ारवेल नोटिफिकेशन @github.com
लिखा था:

हांलांकि इसकी कीमत के बारे निश्चित नहीं हूँ:
यह पैच 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%
बेंच जाओ HTTP
8GiB 0:00:31 [ 256MiB/s] [===========================>] 100%
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65826239
.

alex 5 दिस॰ 2014

@alex दिलचस्प है, न तो env PYTHONUNBUFFERED= या -u का Python 2 पर समान प्रभाव है। मेरी मशीन से आने वाले परिणाम।

Lukasa 5 दिस॰ 2014

ठीक है, नीचे दिया गया डेटा एक ऐसी मशीन से आता है जो इन परीक्षणों को चलाने के अलावा और कुछ नहीं कर रही है। अंतिम परीक्षण पायथन -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%

ये संख्याएँ अत्यंत स्थिर हैं, और निम्नलिखित विशेषताएं दर्शाती हैं:

रॉ सॉकेट रीड फास्ट (डुह) हैं।
गो एक रॉ सॉकेट रीड की गति का लगभग 80% है।
urllib3 कच्चे सॉकेट पढ़ने की गति का लगभग 20% है।
अनुरोध urllib3 की तुलना में थोड़ा धीमा है, जो समझ में आता है क्योंकि हम डेटा को पारित करने के लिए कुछ स्टैक फ्रेम जोड़ते हैं।
httplib अनुरोध/urllib3 से धीमा है। यह असंभव है, और मुझे संदेह है कि हमें httplib या सॉकेट लाइब्रेरी को इस तरह से कॉन्फ़िगर करना होगा कि httplib नहीं है।

Lukasa 5 दिस॰ 2014

एफडब्ल्यूआईडब्ल्यू, मैंने अभी @kevinburke से buffering=True जोड़कर विलय किया है, अपने रन करें
उसे शामिल करें?

शुक्रवार 05 दिसंबर 2014 को दोपहर 12:04:40 बजे कोरी बेनफील्ड नोटिफिकेशन @github.com
लिखा था:

ठीक है, नीचे दिया गया डेटा उस मशीन से आता है जो कुछ और नहीं कर रही है
लेकिन इन परीक्षणों को चला रहे हैं। अंतिम परीक्षण पायथन -यू ध्वज के साथ चलाया गया था
सेट, और जैसा कि आप देख सकते हैं कि ध्वज का कोई प्रभाव नहीं है।
पायथन 2.7.6
गो संस्करण 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%
बेंच जाओ HTTP
8GiB 0:00:21 [385MiB/s] [============================>] 100%
पायथन 2.7.6
गो संस्करण 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%
बेंच जाओ HTTP
8GiB 0:00:20 [ 391MiB/s] [===========================>] 100%
पायथन 2.7.6
गो संस्करण 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%
बेंच जाओ HTTP
8GiB 0:00:21 [ 389MiB/s] [============================>] 100%
ये संख्याएँ अत्यंत स्थिर हैं, और निम्नलिखित विशेषताएं दर्शाती हैं:
रॉ सॉकेट रीड फास्ट (डुह) हैं।
गो एक रॉ सॉकेट रीड की गति का लगभग 80% है।
urllib3 कच्चे सॉकेट पढ़ने की गति का लगभग 20% है।
अनुरोध urllib3 की तुलना में थोड़ा धीमा है, जो समझ में आता है जैसे हम
डेटा को पास करने के लिए कुछ स्टैक फ्रेम जोड़ें।
httplib अनुरोध/urllib3 से धीमा है। बस असंभव है,
और मुझे संदेह है कि हमें httplib या सॉकेट लाइब्रेरी को कॉन्फ़िगर करना होगा
एक तरीका है कि httplib नहीं है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65829335
.

alex 5 दिस॰ 2014

कोरी - बेंच क्लाइंट का नवीनतम संस्करण देखें जो चालू करता है
बफरिंग = httplib में सच (अनुरोध/urllib3 के रूप में)

केविन बर्क
फोन: 925.271.7005 | ट्वेंटीमिलीसेकंड्स.कॉम
शुक्र, 5 दिसंबर 2014 को सुबह 10:04 बजे, कोरी बेनफील्ड नोटिफिकेशन @github.com
लिखा था:
ठीक है, नीचे दिया गया डेटा उस मशीन से आता है जो कुछ और नहीं कर रही है
लेकिन इन परीक्षणों को चला रहे हैं। अंतिम परीक्षण पायथन -यू ध्वज के साथ चलाया गया था
सेट, और जैसा कि आप देख सकते हैं कि ध्वज का कोई प्रभाव नहीं है।
पायथन 2.7.6
गो संस्करण 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%
बेंच जाओ HTTP
8GiB 0:00:21 [385MiB/s] [============================>] 100%
पायथन 2.7.6
गो संस्करण 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%
बेंच जाओ HTTP
8GiB 0:00:20 [ 391MiB/s] [===========================>] 100%
पायथन 2.7.6
गो संस्करण 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%
बेंच जाओ HTTP
8GiB 0:00:21 [ 389MiB/s] [============================>] 100%
ये संख्याएँ अत्यंत स्थिर हैं, और निम्नलिखित विशेषताएं दर्शाती हैं:
रॉ सॉकेट रीड फास्ट (डुह) हैं।
गो एक रॉ सॉकेट रीड की गति का लगभग 80% है।
urllib3 कच्चे सॉकेट पढ़ने की गति का लगभग 20% है।
अनुरोध urllib3 की तुलना में थोड़ा धीमा है, जो समझ में आता है जैसे हम
डेटा को पास करने के लिए कुछ स्टैक फ्रेम जोड़ें।
httplib अनुरोध/urllib3 से धीमा है। बस असंभव है,
और मुझे संदेह है कि हमें httplib या सॉकेट लाइब्रेरी को कॉन्फ़िगर करना होगा
एक तरीका है कि httplib नहीं है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65829335
.

kevinburke 5 दिस॰ 2014

हाँ, यह 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%

रॉ सॉकेट रीड फास्ट (डुह) हैं।
गो एक रॉ सॉकेट रीड की गति का लगभग 80% है।
httplib कच्चे सॉकेट पढ़ने की गति से केवल 25% से कम है।
urllib3 कच्चे सॉकेट पढ़ने की गति का लगभग 20% है, httplib में कुछ छोटे ओवरहेड जोड़ रहा है।
अनुरोध urllib3 की तुलना में थोड़ा धीमा है, जो समझ में आता है क्योंकि हम डेटा को पारित करने के लिए कुछ स्टैक फ्रेम जोड़ते हैं।

Lukasa 5 दिस॰ 2014

तो, यकीनन यहां वास्तविक लागत httplib है। इसे तेज करने के लिए httplib को रास्ते से हटाने की आवश्यकता है।

मुझे यह जानने में दिलचस्पी है कि httplib का कौन सा हिस्सा हमें खर्च कर रहा है। मुझे लगता है कि प्रोफाइलिंग bench_httplib.py एक अच्छा अगला कदम है।

Lukasa 5 दिस॰ 2014

मैंने उस लाइन को bench_socket.py परीक्षण में जोड़कर socket.makefile माध्यम से फ़ाइल ऑब्जेक्ट में सॉकेट के रूपांतरण को खारिज कर दिया है, जो इसे बिल्कुल धीमा नहीं करता है। अजीब तरह से, ऐसा लगता है कि यह तेज़ हो गया है।

Lukasa 5 दिस॰ 2014

उत्तर लगभग निश्चित रूप से स्थानांतरण-एन्कोडिंग है: खंडित हैंडलिंग।
देखें: https://github.com/alex/http-client-bench/pull/6 , पर स्विच करना
सर्वर पर सामग्री-लंबाई कुछ अप्रत्याशित परिणाम उत्पन्न करती है।

शुक्रवार 05 दिसंबर 2014 को दोपहर 12:24:53 बजे कोरी बेनफील्ड नोटिफिकेशन @github.com
लिखा था:

तो, यकीनन यहां वास्तविक लागत httplib है। इसे तेज करने की आवश्यकता है
रास्ते से httplib प्राप्त करना।
मुझे यह जानने में दिलचस्पी है कि httplib का कौन सा हिस्सा हमें खर्च कर रहा है। मैं
लगता है कि प्रोफाइलिंग बेंच_httplib.py एक अच्छा अगला कदम है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65831653
.

alex 5 दिस॰ 2014

दिलचस्प।

खंडित हैंडलिंग लगभग निश्चित रूप से समस्या है, और मुझे वास्तव में आश्चर्य नहीं है कि गो इसे बेहतर तरीके से संभालता है, विशेष रूप से चंक के रूप में जाने के लिए डिफ़ॉल्ट HTTP मोड है।

हालांकि, कच्चे सॉकेट की तुलना में तेजी से अनुरोध किया जा रहा है...अप्रत्याशित!

एक बात ध्यान देने योग्य है: यदि सॉकेट पिछले परीक्षणों में खंडित एन्कोडिंग को डिकोड नहीं कर रहा था, तो उसे एक अनुचित लाभ मिला, क्योंकि यह वास्तव में अन्य तरीकों की तुलना में कम डेटा पढ़ रहा था! वे सभी खंडित हेडर और साथ ही 8GB डेटा पढ़ रहे थे।

यह एक अनुवर्ती प्रश्न की ओर ले जाता है: क्या हमें अभी भी लगता है कि ये सभी विधियां वास्तव में समान मात्रा में डेटा पढ़ रही हैं?

Lukasa 5 दिस॰ 2014

हां, सॉकेट परत धोखा दे रही थी, इसने खंडित मेटाडेटा को डीकोड नहीं किया,
और तकनीकी रूप से थोड़ा कम पढ़ें। यह "कितनी तेजी से" के लिए एक आधार रेखा के रूप में था
क्या हम पढ़ सकते हैं", कुछ साबित करने के लिए नहीं।

शुक्रवार 05 दिसंबर 2014 को दोपहर 12:33:10 बजे कोरी बेनफील्ड नोटिफिकेशन @github.com
लिखा था:

दिलचस्प।
खंडित हैंडलिंग लगभग निश्चित रूप से समस्या है, और मैं वास्तव में नहीं हूं
आश्चर्य है कि go इसे बेहतर तरीके से संभालता है, विशेष रूप से चंकड डिफ़ॉल्ट है
जाने के लिए HTTP मोड।
हालांकि, कच्चे सॉकेट की तुलना में तेजी से अनुरोध किया जा रहा है...अप्रत्याशित!
एक बात ध्यान देने योग्य है: यदि सॉकेट खंडित एन्कोडिंग को डिकोड नहीं कर रहा था
पिछले परीक्षणों में तो इसे अनुचित लाभ मिला, क्योंकि यह वास्तव में था
अन्य तरीकों की तुलना में कम डेटा पढ़ रहे थे! वे सब पढ़ रहे थे
खंडित हेडर के साथ-साथ 8GB डेटा।
यह एक अनुवर्ती प्रश्न की ओर ले जाता है: क्या हम अभी भी इन सभी विधियों के बारे में सोचते हैं
क्या वास्तव में समान मात्रा में डेटा पढ़ रहे हैं?
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -65833299
.

alex 5 दिस॰ 2014

मुझे आश्चर्य नहीं होगा अगर यह उस खंड आकार से संबंधित है जिसे हम एक समय में सॉकेट से पढ़ रहे हैं।

kennethreitz42 8 दिस॰ 2014

सुपर सहायक होने के लिए @alex के लिए केक: केक:

kennethreitz42 8 दिस॰ 2014

@nelhage ने विभिन्न उदाहरणों की कुछ स्ट्रेसिंग की (स्थानांतरण में)
एन्कोडिंग: खंडित मामला) https://gist.github.com/nelhage/dd6490fbc5cfb815f762
परिणाम हैं। ऐसा लगता है कि httplib में एक बग है जिसके परिणामस्वरूप यह होता है
हमेशा सॉकेट से पूरा हिस्सा नहीं पढ़ना।

सोम दिसंबर 08 2014 को 9:05:14 पूर्वाह्न पर केनेथ रिट्ज नोटिफिकेशन @github.com
लिखा था:

सुपर सहायक होने के लिए @alex https://github.com/alex के लिए केक [छवि:
:केक:]
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -66147998
.

alex 8 दिस॰ 2014

तो हमारे पास यहां एक मानक पुस्तकालय में एक बग है जिसे कोई भी वास्तव में बनाए नहीं रख रहा है? ( @ लुकासा में कम से कम 2 पैच सेट हैं जो> 1 साल के लिए खुले हैं।) शायद मैं आज रात कहीं सूची में एक बदबू

sigmavirus24 8 दिस॰ 2014

किसी को (मैं इसे प्राप्त कर सकता हूं, अस्पष्ट) शायद पीडीबी के साथ ड्रिल करने की जरूरत है
या कुछ और पता करें कि कौन सा सटीक कोड उन 20-बाइट को उत्पन्न कर रहा है
पढ़ता है ताकि हम एक अच्छी बग रिपोर्ट तैयार कर सकें।

सोम दिसंबर 08 2014 को 9:14:09 पूर्वाह्न पर इयान कॉर्डास्को नोटिफिकेशन @github.com
लिखा था:

तो हमारे पास यहां एक मानक पुस्तकालय में एक बग है जो वास्तव में कोई नहीं है
को बनाए रखने? ( @ लुकासा https://github.com/Lukasa में कम से कम 2 पैच हैं
सेट जो >1 साल से खुले हैं।) हो सकता है कि मैं एक सूची में एक बदबू उठाऊंगा
कहीं आज रात
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/2371#issuecomment -66149522
.

alex 8 दिस॰ 2014

मैं इसे आज रात या कल में फिट करने की कोशिश करूंगा यदि कोई और नहीं मिलता है।

sigmavirus24 8 दिस॰ 2014

तो, मूल कारण पर कोई खबर? इन लघु पठन को क्या उत्पन्न कर रहा है, और उनके बिना स्थिति में कितना सुधार होता है?

kislyuk 19 दिस॰ 2014

@kislyuk जहाँ तक मुझे जानकारी नहीं है। उम्मीद है कि मेरे पास इस क्रिसमस की छुट्टी का पीछा करने के लिए कुछ समय होगा।

Lukasa 20 दिस॰ 2014

धन्यवाद @ लुकासा। मैं एक प्रदर्शन समस्या से निपट रहा हूं जहां urllib3/अनुरोधों का उपयोग करके एक खंडित प्रतिक्रिया पर डाउनलोड गति कर्ल और अन्य पुस्तकालयों की तुलना में बहुत धीमी है, और यह समझने की कोशिश कर रही है कि यह अपराधी है या नहीं।

kislyuk 22 दिस॰ 2014

मैं इसके साथ थोड़ा घूम रहा था। संक्षिप्त पाठ httplib . में _read_chunked functon से आते हैं

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

2 बाइट पढ़ता है मुख्य रूप से लाइन 622 से लगता है।

मुझे पहले पोस्ट किए गए एक से थोड़ा अलग स्ट्रेस पैटर्न मिला:
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"..., 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"..., 54, 0, न्यूल, न्यूल) = 54
recvfrom(3, "\r\n", 2, 0, NULL, NULL) = 2

इस पैटर्न को इस प्रकार समझाया जा सकता है:

self.fp.readline (पंक्ति 591) 8192 बाइट्स (सॉकेट.रीडलाइन में) के लिए बफर्ड रीड को ट्रिगर करता है
उपभोग किया जाने वाला प्रत्येक खंड 1031 बाइट्स (5 बाइट खंड लंबाई ("400\r\n") + 1024 बाइट डेटा + टर्मिनेटर के 2 बाइट्स)
हम बफ़र किए गए 8192 बाइट्स में से 7 ऐसे विखंडू का उपभोग कर सकते हैं जो हमें 975 बाइट्स के साथ छोड़ देता है
फिर हम अगली खंड लंबाई (5 बाइट्स) पढ़ते हैं जो 970 बाइट्स के साथ निकलती है
अब हमारे पास केवल 970 बाइट्स हैं जो वर्तमान चंक (1024) को पूरा करने के लिए अपर्याप्त हैं इसलिए हम 54 बाइट्स की कमी के लिए नेटवर्क पर वापस जाते हैं
इसे पूरा करने के लिए httplib बकाया बाइट्स पर एक sock.read(54) करता है। इस मामले में socket.read (एक स्पष्ट लंबाई के साथ) निर्दिष्ट 54 बाइट्स के लिए नेटवर्क पर जाने का विकल्प चुनेंगे (अन्य 8192 को बफर करने के बजाय)
फिर हमें चंक टर्मिनेटर पढ़ने को मिलता है जो 2 बाइट्स है और फिर से ऊपर जैसा ही परिदृश्य है

फिर पैटर्न दोहराएगा (चरण 1 पर वापस जाएं)

एफडब्ल्यूआईडब्ल्यू, मैंने पाया कि 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 बाइट पढ़ने की बात आती है तो बफर सॉकेट खाली नहीं होगा।

gardenia 7 मार्च 2015

इससे आगे। मुझे यकीन नहीं है कि छोटे पठन थ्रूपुट के नुकसान में मुख्य कारक हैं (या स्थानीयहोस्ट पर नहीं)। मैंने सॉकेट बफर आकार के साथ खेला जैसे कि यह 1031 बाइट्स का एक गुणक था और स्ट्रेस के अब छोटे पढ़ने के बावजूद इसका थ्रूपुट पर अधिक प्रभाव नहीं पड़ा।

मुझे लगता है कि थ्रूपुट का नुकसान अधिक हो सकता है कि कैसे socket.py छोटे पढ़ने के साथ व्यवहार करता है। यहां प्रासंगिक कोड है (सॉकेट से। पढ़ें):

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

जब आप एक स्पष्ट लंबाई को सॉकेट में पास करते हैं। पढ़ें और इसे मौजूदा बफर किए गए डेटा से पूरा किया जा सकता है तो यह कोड पथ है:

        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 बाइट पढ़ने का मतलब अपठित शेष को एक ताजा स्ट्रिंगियो में कॉपी करना है। ऐसा लगता है कि बहुत से छोटे-छोटे पठन के लिए यह बहुत महंगा हो जाएगा। यदि किसी दिए गए स्ट्रिंगियो को अपठित शेष को ताजा स्ट्रिंगियो में कॉपी करने के मौजूदा पैटर्न के बजाय प्रत्येक पढ़ने पर किसी भी तरह से निकाला जा सकता है तो मुझे उम्मीद है कि इससे थ्रूपुट में मदद मिल सकती है

gardenia 7 मार्च 2015

@gardenia मुझे यह सब अवशोषित करने का मौका नहीं मिला है, लेकिन आपके प्रयास और यहां काम करने के लिए बहुत-बहुत धन्यवाद। @shazow शायद आपको @gardenia का शोध दिलचस्प लगेगा।

sigmavirus24 7 मार्च 2015

: +1: धन्यवाद @gardenia। संयोग से, मेरे उपयोग के मामले में प्रदर्शन में मेरे अपने शोध ने खुलासा किया कि मेरे मामले में प्रतिक्रियाओं को खंडित नहीं किया गया है, लेकिन urllib3 अनुरोधों की तुलना में 20+% तेज प्रदर्शन करता है, इसलिए कुछ ओवरहेड पेश किया जा रहा है जिसे मैं विशेषता देना चाहता हूं। अभी भी इस मुद्दे के शीर्षक के अनुरूप है, लेकिन मूल कारण अलग है।

kislyuk 7 मार्च 2015

आकर्षक, साझा करने के लिए धन्यवाद! :)

@Lukasa के हाइपर को संबोधित करने के लिए भी एक महान लक्ष्य की तरह लगता है।

shazow 7 मार्च 2015

@alex - मैंने urllib3 बनाम आपके द्वारा उल्लिखित गैर-खंडित प्रदर्शन समस्या के अनुरोधों के साथ थोड़ा सा खिलौना किया। मुझे लगता है कि मुझे अनुरोधों में समान 20% की गिरावट दिखाई दे रही है।

अनुरोधों में मैंने स्ट्रीम() (urllib3 से) के इनलाइन कार्यान्वयन के साथ कॉल को self.raw.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 पर कॉल इनकैप्सुलेशन बस्टिंग है, यह एक गंभीर पैच के रूप में सिर्फ एक डेटा बिंदु के रूप में नहीं है)

gardenia 7 मार्च 2015

@shazow यह मेरी आशा है कि हाइपर का उपयोग करने वाले BufferedSocket को अनिवार्य रूप से छोटे पढ़ने को रोककर, उस अक्षमता को बहुत कुछ संबोधित करना चाहिए। मुझे आश्चर्य है कि अगर Py3 पर httplib में यह समस्या है, क्योंकि यह बड़े पैमाने पर io.BufferedReader का उपयोग करता है, जिसे मोटे तौर पर BufferedSocket के समान लाभ प्रदान करना चाहिए।

निश्चित रूप से, हालांकि, जब hyper उपयोगी होने के लिए पर्याप्त HTTP/1.1 कार्यक्षमता बढ़ाता है, तो हमें इन अन्य कार्यान्वयनों के साथ इसे बेंचमार्क करने का प्रयास करना चाहिए और जितनी जल्दी हो सके hyper बनाने का प्रयास करना चाहिए।

Lukasa 7 मार्च 2015

करीब एक साल से निष्क्रिय है। समापन।

sigmavirus24 16 अप्रैल 2016

👎4

मैं इसी तरह के मुद्दों दिखाई दे रही है, 10x कम का उपयोग कर requests के साथ तुलना में urllib3 ।

c4milo 9 जन॰ 2018

मुझे लगता है कि यह मुद्दा urllib3 के HTTPResponse वर्ग के भीतर रहता है, जब इसे एक पुनरावर्तक के रूप में पढ़ा जाता है, तो इसका थ्रूपुट वास्तव में खराब होता है। मुझे अपना कोड बहुत बदसूरत हैक के साथ काम कर रहा है: मैं urllib3 द्वारा उपयोग किए गए रेखांकित httplib.HTTPResponse ऑब्जेक्ट को वापस कर देता हूं और ऐसा लगता है कि मेरी थ्रूपुट समस्या ठीक हो गई है।

दिलचस्प तथ्य: urllib3 का HTTPResponse सुपरक्लास io.IOBase । Python3 का httplib.HTTPResponse सुपरक्लास io.BufferedIOBase । मुझे आश्चर्य है कि इसका इससे कोई लेना-देना है या नहीं।

c4milo 10 जन॰ 2018

<p>अनुरोधों में खराब प्रदर्शन स्ट्रीमिंग बड़ी बाइनरी प्रतिक्रियाएं हैं</p>

सभी 40 टिप्पणियाँ

संबंधित मुद्दों