साना फाइलहरू VPN मा आउने-जाने चक्रका कारण घस्रन्छन्, गतिका कारण होइन
साना फाइलहरूको फोल्डरले ठूलो फाइलले लुकाउने मेटाडाटा र आउने-जाने चक्रका लागत तिर्छ। सुरुङको ब्यान्डविथलाई दोष दिनुअघि कामको भारको आकार नाप्नुहोस्।
VPN मा 2 GB को एउटा फाइल प्रतिलिपि गर्नुहोस् र स्थानान्तरण ठीक देखिन्छ। दस हजार साना कागजात भएको फोल्डर प्रतिलिपि गर्नुहोस् र त्यही लिङ्क बिग्रिएको देखिन्छ। फरक दुई कामबीच बदलिएको ब्यान्डविथ सेटिङ होइन। दोस्रो कामले समय सेटअप, मेटाडाटा र जवाफको प्रतीक्षामा बिताउँछ, र सुरुङको विलम्बताले त्यो प्रतीक्षा देखिने बनाउँछ।
एउटा फाइल स्ट्रिम हुन्छ; फाइलहरूको फोल्डर वार्ता गर्छ
ठूलो प्रतिलिपिले आफ्नो जीवनको अधिकांश समय केही खुला ह्यान्डलमा पढ्ने-लेख्ने लूपमा बिताउँछ। प्रोटोकलको अतिरिक्त लागत प्रति फाइल एक पटक तिरिन्छ, र डाटा ठूला ब्लकमा सर्छ। नतिजामा ब्यान्डविथको प्रभुत्व हुन्छ।
फोल्डर प्रतिलिपिले प्रति फाइल तिर्छ: बनाउने, गुण सोध्ने, खोल्ने, लेख्ने, बन्द गर्ने र डाइरेक्टरी मेटाडाटा अद्यावधिक गर्ने। यीमध्ये प्रत्येक अर्को चरण अगाडि बढ्नुअघि जवाफ पर्खने अनुरोध हो। बाइट साना छन्; समन्वय होइन।
त्यसैले कम लिङ्क-उपयोगको ग्राफले लगभग केही पनि प्रमाणित गर्दैन। लिङ्क निष्क्रिय छ किनकि क्लाइन्ट पर्खिरहेको छ, सुरुङ ढिलो भएर होइन। स्टोरेज एरे वा इन्डपोइन्ट स्क्यानरले त्यही प्रकारको ढिलाइ थप्न सक्छ। कुनै पनि नेटवर्क सेटिङ बदल्नुअघि कुन चरण पर्खिरहेको छ पहिचान गर्नुहोस्।
आउने-जाने चक्र बाइटभन्दा छिटो थुप्रिन्छन्
विलम्बता एउटा निर्भर आदान-प्रदानको लागत हो। यदि फाइललाई धेरै क्रमिक आदान-प्रदान चाहिन्छ र सुरुङले प्रत्येक दिशामा 40 ms थप्छ भने, प्रति फाइल लागत छिटो बढ्छ। दस हजार फाइलले त्यसलाई मिनेटमा बदल्छ।
गणना उदाहरण हो, मापन होइन: फाइलले एकै आउने-जाने चक्र लिन्छ भन्ने ग्यारेन्टी छैन, र क्लाइन्टहरू केही काम एकअर्कामा ओभरल्याप गर्छन्।
कुल दुई लिभरले बदल्छ। प्रति फाइल निर्भर आदान-प्रदानको संख्या घटाउनुहोस्, वा तीमध्ये धेरै एकै समयमा चलाउनुहोस्। पहिलो प्रोटोकल वा कामको भारमा परिवर्तन हो; दोस्रो समानान्तरता हो। दुवैले ढिलो लिङ्कलाई छिटो बनाउँदैनन्।
कामको भार नाप्नुहोस्, लिङ्क होइन
समान इन्डपोइन्ट र समान पहुँच नीति भएका तीन कामको तुलना गर्नुहोस्: एउटा ठूलो फाइल, साना फाइलहरूको फोल्डर र वास्तविक व्यापारिक कार्य। प्रत्येक नतिजासँगै फाइल संख्या, आकार वितरण, प्रतिलिपि उपकरण र नेटवर्क अवस्था रेकर्ड गर्नुहोस्।
ती विवरणबिनाको एउटै MB/s अंक अरू कसैको अंकसँग तुलना गर्न सकिँदैन।
विलम्बता थ्रुपुटबाट अलग नाप्नुहोस्। फाइल सर्भरसम्मको साधारण आउने-जाने परीक्षणले साना कार्यहरूमा गुणा हुने अंक दिन्छ। त्यसपछि प्रतिलिपिको औसत दर होइन, अनुरोधको ढाँचा हेर्नुहोस्। यदि दर कम छ र लिङ्क निष्क्रिय छ भने, अवरोध सुरुङको माथि छ।
काम बदल्नुहोस्: समानान्तरता र अभिलेख
अधिकृत ठूलो प्रतिलिपिका लागि नियन्त्रित समानान्तरता भएको उपकरणले धेरै अनुरोध चलाइराख्छ। Robocopy को /MT विकल्प Windows मा सामान्य उदाहरण हो। थ्रेड थप्दा छिटो प्रतिलिपिको ग्यारेन्टी हुँदैन।
क्लाइन्ट, सर्भर र स्टोरेजले सहन सक्ने संख्या छान्नुहोस्, र कामको लग र कुनै पनि त्रुटि राख्नुहोस्।
स्रोतमा अभिलेख गर्ने र स्थानीय रूपमा खोल्ने कामले प्रति फाइल टाढाको काम हटाउँछ। तुलनामा तयारी र निकासीको समय समावेश गर्नुहोस्, र अभिलेखले कामलाई आवश्यक मेटाडाटा र अनुमति सुरक्षित राख्छ भनी पुष्टि गर्नुहोस्। दुवै उपायले एप्लिकेसनलाई आफ्नै फाइल कार्यहरू ब्याच गर्न बाध्य पार्दैन।
नियन्त्रित परीक्षणले काउन्टर जाँच्नुहोस्
एउटा चल बदलेर त्यही काम दुई पटक चलाउनुहोस्, र दुवै अंक रेकर्ड गर्नुहोस्। सेटिङले मद्दत गर्यो कि नेटवर्क संयोगवश शान्त थियो भनी जान्ने एकमात्र उपाय नियन्त्रित परीक्षण हो।
दुई आदेशले फाइल संख्या र आउने-जाने चक्रको आधाररेखा दिन्छन्:
Get-ChildItem \\fileserver.hq.example\\share -Recurse | Measure-Object -Property Length -Sum
ping -n 20 fileserver.hq.example
त्यसपछि सीमित थ्रेड संख्यासँग प्रतिलिपि चलाउनुहोस् र लगलाई अघिल्लो पटकसँग तुलना गर्नुहोस्:
robocopy \\fileserver.hq.example\\share C:\\local /E /MT:16 /LOG:copy.log /TEE
काउन्टर सुधार्न SMB साइनिङ, इन्क्रिप्शन वा इन्डपोइन्ट सुरक्षा बन्द नगर्नुहोस्। ती परिवर्तनले अवरोध नभएको हुन सक्ने अंकका लागि सुरक्षा गुण साट्छन्। र आफ्नो नोटमा VPN यातायातलाई SMB को आफ्नै यातायातबाट अलग राख्नुहोस्, किनकि एउटामा गरिएको सुधार अर्कोबारे प्रमाण होइन।