मैं उन प्रदर्शन संख्याओं को समझने की कोशिश कर रहा हूं जो मुझे मिल रहा है और थ्रेड की इष्टतम संख्या निर्धारित करने के लिए कैसे।टीसीपी, HTTP और मल्टी-थ्रेडिंग स्वीट स्पॉट
मैं पर्ल जो एक पेज डाउनलोड करता है में एक प्रायोगिक मल्टी-थ्रेडेड वेब ग्राहक लिखा था अपने परिणाम के लिए इस पोस्ट के नीचे देखो, पकड़ लेता है प्रत्येक छवि टैग के लिए स्रोत और छवि को डाउनलोड करता है - त्यागकर डेटा।
यह 10 सेकंड के प्रारंभिक प्रति फ़ाइल टाइमआउट के साथ एक गैर-अवरुद्ध कनेक्ट का उपयोग करता है जो प्रत्येक टाइमआउट के बाद युगल होता है और पुनः प्रयास करता है। यह आईपी पते को भी कैश करता है ताकि प्रत्येक थ्रेड को केवल एक बार DNS लुकअप करना पड़े।
डाउनलोड किए गए आंकड़ों की कुल राशि 1316 फाइलों में 2271122 बाइट्स है जो http://hubblesite.org/gallery/album/entire/npp/all/hires/true/ से 2.5 एमबी कनेक्शन के माध्यम से है। थंबनेल छवियों को एक कंपनी द्वारा होस्ट किया जाता है जो उच्च बैंडविड्थ अनुप्रयोगों के लिए कम विलंबता में विशेषज्ञ होने का दावा करता है।
दीवार समय है:
1 थ्रेड 04:48 लेता है - 0 समय समाप्ति
2 धागे लेता है 02:38 - 20 समय समाप्ति
- 0 समय समाप्ति
5 धागे 02:22 लेता है 40 समय समाप्ति
50 धागे 02:27 ले - - 10 धागे 02:27 ले 170 समय समाप्ति
सबसे खराब स्थिति में (50 धागे) CPU समय के कम से कम 2 सेकंड खपत होती है ख वाई ग्राहक।
औसत फ़ाइल आकार 1.7k
औसत RTT 100 एमएस (के रूप में पिंग द्वारा मापा गया)
औसत CLI CPU/img 1 एमएस
सबसे तेजी से औसत डाउनलोड गति के बारे में 15 केबी/सेक समग्र पर 5 सूत्र है।
0 CLI syn
भेजता है:
सर्वर वास्तव में के रूप में यह जिसका अर्थ यह प्रत्येक अनुरोध पर कार्रवाई करने के लिए सर्वर के लिए औसतन केवल 18 एमएस लेता है प्रत्येक छवि प्राप्त करने का एकमात्र 218 एमएस लेता है सुंदर कम विलंबता है लगता है 50 SRV rcvs syn
50 SRV भेजता syn + पावती
100 CLI स्थापित Conn/CLI प्राप्त भेजता
150 SRV recv के मिल
168 SRV फ़ाइल पढ़ता है, डेटा भेजता है, करीब
218 CLI recv HTTP हेडर + पूरी फाइल कॉल 2 segme में एनटीएस एमएसएस == 1448
मैं देख सकता हूं कि प्रति फ़ाइल औसत डाउनलोड गति कम फ़ाइल आकार और कनेक्शन सेटअप की अपेक्षाकृत उच्च लागत की वजह से कम है।
जो मुझे समझ में नहीं आता है, यही कारण है कि मैं 2 धागे से अधिक प्रदर्शन में वास्तव में कोई सुधार नहीं देखता हूं। सर्वर पर्याप्त तेज़ प्रतीत होता है, लेकिन पहले से ही 5 धागे पर कनेक्शन समाप्त कर देता है।
टाइमआउट लगभग 900-1000 सफल कनेक्शन के बाद शुरू होने लगते हैं चाहे यह 5 या 50 धागे हो, जो मुझे लगता है कि सर्वर पर शायद कुछ प्रकार की थ्रॉटलिंग थ्रेसहोल्ड है, लेकिन मुझे उम्मीद है कि 10 धागे अभी भी 2 से काफी तेज होंगे
क्या मुझे यहां कुछ याद आ रही है?
संपादित-1
बस तुलना खातिर मैं DownThemAll Firefox विस्तार स्थापित किया है और इसे का उपयोग छवियों को डाउनलोड। मैंने इसे 10 सेकंड टाइमआउट के साथ 4 एक साथ कनेक्शन पर सेट किया। डीटीएम ने सभी फाइलों को डाउनलोड करने में लगभग 3 मिनट लग गए + उन्हें डिस्क पर लिखें, और लगभग 900 कनेक्शन के बाद टाइमआउट का अनुभव करना शुरू हो गया।
मैं टीसीपीडम्प चलाने के लिए टीसीपीडम्प चलाने जा रहा हूं और टीसीपी प्रोटोकॉल स्तर पर क्या हो रहा है, इसकी एक बेहतर तस्वीर प्राप्त करने जा रहा हूं।
मैंने फ़ायरफ़ॉक्स के कैश को भी साफ़ किया और पुनः लोड किया। पृष्ठ और सभी छवियों को फिर से लोड करने के लिए 40 सेकेंड। यह बहुत तेज़ तरीका लग रहा था - शायद फ़ायरफ़ॉक्स ने उन्हें स्मृति कैश में रखा था जिसे साफ़ नहीं किया गया था? तो मैंने ओपेरा खोला और इसमें लगभग 40 सेकंड लग गए। मुझे लगता है कि वे इतने तेज हैं क्योंकि वे HTTP/1.1 पाइपलाइनिंग का उपयोग कर रहे हैं?
और उत्तर है !??
तो पाइपलाइनिंग के माध्यम से सॉकेट का पुन: उपयोग करने के लिए थोड़ा और परीक्षण और लेखन कोड के बाद मुझे कुछ रोचक जानकारी मिली।
5 धागे पर चलते समय गैर-पाइपलाइन संस्करण 77 सेकंड में पहली 1026 छवियों को पुनर्प्राप्त करता है लेकिन शेष 2 9 0 छवियों को पुनर्प्राप्त करने के लिए और 65 सेकंड लेता है। यह MattH's सिद्धांत है जो मेरे क्लाइंट को SYN FLOOD ईवेंट द्वारा हिट करने के बारे में बताता है जिससे सर्वर थोड़े समय के लिए मेरे कनेक्शन प्रयासों का जवाब देना बंद कर देता है। हालांकि, यह समस्या का केवल एक हिस्सा है क्योंकि 10 सेकंड छवियों को प्राप्त करने के लिए 5 सेकंड के लिए 77 सेकंड अभी भी बहुत धीमी है; यदि आप SYN FLOOD समस्या को हटाते हैं तो भी सभी फ़ाइलों को पुनर्प्राप्त करने में लगभग 99 सेकंड लगेंगे। तो थोड़ा सा शोध और कुछ tcpdump के आधार पर ऐसा लगता है कि इस मुद्दे के दूसरे भाग में विलम्ब और कनेक्शन सेटअप ओवरहेड है।
यहां वह जगह है जहां हम "मीठे स्पॉट" या थ्रेड की इष्टतम संख्या खोजने के मुद्दे पर वापस आते हैं। मैं ग्राहक संशोधित HTTP/1.1 पाइपलाइनिंग लागू करने के लिए और पाया कि इस मामले में धागे की इष्टतम संख्या 15 और 20 के बीच है कि उदाहरण के लिए:
1 थ्रेड लेता है 02:37 - 0 समय समाप्ति
2 धागे लेता है 01:22 - 0 समय समाप्ति
5 धागे लेता है 00:34 - 0 समय समाप्ति
11 धागे 00:19 ले - - 0 समय समाप्ति
10 धागे 00:20 ले 0 समय समाप्ति
15 धागे 0 ले : 16 - 0 टाइमआउट
चार कारक हैं जो इस पर असर डालते हैं; विलंबता/आरटीटी, अधिकतम अंत-टू-एंड बैंडविड्थ, आरईवी बफर आकार और छवि फ़ाइलों का आकार डाउनलोड किया जा रहा है। See this site for a discussion on how receive buffer size and RTT latency affect available bandwidth।
उपर्युक्त के अतिरिक्त, औसत फ़ाइल आकार अधिकतम प्रति कनेक्शन स्थानांतरण दर को प्रभावित करता है।हर बार जब आप एक जीईटी अनुरोध जारी करते हैं तो आप में एक खाली अंतर बनाते हैं जो आपके स्थानांतरण पाइप कनेक्शन कनेक्शन आरटीटी का आकार है। उदाहरण के लिए, यदि आप अधिकतम संभावित स्थानांतरण दर (रिकव बफ आकार/आरटीटी) 2.5 एमबी और हैं तो आपका आरटीटी 100 एमएमएस है, तो प्रत्येक जीईटी अनुरोध आपके पाइप में न्यूनतम 32 केबी अंतर होता है। 320kB की एक बड़ी औसत छवि आकार के लिए जो 10% ओवरहेड प्रति फ़ाइल है, प्रभावी रूप से आपकी उपलब्ध बैंडविड्थ को 2.25 एमबीटी तक कम कर देता है। हालांकि, 3.2kb के छोटे औसत फ़ाइल आकार के लिए ओवरहेड कूदता है 1000% और उपलब्ध बैंडविड्थ 232 केबीटी/सेकेंड तक कम हो जाता है - लगभग 2 9 केबी।
गैप आकार = MPTR * RTT
:
MPTR/(MPTR/गैप आकार + औसत फ़ाइल आकार) * औसत फ़ाइल आकार)तो धागे के इष्टतम संख्या को खोजने के लिए
मेरे उपरोक्त परिदृश्य के लिए यह मुझे 11 धागे की इष्टतम थ्रेड गिनती देता है, जो मेरे असली दुनिया के परिणामों के बहुत करीब है।
यदि वास्तविक कनेक्शन गति सैद्धांतिक एमपीटीआर की तुलना में धीमी है तो इसके बजाय गणना में उपयोग किया जाना चाहिए।
क्या आप सुनिश्चित हैं कि आपका ग्राहक स्वयं को दो समवर्ती HTTP सत्रों तक सीमित नहीं कर रहा है (ग्राहक # 3 को समाप्त करने के लिए ग्राहक # 3/# 2 का इंतजार कर रहा है)? यह सब कुछ है, कुछ HTTP आरएफसी ग्राहकों को सुझाव देता है * करना चाहिए *। और यदि नहीं, तो क्या आप सुनिश्चित हैं कि * सर्वर * (या रास्ते में कुछ) ऐसा नहीं करता है? अर्थात। क्या आप अपने सत्रों की एक साथ पुष्टि कर सकते हैं? – bzlm
@bzlm: मैंने क्लाइंट को स्क्रैच से लिखा है, मैं किसी भी पुस्तकालय का उपयोग नहीं करता हूं। इसलिए मैं 100% के करीब हूं यकीन है कि कनेक्शन क्लाइंट साइड से समवर्ती हैं। मुझे लगता है कि जब मैं सर्वर से SYN को पुन: प्राप्त करता हूं तो मैं यह देखने के लिए tcpdump सकता हूं हालांकि मुझे नहीं पता कि यह पर्याप्त है या नहीं। –
@ हॉब्स: पर्ल थ्रेडिंग कैसे गलती हो सकती है?प्रक्रिया के लिए कुल सीपीयू समय 2 सेकंड से कम है। –