2009-11-25 13 views
16

रिचकॉपी, माइक्रोसॉफ्ट से बेहतर-से-रोबोकॉपी-जीयूआई उपकरण, फ़ाइलों की प्रतिलिपि बनाने के लिए पसंद का वर्तमान टूल प्रतीत होता है। TechNet article presenting the tool में हाइटलाइट की गई मुख्य विशेषताएं में से एक यह है कि यह समानांतर में एकाधिक फ़ाइलों की प्रतिलिपि बनाता है। अपनी डिफ़ॉल्ट सेटिंग में, तीन फाइलों को एक साथ कॉपी किया जाता है, जिसे आप अच्छी तरह से जीयूआई में देख सकते हैं: [प्रगति: फ़ाइल ए का एक्सएक्स%, फ़ाइल बी का वाई%, ...]। इस उपकरण की प्रशंसा करने और दावा करने की प्रक्रिया को गति देने के लिए बहुत सारे blogentries हैं और दावा करते हैं कि यह प्रतिलिपि प्रक्रिया को गति देता है।मल्टीथ्रेड फ़ाइल स्थानांतरण प्रदर्शन में सुधार क्यों करता है?

मेरा प्रश्न है: यह तकनीक प्रदर्शन में सुधार क्यों करती है? जहां तक ​​मुझे पता है, आधुनिक कंप्यूटर सिस्टम पर फ़ाइलों की प्रतिलिपि करते समय, एचडीडी बाधा है, सीपीयू या नेटवर्क नहीं। मेरी धारणा यह होगी कि एक साथ कई फाइलों की प्रतिलिपि बनाने से पूरी प्रक्रिया धीमी बन जाती है, क्योंकि एचडीडी को अनुक्रमिक रूप से एक फ़ाइल स्ट्रीम करने की बजाय विभिन्न फ़ाइलों के बीच आगे और आगे कूदने की आवश्यकता होती है। चूंकि रिचकॉपी तेज है, मेरी धारणाओं में कुछ गलती होनी चाहिए ...

+7

पीएस: मैंने लंबे समय से सोचा है कि क्या स्टैक ओवरफ्लो (यह एक प्रोग्रामिंग तकनीक के बारे में है) या सुपरयूसर (यह एक उपकरण का उपयोग करने के बारे में है) इसके लिए सही जगह है। मैंने स्टैक ओवरफ्लो पर निर्णय लिया है, क्योंकि मुझे उपकरण के डिजाइन निर्णयों में दिलचस्पी है, न कि इसके उपयोग में। – Heinzi

+0

याद रखें कि बहुत अधिक बैंडविड्थ लिंक (गीगाबिट +) पर भी, विलंबता शून्य से अधिक है – MarkR

उत्तर

9

उपकरण हार्डवेयर में उपयोग सुधार कर रहा है जो एकाधिक पढ़ने और लिखने के अनुरोधों को बेहतर ढंग से अनुकूलित कर सकता है।

जब एक समय हार्डवेयर के बाद से सॉफ्टवेयर नहीं है पता चला है कि डेटा के ब्लॉक है कि वर्तमान में (या निकट) पढ़ा सिर के नीचे गुजर रहा है एक subsquent पढ़ने की आवश्यकता होगी नहीं जा रहा है में एक फ़ाइल को कॉपी उस अनुरोध को अभी तक कतारबद्ध किया गया है।

इन दिनों एक फ़ाइल प्रतिलिपि आधुनिक डिस्क सब-सिस्टम के लिए बहुत कर कार्य नहीं है। इन हार्डवेयर प्रणालियों को एक बार करने के लिए और अधिक काम करने के बाद उपकरण अपनी बेहतर अनुकूलन सुविधाओं का लाभ उठा रहा है।

1

मेरे gues यह है कि एचडीडी पढ़ना लिखने वाले सिर अपने अधिकांश समय निष्क्रिय रहते हैं और डिस्क के सही मेमोरी ब्लॉक को उनके नीचे छोड़ने की प्रतीक्षा करते हैं, अधिक स्मृति की प्रतिलिपि बनाई जाती है, निष्क्रिय होने में कम समय और अधिकांश आधुनिक डिस्क शेड्यूलर कूदने की देखभाल करें (फाइलों/टुकड़ों की कम संख्या के लिए)

1

जहां तक ​​मुझे पता है, आधुनिक कंप्यूटर सिस्टम पर फ़ाइलों की प्रतिलिपि करते समय, एचडीडी बाधा है, सीपीयू या नेटवर्क नहीं।

मुझे लगता है कि उन मान्यताओं ज्यादा सरलीकृत कर रहे हैं।

सबसे पहले, जबकि LAN 100 एमबी/1 जीबीटी पर चलते हैं। लंबे समय तक चलने वाले नेटवर्क की अधिकतम डेटा दर होती है जो धीमे लिंक की अधिकतम दर से कम होती है।

दूसरा, इंटरनेट पर टीसीपी/आईपी स्ट्रीम का प्रभावी थ्रूपुट अक्सर राउंड-ट्रिप संदेशों और स्वीकृतियों के लिए लिया जाता है। उदाहरण के लिए, मेरे पास 8 + एमबीटी लिंक है, लेकिन जब मैं संयुक्त राज्य अमेरिका से डाउनलोड कर रहा हूं तो डाउनलोड पर मेरी डेटा दर प्रति सेकंड 1-2 एमबीटी से कम है। इसलिए यदि आप समांतर एक स्ट्रीम में कई धाराएं चला सकते हैं तो एक स्वीकृति के लिए इंतजार कर रहा है जबकि दूसरा पैकेट पंप कर रहा है। (लेकिन अगर आप बहुत ज्यादा भेजने का प्रयास करें, आप भीड़ हो रही शुरू, टाइमआउट, वापस बंद और कम समग्र अंतरण दर।)

