की प्रतिक्रिया स्ट्रीम के लिए इष्टतम बफर आकार HttpWebResponse.GetResponseStream() से स्ट्रीम के साथ उपयोग करने के लिए इष्टतम बफर आकार क्या है?HttpWebResponse
ऑनलाइन उदाहरण 256b से 5 केबी तक भिन्न होते हैं। क्या देता है? मुझे लगता है कि बफर आकार परिस्थिति हो सकता है। यदि हां, तो किस प्रकार के बफर आकार का उपयोग करने की स्थितियां हैं?
धन्यवाद।
वास्तव में, इससे कोई फर्क नहीं पड़ता।
निश्चित रूप से, यदि आप वास्तव में छोटे बफर का उपयोग करते हैं, तो आपको बाइट्स प्राप्त करने के लिए परतों के माध्यम से कुछ अतिरिक्त कॉल करना पड़ सकता है (हालांकि धारा कम से कम कुछ बफरिंग कर रही है - मुझे नहीं पता कि यह क्या है डिफ़ॉल्ट हैं)। और निश्चित रूप से, यदि आप वास्तव में बड़े बफर का उपयोग करते हैं, तो आप कुछ स्मृति बर्बाद कर देंगे और कुछ विखंडन शुरू करेंगे। चूंकि आप स्पष्ट रूप से आईओ कर रहे हैं, जब भी आप बफर को ट्वीव करके लाभ प्राप्त करते हैं, तो आईओ समय पर प्रभुत्व हो रहा है।
एक सामान्य नियम के रूप में, मैं 2048 (2k) और 8192 (8k) के बीच दो की शक्ति के साथ जाता हूं। बस सुनिश्चित करें कि आप जानते हैं कि आप क्या कर रहे हैं यदि आप 85,000 बाइट्स के बराबर या उससे अधिक बफर के साथ जाते हैं (यह तब "large object" and subject to different GC rules है)।
वास्तव में, बफर आकार से अधिक महत्वपूर्ण यह है कि आप इसे कब तक रखते हैं। बड़ी वस्तु ढेर के बाहर वस्तुओं के लिए, जीसी बहुत कम जीवित वस्तुओं से निपटने में बहुत अच्छा है (जनरल 0 संग्रह तेजी से हैं), या बहुत लंबे समय तक जीवित वस्तुओं (जनरल 2)। ऑब्जेक्ट जो लाल होने से पहले जनरल 1 या 2 तक पहुंचने के लिए पर्याप्त समय तक जीवित रहते हैं, तुलनात्मक रूप से अधिक महंगा होते हैं, और आम तौर पर बफर कितना बड़ा होता है, इस बारे में चिंता करने के लिए आपके समय के बराबर अधिक मूल्यवान होता है।
एक अंतिम नोट: यदि आपको लगता है कि आपके द्वारा उपयोग किए जा रहे बफर के आकार के कारण आपके पास प्रदर्शन समस्या है, तो परीक्षण। यह असंभव है, लेकिन कौन जानता है, हो सकता है कि आपके पास ओएस संस्करण, नेटवर्क हार्डवेयर और ड्राइवर रिलीज का एक अजीब संगम हो, जिसमें कुछ आकार के बफर के साथ कुछ अजीब समस्या है।
मेरा अचूक अनुभव यह रहा है कि यह वास्तव में आप जो कर रहे हैं उस पर निर्भर करता है, लेकिन आमतौर पर 1024-4096 बाइट्स (दो की 1-4 केबी उर्फ पावर) की सीमा में कुछ भी मुझे तुलनीय प्रदर्शन प्रदान करेगा (4 केबी के साथ मैंने देखा "सर्वश्रेष्ठ" संख्या)।
असल में, आप एक बफर काफी बड़ा चाहते हैं ताकि आप स्ट्रीम से डेटा को अनावश्यक रूप से पढ़ न सकें, लेकिन इतना बड़ा नहीं कि आप रिटर्न कम कर दें। यदि आपका बफर बहुत बड़ा (~ एमबी) है, तो आप अपनी मेमोरी कैश मिस बढ़ाएंगे, जो वास्तव में आपके प्रदर्शन को कम करना शुरू कर सकता है। बेशक, यह वास्तविक एच/डब्ल्यू (बस गति, कैश आकार इत्यादि) के आधार पर बहुत भिन्न होता है, लेकिन मुझे लगता है कि 4 केबी बफर की तुलना में 4 एमबी बफर धीमा था (दोनों मामलों में लंबे जीवनकाल थे, इसलिए जीसी नहीं था एक मुद्दा)।
जोनाथन नोट्स के रूप में, समयपूर्व अनुकूलन का प्रयास करने से पहले अपने वर्तमान कार्यान्वयन का परीक्षण करें।
वास्तव में मुझे समस्या है जब बफर आकार बहुत छोटा होता है। मैंने इसका परीक्षण किया है और इसे सत्यापित किया है कि बफर आकार को छोटे मान के रूप में सेट नहीं किया जाना चाहिए। मेरे उदाहरण में मैंने इसे 2048 पर सेट किया है और डाउनलोड फ़ायरफ़ॉक्स की तुलना में बहुत धीमा हो रहा है (फ़ायरफ़ॉक्स एक डाउनलोड सेगमेंटेशन के बिना भी है, मेरे जैसा ही है)।
और इसे एक बड़े आकार के 409600 पर सेट करने के बाद, डाउनलोड बहुत तेज है, मुझे लगता है कि अतिरिक्त कॉल ओवरहेड खर्च करेगा या ऐसा डाउनलोड धीमा हो जाएगा। शायद नेटवर्क स्तर में, बफर आपके बफर आकार से अधिक है, इसलिए टीसीपी को फिर से पैकेज को फिर से भेजने की आवश्यकता है? (बस एक अनुमान है, क्योंकि मुझे नहीं पता कि टीसीपी कैसे काम करता है), हालांकि छोटे बफर आकार निश्चित रूप से मेरे डाउनलोड को धीमा कर रहा है। मैंने फ़ायरफ़ॉक्स डिफ़ॉल्ट डाउनलोड (बिना जोड़ने और segmenetation के) का उपयोग करके और मेरी कक्षा का उपयोग करके इसे चलाकर परीक्षण किया है, दोनों बहुत अलग हैं।
अब यह बहुत तेज़ है, हर बार जब यह लूप होता है, तो यह लगभग 200000 बाइट्स (200 केबी) पढ़ेगा क्योंकि कनेक्शन यहां तेजी से शांत है, लेकिन जब मैं दो थ्रेड चला रहा हूं, तो यह बहुत धीमा हो जाएगा, शायद इसे साझा करने की आवश्यकता है एक और धागा
एक बड़ी फ़ाइल (2 जीबी) अपलोड करने के मामले में मेरे साथ भी हुआ: बड़ा बफर इसे बहुत तेज बना दिया –
बहुत उपयोगी पोस्ट, लेकिन मुझे लगता है कि आपका मतलब 8192 था? 2 की शक्ति -> 2048, 40 9 6, 8192 (8 के)। – Derrick