مضمون کا ترجمہ: ایلچی تھریڈنگ ماڈل - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

مجھے یہ مضمون کافی دلچسپ لگا، اور چونکہ Envoy اکثر "istio" کے حصے کے طور پر یا محض kubernetes کے "انگریس کنٹرولر" کے طور پر استعمال ہوتا ہے، اس لیے زیادہ تر لوگوں کا اس کے ساتھ ویسا براہ راست تعامل نہیں ہوتا ہے، مثال کے طور پر، عام لوگوں کے ساتھ۔ Nginx یا Haproxy تنصیبات۔ تاہم، اگر کوئی چیز ٹوٹ جاتی ہے، تو یہ سمجھنا اچھا ہوگا کہ یہ اندر سے کیسے کام کرتا ہے۔ میں نے زیادہ سے زیادہ متن کا روسی زبان میں ترجمہ کرنے کی کوشش کی، خاص الفاظ سمیت؛ جن لوگوں کو یہ دیکھنا تکلیف دہ لگتا ہے، میں نے اصل کو قوسین میں چھوڑ دیا۔ بلی میں خوش آمدید۔

ایلچی کوڈبیس کے لیے کم درجے کی تکنیکی دستاویزات فی الحال بہت کم ہیں۔ اس کے تدارک کے لیے، میں ایلچی کے مختلف ذیلی نظاموں کے بارے میں بلاگ پوسٹس کی ایک سیریز کرنے کا ارادہ رکھتا ہوں۔ چونکہ یہ پہلا مضمون ہے، براہ کرم مجھے بتائیں کہ آپ کیا سوچتے ہیں اور مستقبل کے مضامین میں آپ کی کیا دلچسپی ہو سکتی ہے۔

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

تھریڈنگ کا جائزہ

ایلچی تین مختلف قسم کے سلسلے استعمال کرتا ہے:

مرکزی: یہ تھریڈ پروسیس اسٹارٹ اپ اور ٹرمینیشن کو کنٹرول کرتا ہے، XDS (xDiscovery Service) API کی تمام پروسیسنگ، بشمول DNS، ہیلتھ چیکنگ، جنرل کلسٹر اور رن ٹائم مینجمنٹ، شماریات ری سیٹ، ایڈمنسٹریشن اور جنرل پروسیس مینجمنٹ - لینکس سگنلز ہاٹ ری اسٹارٹ وغیرہ۔ ہر وہ چیز جو اس تھریڈ میں ہوتا ہے غیر مطابقت پذیر اور "غیر مسدود" ہے۔ عام طور پر، مرکزی دھاگہ تمام اہم فعالیت کے عمل کو مربوط کرتا ہے جن کو چلانے کے لیے بڑی مقدار میں CPU کی ضرورت نہیں ہوتی ہے۔ یہ زیادہ تر کنٹرول کوڈ کو اس طرح لکھنے کی اجازت دیتا ہے جیسے یہ سنگل تھریڈڈ ہو۔
کارکن: پہلے سے طے شدہ طور پر، ایلچی سسٹم میں ہر ہارڈویئر تھریڈ کے لیے ایک ورکر تھریڈ بناتا ہے، اسے آپشن کا استعمال کرکے کنٹرول کیا جا سکتا ہے۔ --concurrency. ہر ورکر تھریڈ ایک "نان بلاکنگ" ایونٹ لوپ چلاتا ہے، جو ہر سننے والے کو سننے کے لیے ذمہ دار ہوتا ہے؛ لکھنے کے وقت (29 جولائی 2017) سننے والے کی کوئی شارڈنگ نہیں ہوتی، نئے کنکشن کو قبول کرنا، فلٹر اسٹیک کو انسٹینٹیٹ کرنا کنکشن، اور کنکشن کی زندگی کے دوران تمام ان پٹ/آؤٹ پٹ (IO) آپریشنز پر کارروائی کرنا۔ ایک بار پھر، یہ زیادہ تر کنکشن ہینڈلنگ کوڈ کو اس طرح لکھنے کی اجازت دیتا ہے جیسے یہ سنگل تھریڈڈ ہو۔
فائل فلشر: ہر فائل جو ایلچی لکھتا ہے، بنیادی طور پر لاگز تک رسائی حاصل کرتا ہے، فی الحال ایک آزاد بلاکنگ تھریڈ ہے۔ یہ اس حقیقت کی وجہ سے ہے کہ استعمال کرتے وقت بھی فائل سسٹم کے ذریعہ کیش فائلوں کو لکھنا O_NONBLOCK کبھی کبھی بلاک ہو سکتا ہے (سسکنا)۔ جب ورکر تھریڈز کو کسی فائل پر لکھنے کی ضرورت ہوتی ہے، تو ڈیٹا کو درحقیقت میموری میں موجود بفر میں منتقل کر دیا جاتا ہے جہاں آخر کار اسے تھریڈ کے ذریعے فلش کیا جاتا ہے۔ فائل فلش. یہ کوڈ کا ایک شعبہ ہے جہاں تکنیکی طور پر تمام ورکر تھریڈز میموری بفر کو بھرنے کی کوشش کرتے ہوئے ایک ہی لاک کو بلاک کر سکتے ہیں۔