अंत में, ऑपरेटिंग सिस्टम अच्छे हैं अन्य के साथ समानांतर में आई/ओ कार्यों की एक किस्म कर पर काम। यदि आप समानांतर में 2 या अधिक फ़ाइलों को डाउनलोड कर रहे हैं, तो ओ/एस एक डाउनलोड के लिए नेटवर्क पैकेट को पढ़/प्रसंस्करण कर रहा है और एक ही समय में डिस्क पर लिख रहा है ... एक ही समय में।

5

एक बेवकूफ "एकाधिक फाइलों की प्रतिलिपि बनाएँ" एप्लिकेशन एक फ़ाइल की प्रतिलिपि बनायेगा, फिर अगले को कॉपी करने से पहले इसे पूरा करने के लिए प्रतीक्षा करें।

इसका मतलब यह होगा कि एक व्यक्तिगत फ़ाइल को नेटवर्क विलंबता से तेज़ी से कॉपी नहीं किया जा सकता है, भले ही यह खाली हो (0 बाइट्स)। क्योंकि यह संभवतः कई फ़ाइल सर्वर कॉल करता है, (खोलें, लिखें, बंद करें), यह कई एक्स विलंबता हो सकता है।

फ़ाइलों की कुशलतापूर्वक प्रतिलिपि बनाने के लिए, आप एक सर्वर और क्लाइंट चाहते हैं जो एक सेन प्रोटोकॉल का उपयोग करें जिसमें पाइपलाइनिंग हो; यह कहना है - क्लाइंट अगली फाइल भेजने से पहले सहेजी जाने वाली पहली फ़ाइल का इंतजार नहीं करता है, और वास्तव में, कई या कई फाइलें "तार पर" हो सकती हैं।

ऐसा करने के लिए एक कस्टम सर्वर की आवश्यकता नहीं होगी एक एसएमबी (या समान) फ़ाइल सर्वर नहीं। उदाहरण के लिए, rsync यह करता है और सिंगल थ्रेडेड होने के बावजूद बड़ी संख्या में फाइलों की प्रतिलिपि बनाने में बहुत अच्छा है।

तो मेरा अनुमान है कि मल्टीथ्रेडिंग मदद करता है क्योंकि यह एक तथ्य है कि सर्वर एक सत्र पर पाइपलाइनिंग का समर्थन नहीं करता है।

एक एकल थ्रेडेड कार्यान्वयन जो एक समझदार प्रोटोकॉल का उपयोग करता है मेरी राय में सबसे अच्छा होगा।

+0

माइक्रोसॉफ्ट के फाइल प्रोटोकॉल स्थानांतरण बहुत खराब 'डिजाइन' हैं। उनके कार्यान्वयन अभी भी बदतर हैं। इसका मेरा सबूत यह है कि एसएएमबीए उसी हार्डवेयर पर विंडोज़ को बेहतर प्रदर्शन करेगा। समानांतर में प्रतिलिपि के इंतजार के कारण प्रति देरी की वजह से "मृत समय" में अन्य फ़ाइलों की प्रतिलिपि बनाकर कम किया जाता है। –

+0

मेरा मुद्दा यह नहीं था कि प्रोटोकॉल बुरी तरह डिज़ाइन किया गया है; यह है कि इसका डिजाइन खुद को इस विशेष उपयोग के मामले में उधार नहीं देता है। प्रोटोकॉल डिज़ाइन पारदर्शी दूरस्थ फ़ाइल पहुंच प्रदान करने के लिए आवश्यकता को लागू करने के लिए पर्याप्त है; यह विलंबता के साथ एक लिंक पर कई छोटी फाइलों की प्रतिलिपि बनाने के लिए बहुत अच्छा काम नहीं करता है - इसके लिए आपको कुछ और चाहिए। – MarkR

1

लंबी दूरी पर, नेटवर्क पढ़ने से कहीं अधिक तेज़ी से लिख सकते हैं। मल्टीथ्रेडिंग के साथ, अतिरिक्त "पाठकों" होने का अर्थ है कि डेटा को अधिक कुशलता से प्रसारित किया जा सकता है और बफर में नहीं दबाया जा सकता है।

2

यह एक नेटवर्क उपकरण है, इसलिए बाधा नेटवर्क है, न कि एचडीडी। एक (निम्न) बिंदु तक आप समानांतर में कुछ कनेक्शन का उपयोग करके एक टीसीपी लिंक से अधिक थ्रूपुट प्राप्त कर सकते हैं। यह (ए) टीसीपी हैंडशेक समानांतर करता है; (बी) बैंडविड्थ-देरी उत्पाद का बेहतर उपयोग कर सकते हैं यदि यह उच्च है; और (सी) किसी कारण से उच्च आरटीटी या विफलता दर का सामना करने के कारण किसी गंभीर तरीके से महत्वपूर्ण पथ को गंभीर तरीके से धीमा नहीं करता है।

करने का एक और तरीका (बी) एक विशाल टीसीपी सॉकेट प्राप्त बफर का उपयोग करना है, लेकिन यह हमेशा सुविधाजनक नहीं होता है।

एचडीडी के बारे में अन्य कई जवाब गलत हैं। व्यावहारिक रूप से कोई भी एचडीडी अनुक्रमिक पहुंच की धारणा पर कुछ पढ़ा जाएगा, और कोई भी बुद्धिमान ओएस कैश भी ऐसा करेगा।

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