چھوٹی فائلیں 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 کی اپنی منتقلی سے الگ رکھیں، کیونکہ ایک میں درستگی دوسرے کے بارے میں ثبوت نہیں۔