OpenVPN کو کتنے کور درکار ہیں؟ یہ راستے پر منحصر ہے

ایک جیسے پروسیسر کی تعداد والے دو سرور بہت مختلف تھرو پٹ برقرار رکھ سکتے ہیں، کیونکہ اہم عدد یہ ہے کہ فعال ڈیٹا راستہ واقعی کتنے کور استعمال کر سکتا ہے۔ ایک کلائنٹ کے پیکٹ پروسیس کرنے والا واحد صارف جوگ ڈیمون ایک کور تک محدود ہوتا ہے، جبکہ کرنل میں منتقل شدہ راستہ وہ کام پھیلا سکتا ہے۔ ان دونوں بیانات میں سے کوئی یہ نہیں بتاتا کہ کوئی مخصوص مشین آپ کی ٹریفک کے ساتھ کیا کرے گی، اس لیے پیمائش کور گننے سے پہلے آتی ہے۔

نیچے دیا گیا موازنہ اس بارے میں ہے کہ پیکٹ کہاں پروسیس ہوتے ہیں، اس بارے میں نہیں کہ کون سی مصنوعات تجریدی طور پر تیز ہے۔ یہ مختلف سوالات ہیں جن کے مختلف جواب ہیں۔

صارف کی جگہ کے راستے پر فی بہاؤ ایک کور

روایتی Community OpenVPN مثال میں ڈیٹا چینل صارف کی جگہ میں پروسیس ہوتا ہے، اور مصروف کنکشن ایک پروسیسر کو پکڑ سکتا ہے جبکہ مشین کا مجموعی استعمال نظر نہ آنے کے برابر رہتا ہے۔ اسی لیے ایک بہاؤ پر پہلے ہی سیر شدہ ہوسٹ میں کور بڑھانے سے کچھ نہیں بدلتا: شیڈیولر کے پاس وہ کام تقسیم کرنے کا کوئی طریقہ نہیں۔ فی کلائنٹ ایک عمل کا ڈھانچہ ایک کلائنٹ کی منتقلی کو کل کور تعداد سے قطع نظر ایک کور کی صلاحیت تک محدود کرتا ہے۔ جانچ کے دوران کل تعداد کے بجائے فی کور استعمال پڑھیں، ورنہ رکاوٹ بچی ہوئی گنجائش معلوم ہوگی۔

ایک ہوسٹ پر کئی سرور مثالیں چلانا الگ الگ کلائنٹس کو عملوں میں تقسیم کرتا ہے۔ یہ موجودہ کنکشن کو متوازی نہیں کرتا، اور الگ پول، سامعین اور روٹنگ فیصلے طلب کرتا ہے۔

دوسرا راستہ: کرنل میں پیکٹ

ڈیٹا چینل آف لوڈ معاون پیکٹ پروسیسنگ اور خفیہ کاری کو کرنل میں منتقل کرتا ہے، جہاں کام کئی کور استعمال کر سکتا ہے۔ یہ گنجائش کا سوال ایک کور سے مشین تک بدل دیتا ہے، مگر صرف ان ترتیبات کے لیے جنہیں عمل درآمد معاون قرار دیتا ہے: موافق کرنل ماڈیول، موزوں ڈیٹا سائفر اور ایسی ترتیب جس میں وہ خصوصیات نہ ہوں جو آف لوڈ خارج کرتا ہے۔ ماڈیول نصب کرنا اسے استعمال کرنے کے برابر نہیں، اس لیے فعال موڈ کی تصدیق کنکشن کے اپنے لاگ یا حالت کی آؤٹ پٹ سے کریں۔ ورژن بینر ثابت کرتا ہے کہ کیا دستیاب ہے، یہ نہیں کہ کیا چل رہا ہے۔

آف لوڈ تصدیق یا کنٹرول چینل کو نہیں ہٹاتا، اور ہر تعیناتی کو کثیر کور نہیں بناتا۔ یہ موافق ڈیٹا راستے کی مقامی تیز رفتاری ہے، اور تقاضے پلیٹ فارم اور ورژن کے مطابق مختلف ہوتے ہیں۔

موازنہ درحقیقت کیا طے کرتا ہے

اصل انتخاب فی بہاؤ حد قبول کرنے، کلائنٹس کو مثالوں میں پھیلانے، اور معاون آف لوڈ ترتیب کی طرف جانے کے درمیان ہے۔ ہر ایک الگ مسئلہ حل کرتا ہے، اور غلط چننا عدد کو ہلائے بغیر پیسہ خرچ کرتا ہے۔ اہم جانچ وہ ہے جو خدمت کے استعمال کے انداز جیسی شکل میں ہو۔

تین شکلیں پیمائیں: ایک منتقلی کے ساتھ ایک کلائنٹ، کئی بہاؤ کے ساتھ ایک کلائنٹ، اور اکٹھے کئی کلائنٹس۔ تیسری میں زیادہ مجموعہ ثابت نہیں کرتا کہ ایک ڈاؤن لوڈ وہاں پہنچ سکتا ہے، اور سست واحد منتقلی ثابت نہیں کرتا کہ سرور کی مجموعی گنجائش ختم ہو گئی ہے۔ نتائج مختلف سوالات کے جواب دیتے ہیں اور دونوں رکھنے کے لائق ہیں۔

صرف درمیانی شکل بتاتی ہے کہ ایک کلائنٹ کے اندر ہم وقتی مدد کرتی ہے یا نہیں، جو عام طور پر سرور کی نہیں بلکہ نقل و حمل اور راستے کی خصوصیت ہے۔ صرف پہلی وہ حد بتاتی ہے جو ایک ایپلیکیشن دیکھے گی۔ موازنہ بامعنی رہے اس کے لیے دوڑوں کے درمیان کام کا بوجھ یکساں رکھیں۔

عدد بامعنی ہو اس کے لیے پیمائش

سرور اور کلائنٹ کے ورژن، فعال ڈیٹا راستہ، طے شدہ ڈیٹا سائفر، منتقلی کی سمت، پیکٹ کے حجم، بہاؤ کی تعداد اور دورانیہ درج کریں۔ فی کور سرگرمی اور دونوں سروں پر پیکٹ اور قطار کے ضیاع کو دیکھیں، کیونکہ کلائنٹ کا اپنا انٹرفیس، فراہم کنندہ کا نیٹ ورک یا منزل کی خدمت پہلے حد بن سکتی ہے۔ ایک وقت میں ایک متغیر بدلیں، کیونکہ سائفر، کمپریشن، MTU اور آف لوڈ اکٹھے بدلنے والی دوڑ نہیں بتا سکتی کہ کون اہم تھا۔ جانچ کے دوران وہ رسائی پالیسی رکھیں جو آپ واقعی نافذ کرنا چاہتے ہیں، کیونکہ ایسا لیبارٹری انتظام جسے کوئی نہ چلائے بہت کم ثابت کرتا ہے۔

پھر کنٹرول چینل، دوبارہ بات چیت اور ہوسٹ پر چلنے والے باقی سب کے لیے جگہ چھوڑیں۔

بتائیں کہ ترتیب نے مطلوبہ ہم وقتی کے تحت کیا برداشت کیا، کسی اور کے ہارڈ ویئر سے اندازہ لگائی گئی رفتار نہیں۔ جانچ کی شرائط کے ساتھ دیا گیا عدد مفید ہے؛ ان کے بغیر وعدہ ایسا اندازہ ہے جو بعد میں آپ کے خلاف نقل کیا جائے گا۔