کنکشن ہینڈلنگ

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

اس کے کئی اہم نتائج ہیں:

ایلچی میں تمام کنکشن پولز ورکر تھریڈ کو تفویض کیے گئے ہیں۔ لہذا، اگرچہ HTTP/2 کنکشن پول ایک وقت میں ہر اپ اسٹریم ہوسٹ سے صرف ایک کنکشن بناتے ہیں، اگر چار ورکر تھریڈز ہیں، تو ایک مستحکم حالت میں فی اپ اسٹریم میزبان کے لیے چار HTTP/2 کنکشن ہوں گے۔
ایلچی کے اس طرح کام کرنے کی وجہ یہ ہے کہ ہر چیز کو ایک ہی ورکر تھریڈ پر رکھ کر، تقریباً تمام کوڈ کو بلاک کیے بغیر لکھا جا سکتا ہے اور گویا یہ سنگل تھریڈڈ ہے۔ یہ ڈیزائن بہت سارے کوڈ لکھنا آسان بناتا ہے اور ورکر تھریڈز کی تقریباً لامحدود تعداد پر ناقابل یقین حد تک اسکیل کرتا ہے۔
تاہم، اہم نکات میں سے ایک یہ ہے کہ میموری پول اور کنکشن کی کارکردگی کے نقطہ نظر سے، یہ دراصل بہت اہم ہے --concurrency. ضرورت سے زیادہ ورکر تھریڈز رکھنے سے میموری ضائع ہو جائے گی، مزید بیکار کنکشنز بنیں گے، اور کنکشن پولنگ کی شرح کم ہو جائے گی۔ Lyft میں، ہمارے ایلچی سائڈ کار کنٹینرز بہت کم ہم آہنگی کے ساتھ چلتے ہیں تاکہ کارکردگی تقریباً ان خدمات سے مماثل ہو جس کے ساتھ وہ بیٹھتے ہیں۔ ہم ایلچی کو ایک کنارے پراکسی کے طور پر صرف زیادہ سے زیادہ ہم آہنگی پر چلاتے ہیں۔

غیر مسدود کرنے کا کیا مطلب ہے؟

"نان بلاکنگ" کی اصطلاح اب تک کئی بار استعمال کی گئی ہے جب اس بات پر بحث کی جا رہی ہے کہ مین اور ورکر تھریڈز کیسے کام کرتے ہیں۔ تمام کوڈ اس مفروضے پر لکھے گئے ہیں کہ کچھ بھی کبھی بلاک نہیں ہوتا ہے۔ تاہم، یہ مکمل طور پر سچ نہیں ہے (کیا مکمل طور پر سچ نہیں ہے؟)

ایلچی کئی طویل عمل کے تالے استعمال کرتا ہے:

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

تھریڈ مقامی اسٹوریج

ایلچی جس طرح سے مین تھریڈ کی ذمہ داریوں کو ورکر تھریڈ کی ذمہ داریوں سے الگ کرتا ہے، اس کی ضرورت ہے کہ مرکزی تھریڈ پر پیچیدہ پروسیسنگ کی جائے اور پھر ہر ورکر تھریڈ کو انتہائی ہم آہنگی کے ساتھ فراہم کی جائے۔ یہ سیکشن اعلی سطح پر Envoy Thread Local Storage (TLS) کی وضاحت کرتا ہے۔ اگلے حصے میں میں بیان کروں گا کہ اسے کلسٹر کو منظم کرنے کے لیے کیسے استعمال کیا جاتا ہے۔

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

ایلچی کا TLS (تھریڈ لوکل اسٹوریج) سسٹم اس طرح کام کرتا ہے:

مرکزی دھاگے پر چلنے والا کوڈ پورے عمل کے لیے ایک TLS سلاٹ مختص کر سکتا ہے۔ اگرچہ یہ خلاصہ ہے، عملی طور پر یہ ایک ویکٹر میں ایک اشاریہ ہے، O(1) تک رسائی فراہم کرتا ہے۔
مین تھریڈ اپنے سلاٹ میں صوابدیدی ڈیٹا کو انسٹال کر سکتا ہے۔ جب یہ ہو جاتا ہے، ڈیٹا کو ہر ورکر تھریڈ پر عام ایونٹ لوپ ایونٹ کے طور پر شائع کیا جاتا ہے۔
ورکر تھریڈز اپنے TLS سلاٹ سے پڑھ سکتے ہیں اور وہاں دستیاب تھریڈ-لوکل ڈیٹا کو بازیافت کر سکتے ہیں۔

