छोट्या फाइल्स 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 च्या स्वतःच्या वाहतुकीपासून वेगळी ठेवा, कारण एकातील दुरुस्ती दुसऱ्याबद्दलचा पुरावा नाही।