اگرچہ یہ ایک بہت ہی آسان اور ناقابل یقین حد تک طاقتور نمونہ ہے، لیکن یہ آر سی یو (ریڈ-کاپی-اپ ڈیٹ) بلاک کرنے کے تصور سے بہت ملتا جلتا ہے۔ بنیادی طور پر، ورکر تھریڈز کبھی بھی کام کے دوران TLS سلاٹس میں ڈیٹا میں کوئی تبدیلی نہیں دیکھتے ہیں۔ تبدیلی صرف کام کے واقعات کے درمیان باقی مدت کے دوران ہوتی ہے۔

ایلچی اسے دو مختلف طریقوں سے استعمال کرتا ہے:

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

کلسٹر اپ ڈیٹ تھریڈنگ

اس سیکشن میں، میں بیان کروں گا کہ کس طرح TLS (تھریڈ لوکل سٹوریج) کو کلسٹر کو منظم کرنے کے لیے استعمال کیا جاتا ہے۔ کلسٹر مینجمنٹ میں xDS API اور/یا DNS پروسیسنگ کے ساتھ ساتھ صحت کی جانچ بھی شامل ہے۔

کلسٹر فلو مینجمنٹ میں درج ذیل اجزاء اور اقدامات شامل ہیں:

کلسٹر مینیجر ایلچی کے اندر ایک جزو ہے جو تمام معروف کلسٹر اپ اسٹریمز، کلسٹر ڈسکوری سروس (CDS) API، سیکرٹ ڈسکوری سروس (SDS) اور Endpoint Discovery Service (EDS) APIs، DNS، اور فعال بیرونی چیکنگ کا انتظام کرتا ہے۔ یہ ہر اپ اسٹریم کلسٹر کا "بالآخر مستقل" منظر بنانے کے لیے ذمہ دار ہے، جس میں دریافت شدہ میزبانوں کے ساتھ ساتھ صحت کی حیثیت بھی شامل ہے۔
ہیلتھ چیکر ایک فعال صحت کی جانچ کرتا ہے اور کلسٹر مینیجر کو صحت کی حالت میں ہونے والی تبدیلیوں کی اطلاع دیتا ہے۔
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS کلسٹر کی رکنیت کا تعین کرنے کے لیے انجام دیا جاتا ہے۔ ریاست کی تبدیلی کلسٹر مینیجر کو واپس کر دی جاتی ہے۔
ہر ورکر تھریڈ ایک ایونٹ لوپ کو مسلسل چلاتا ہے۔
جب کلسٹر مینیجر اس بات کا تعین کرتا ہے کہ کلسٹر کی حالت بدل گئی ہے، تو یہ کلسٹر کی حالت کا ایک نیا صرف پڑھنے کا سنیپ شاٹ بناتا ہے اور اسے ہر ورکر تھریڈ کو بھیجتا ہے۔
اگلی پرسکون مدت کے دوران، ورکر تھریڈ اسنیپ شاٹ کو مختص کردہ TLS سلاٹ میں اپ ڈیٹ کرے گا۔
ایک I/O ایونٹ کے دوران جس میں میزبان کو بیلنس لوڈ کرنے کا تعین کرنا ہوتا ہے، لوڈ بیلنسر میزبان کے بارے میں معلومات حاصل کرنے کے لیے TLS (تھریڈ لوکل اسٹوریج) سلاٹ کی درخواست کرے گا۔ اس کے لیے تالے کی ضرورت نہیں ہے۔ یہ بھی نوٹ کریں کہ TLS اپ ڈیٹ ایونٹس کو بھی متحرک کر سکتا ہے تاکہ لوڈ بیلنسرز اور دیگر اجزاء کیشز، ڈیٹا سٹرکچرز وغیرہ کا دوبارہ حساب لگا سکیں۔ یہ اس پوسٹ کے دائرہ کار سے باہر ہے، لیکن کوڈ میں مختلف جگہوں پر استعمال ہوتا ہے۔

مندرجہ بالا طریقہ کار کو استعمال کرتے ہوئے، ایلچی ہر درخواست پر بغیر کسی بلاکنگ کے عمل کر سکتا ہے (سوائے جیسا کہ پہلے بیان کیا گیا ہے)۔ TLS کوڈ کی پیچیدگی کو چھوڑ کر، زیادہ تر کوڈ کو یہ سمجھنے کی ضرورت نہیں ہے کہ ملٹی تھریڈنگ کس طرح کام کرتی ہے اور اسے سنگل تھریڈڈ لکھا جا سکتا ہے۔ یہ اعلی کارکردگی کے علاوہ زیادہ تر کوڈ کو لکھنا آسان بناتا ہے۔

دوسرے ذیلی نظام جو TLS کا استعمال کرتے ہیں۔

ٹی ایل ایس (تھریڈ لوکل اسٹوریج) اور آر سی یو (ریڈ کاپی اپڈیٹ) بڑے پیمانے پر ایلچی میں استعمال ہوتے ہیں۔

استعمال کرنے کی مثالیں:

عمل درآمد کے دوران فعالیت کو تبدیل کرنے کا طریقہ کار: فعال فعالیت کی موجودہ فہرست کو مرکزی دھاگے میں شمار کیا جاتا ہے۔ اس کے بعد ہر ورکر تھریڈ کو RCU سیمنٹکس کا استعمال کرتے ہوئے صرف پڑھنے کے لیے اسنیپ شاٹ دیا جاتا ہے۔
روٹ ٹیبلز کو تبدیل کرنا: RDS (روٹ ڈسکوری سروس) کے ذریعے فراہم کردہ روٹ ٹیبلز کے لیے، روٹ ٹیبلز مین تھریڈ پر بنائی جاتی ہیں۔ آر سی یو (ریڈ کاپی اپ ڈیٹ) سیمنٹکس کا استعمال کرتے ہوئے ہر ورکر تھریڈ کو بعد میں صرف پڑھنے کا سنیپ شاٹ فراہم کیا جائے گا۔ یہ روٹ ٹیبلز کو تبدیل کرنے کو جوہری طور پر موثر بناتا ہے۔
HTTP ہیڈر کیشنگ: جیسا کہ یہ پتہ چلتا ہے، ہر درخواست کے لیے HTTP ہیڈر کا حساب لگانا (~25K+ RPS فی کور چلانے کے دوران) کافی مہنگا ہے۔ ایلچی مرکزی طور پر ہر آدھے سیکنڈ میں ہیڈر کی گنتی کرتا ہے اور اسے TLS اور RCU کے ذریعے ہر کارکن کو فراہم کرتا ہے۔

دیگر معاملات بھی ہیں، لیکن پچھلی مثالوں سے یہ اچھی طرح سمجھنا چاہیے کہ TLS کس لیے استعمال ہوتا ہے۔

معلوم کارکردگی کے نقصانات

اگرچہ ایلچی مجموعی طور پر کافی اچھی کارکردگی کا مظاہرہ کرتا ہے، کچھ قابل ذکر شعبے ایسے ہیں جن پر توجہ کی ضرورت ہوتی ہے جب اسے بہت زیادہ کنکرنسی اور تھرو پٹ کے ساتھ استعمال کیا جاتا ہے:

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

نتیجہ

ایلچی کے تھریڈنگ ماڈل کو پروگرامنگ میں آسانی فراہم کرنے کے لیے ڈیزائن کیا گیا ہے اور اگر صحیح طریقے سے ترتیب نہ دی گئی ہو تو ممکنہ طور پر ضائع ہونے والی میموری اور کنکشنز کی قیمت پر بڑے پیمانے پر ہم آہنگی فراہم کی جائے۔ یہ ماڈل اسے بہت زیادہ دھاگوں کی گنتی اور تھرو پٹ پر بہت اچھی کارکردگی دکھانے کی اجازت دیتا ہے۔
جیسا کہ میں نے ٹویٹر پر مختصراً ذکر کیا ہے، یہ ڈیزائن پورے یوزر موڈ نیٹ ورکنگ اسٹیک جیسے ڈی پی ڈی کے (ڈیٹا پلین ڈویلپمنٹ کٹ) کے اوپر بھی چل سکتا ہے، جس کے نتیجے میں روایتی سرورز مکمل L7 پروسیسنگ کے ساتھ فی سیکنڈ لاکھوں درخواستوں کو سنبھال سکتے ہیں۔ یہ دیکھنا بہت دلچسپ ہوگا کہ اگلے چند سالوں میں کیا تعمیر ہوتا ہے۔
ایک آخری فوری تبصرہ: مجھ سے کئی بار پوچھا گیا کہ ہم نے ایلچی کے لیے C++ کا انتخاب کیوں کیا۔ وجہ یہ ہے کہ یہ اب بھی وسیع پیمانے پر استعمال ہونے والی صنعتی گریڈ کی واحد زبان ہے جس میں اس پوسٹ میں بیان کردہ فن تعمیر کو بنایا جا سکتا ہے۔ C++ یقینی طور پر تمام یا یہاں تک کہ بہت سے پروجیکٹس کے لیے موزوں نہیں ہے، لیکن کچھ استعمال کے معاملات کے لیے یہ کام انجام دینے کا واحد ذریعہ ہے۔

کوڈ کے لنکس

اس پوسٹ میں زیر بحث انٹرفیس اور ہیڈر کے نفاذ کے ساتھ فائلوں کے لنکس:

ماخذ: www.habr.com

[ترجمہ] ایلچی تھریڈنگ ماڈل