چرا NGINX انقدر وحشتناک سریعه؟!
بخش اول: Traffic Routing

--------------------------------------

مدتی بود دنبال پروژه ای بودم که با هدف عمیق تر شدن توی مفاهیم شبکه و کانکارنسی بتونم با سی++ پیاده سازی کنم، هم فال بود و هم تماشا.
بعد از یه مدت تصمیم گرفتم سمت وب‌سرورها برم و رفتار اونارو زیر بار بررسی کنم، سورس NGINX رو دانلود کردم و شروع کردم به بیلد کردنش و بعد از سر و کله زدن با openssl در نهایت بیلدش کردم، هدف من بیشتر مشاهده ی رفتار NGINX روی حالتی بود که میخواست Load balancing کنه.

طبق چیزی که دیدم NGINX میاد و به دو روش معمول ترافیک رو به سمت سرور های مقصد ارسال میکنه، به طوری که میتونیم بگیم به روش Reverse proxy داره ترافیک رو سمت سرور مقصد هدایت میکنه. وقتی درخواستی از سمت کلاینت ارسال میشه NGINX اون رو دریافت میکنه و طبق الگوریتمی سرور مقصد رو انتخاب میکنه و روش یه سوکت جدید باز میکنه همچنین ممکنه از سوکت های قبلی که اماده داره به سرور مقصد استفاده کنه تا زمان Connection Establishing رو کاهش بده، بعد ترافیک رو از کلاینت میخونه و به سمت سرور اصلی فوروارد میکنه و منتظر جواب میمونه(بخش های بعدی میگم چطور) بعد از اینکه جواب از سرور مقصد دریافت شد اون رو به کلاینت برمیگردونه و تمام.

حالا چرا گفتم ۲ روش؟ چون هم میتونه این کار رو توی لایه ی ۴ نتورک مدل OSI انجام بده هم میتونه توی لایه ی ۷ مدل OSI انجام بده، اگه بخواییم بهتر متوجه بشیم من هم میتونم به NGINX بگم که درخواست هارو بر اساس هدر، سشن یا اندپوینت هدایت کنم(لایه‌ی ۷)، هم میتونم اجازه بدم بر اساس IP یا PORT کاربر این اتفاق بیوفته(لایه‌ی ۴).

‌ وقتی ما نیاز داریم که سشن یا هدر رو چک کنیم در حقیقت نیاز داریم که داده ای که برامون ارسال شده رو باز کنیم و پردازشش کنیم و بعد بر اساس اون تصمیم بگیریم ولی توی مدل دوم نیازی به داده ی ارسالی نداریم و IP و PORT کاربر مشخصه، پس میتونیم بگیم روش اول توی لایه ی هفتم و روش دوم توی لایه ی چهارم اتفاق میوفته که طبیعتا سریعتر از روش اول باید باشه.

@knowpow

اگه اینجا اون ریورس پروکسی که توی عکس میبینیم رو بهش یه لاجیکی اضافه کنیم که تصمیم بگیره با یه مبنایی ترافیک رو به یه مقصدی هدایت کنه در حقیقت ما یه لودبالانسر ساختیم

لود بالانسرها به همین سادگی هم نیستن ولی کلیت ماجرا اینه

@knowpow

چرا NGINX انقدر وحشتناک سریعه؟!
بخش دوم: Blocking I/O

--------------------------------------

توی بخش قبلی فهمیدیم که NGINX ترافیک روتینگ رو توی لایه‌ی چهار و لایه‌ی هفت مدل OSI انجام میده و از مدل Reverse Proxy استفاده میکنه.

حالا باید بدونیم چطور NGINX چندین هزار رکویست رو در لحظه میتونه مدیریت کنه؟!
خب NGINX میاد از Nonblocking I/O برای مدیریت کانکشن ها استفاده میکنه، ولی من اول میخوام بریم ببینیم که اصلا Blocking I/O چیه که Nonblocking I/O هم وجود داره؟ اصن چرا باید بلاک بشه چیزی؟

زمانی که برنامه ای میخواد به IO دسترسی پیدا بکنه باید یه سری فرایند رو بگذرونه که این کارها زمانبره و به صورت blocking انجام میشه، یعنی فرض کنید اگر برنامه‌ای میخواد یک فایلی باز کنه تا اون رو بخونه باید فرایند زیر رو طی کنه:

۱- سیستم کال: باید درخواست باز کردن فایل رو با سیستم کال open بدین
۲- تغییر حالتCPU: کرنل برای اینکه بتونه این درخواست رو پردازش کنه نیاز داره که CPU رو به حالت کرنل تغییر بده(چرا؟ چون سوئیچ ضروریه و دسترسی مستقیم به سیستم فایل و منابع سخت افزاری کاری محسوب میشه که فقط کرنل مجازه انجام بده)
۳- صحت سنجی آدرس: اول کرنل شروع میکنه ببینه ادرس فایلی که دادین درسته بعد هم چک میکنه ببینه که آیا شما مجازین که این کار رو انجام بدین یا نه
۴-تخصیص فایل: در نهایت اگه مراحل قبل موفق باشه، کرنل یه file handler یا file denoscriptor به این فایل تخصیص میده
۵- بررسی قفل فایل: کرنل اینجا چک میکنه ببینه کسی قبل از شما این فایل رو قفل کرده یا نه و اگه کسی نباشه به این فایل یک lock در نظر میگیره و فایل رو باز میکنه
۶-بازگشت توصیفگر فایل: بعد از باز کردن فایل، کرنل file denoscriptor رو بعد از اینکه CPU به حالت یوزر برگشت به شما برمیگردونه و شما باقی کارها رو با اون file denoscriptor انجام میدین

خب این مسیر کلی بود که پروسس شما برای باز کردن یه فایل ساده انجام میداد، الان میخوام بگم کدوم مراحل ممکنه پروسس شمارو بلاک کنه و بیشتر از طبق معمول طول بکشه، تغییر حالت CPU از کرنل به یوزر یه کار هزینه بره ولی من چون توی همه‌ی سیستم کال ها اینکارو انجام میدیم دیگه درنظرش نمیگیرم، حالا توی مرحله ی ۳ اگه ادرسی که دادین روی یه هارد مکانیکی باشه یا روی دیسکتون بار خوندن و نوشتن بالایی وجود داشته باشه میتونه اینکار بلاک بشه، توی مرحله ی ۳ چک کردن دسترسی ها نیازی به کار خاصی نداره و سریع انجام میشه، توی مرحله ی ۴ هم کارا سریع انجام میشن ولی اگه کرنل به حد مجاز توصیفگرهای فایل(file denoscriptor)هایی که باز هستن نزدیک بشه و نیاز به مدیریت و تخصیص مجدد ریسورس داشته باشه ممکنه بیشتر از حد معمول طول بکشه
توی مرحله ی ۵ هم پتانسیل بلاک شدن وجود داره چون اگر پروسس دیگه ای فایل رو قفل کرده باشه، کرنل باید منتظر آزاد شدن قفل باشه که طبیعتا منتظر موندن کرنل یعنی بلاک شدن پروسس ما.
توی مرحله‌ی اخر تنها کاری که مجبوری انجام بدیم و بازگشت به حالت کاربر هست و تمام

جمع بندی:
هر کاری که نیاز به I/O داشته باشه به احتمال خیلی زیاد پروسس شمارو بلاک میکنه و باید منتظر تموم شدن کاری که درخواست کردیم باشیم، چرا گفتم به احتمال خیلی زیاد؟! چون توی حالت عادی که باری روی سیستم نیست تمامی باس های داده خالیه و همه میتونن راحت رفت و آمد کنن، ولی وقتی بار سیستم میره بالا و باس های داده مثل اتوبان کرج-تهران میشه و دیگه همه چی مثل قبل نیست، باید برای باز کردن فایل که یه کار ساده محسوب میشه صبر کنیم و پروسسمون رو بلاک کنیم، و این اصلا برای سیستسم خوب نیست. دقت کنید که ما حاضریم هزینه ی انجام دادن تسک رو بدیم ولی نباید ریسورس سیستم رو برای کاری مثل منتظر موندن برای خلوت شدن باس داده یا در دسترس بودن lock انجام بدیم، اینکاره که سیستم رو کند میکنه، مگر نه من اگه بخوام یه فایل یه میلیون سطری رو بخونم هیچ چاره ای ندارم جز اینکه خط به خط این فایل رو بخونم و هزینه ی این تسک رو باید بدم چون هیچ راه فراری وجود نداره غیر از اینکه خط به خط فایل خونده بشه، ولی میتونم یه مکانیزم استفاده کنم که سیستم رو منتظر باز شدن قفل فایل، ازاد شدن باس داده و هرچیز دیگه ای نکنم! اسم این مکانیزم Nonblocking I/O هست که توی پست بعدی صحبت میکنم در موردش.

@knowpow

از پست بعدی فکر کنم کلمه‌ی وحشتناک رو هم میتونم حذف کنم،‌ قبل اینکه شروع کنم به خوندن فکر میکردم تنها چیزی هست که میتونه NGINX رو توصیف کنه این کلمه اس ولی خب الان اینجوری فکر نمیکنم

خیلی خوشحال میشم کانالم رو به کسایی که فکر میکنید براشون مفیده معرفی کنید

من یه مهندس نرم افزار هستم که بیشتر سمت بهبود پرفورمنس سیستم ها بوده و تا امروز بخش موبایل و کرنل موبایل بودم و الان هم در مورد سیستم های توزیع شده، کرنل لینوکس و نتورکینگ میخونم و اینجا در موردشون مینویسم.

مثل همیشه فقط میخوام اشاره کنم به اینکه این کانال بخشی از تلاش من برای کمک به پیدا کردن مسیر شغلی حرفه ای تر، احساس مفید بودن و در نهایت زندگی بهتر برای اون دسته از آدم هایی هست که میخوان برای جامعه و بشریت مفید باشن و امیدوارم بتونه برای هموار کردن و روشن‌تر کردن مسیر زندگی یک نفر هم که شده کمک کنه.


@knowpow

اگر بخوام مثال دیگه ای از نوشتن به صورت بلاکینگ بگم این تصویر به خوبی میتونه گویای ماجرا باشه، اینجا من نوشتن بروی I/O سوکت TCP رو مثال میزنم و سیستم کال write() رو توضیح میدم.

خب توی تصویر میبینیم که برای هر اندپوینت سوکتی که از کرنل درخواست باز کردن میکنیم کرنل یک بافر نوشتن و یک بافر خواندن به اون اختصاص میده،‌ و وقتی روی یک سوکت میخواییم عملیات write انجام بدیم کرنل تا زمانی که داده بروی بافر ارسال کپی نشده باشه پروسس برنامه رو بلاک میکنه، این اتفاق حتی وقتی بافر ارسال هم پر باشه میوفته، یعنی فرض کنین ۱۰۲۴ بایت ارسال شده و بطور کامل بروی شبکه نوشته نشده و در همین حین درخواست برای نوشتن ۱۰۲۴ بایت دیگه هم میاد، ولی کرنل پروسس رو تا جایی که این ۱۰۲۴ بایت دوم رو بتونه توی بافر جا براش تخصیص بده بلاک نگه میداره، حالا خالی شدن این بافر به وضعیت شلوغی شبکه و کانفیگ سیستم بستگی داره.

راه حل؟ مدل Nonblocking که بهش میرسیم تو ادامه...

@knowpow

چرا NGINX انقدر سریعه؟!
بخش سوم: Non Blocking I/O

--------------------------------------

توی بخش قبلی فهمیدیم وقتی که یه سیستم کال برای باز کردن یک فایل انجام میشه چه اتفاقایی میوفته، و چه چیزهایی پتانسیل بلاک کردن پروسس برنامه رو دارند، توی این بخش میخوام در مورد مدل بعدی یعنی Nonblocking بنویسم.

نکته: توی مدل لینوکسی ترد با پروسس هیچ تفاوتی نداره، تنها امتیازی که ترد داره و توانایی دسترسی به مموری تردهای دیگه یا shared memory هست،‌ پس هر وقت توی این سری پست ها گفتم ترد منظورم میتونه پروسس هم باشه، چون پروسس هم یه ترد محسوب میشه که ID اون برابر با PID هست.

نگهداری ترد ها برای سیستم‌عامل هزینه ی بالایی دارن، اولین هزینه ای که اینجا من بهشون اشاره میکنم انجام contex switching روی ترد ها توسط CPU هست، contex switching زمانی اتفاق میوفته که سیستم‌عامل cpu رو از یک ترد بگیره و به ترد دیگه ای بده. برای اینکار سیستم عامل باید اطلاعات فعلی که ترد داره (مثل کانتر برنامه، اطلاعات رجیستر، مموری الوکیت شده و..) رو ذخیره کنه و اطلاعات ترد بعدی روی روی سیستم لود کنه،‌ برای همین اینکار هزینه ی محاسباتی بالایی داره و وقتی خیلی زیاد انجام بشه میتونه لود سیستم رو ببره بالا . (کتابخونه ی کوروتین کاتلین اینجا یه روش نسبتا خوبی رو پیاده سازی کرده که درموردش مینویسم)


اکثر وب سرورها برای هر رکویستی که دریافت میکنند یک ترد یا یک پروسس بهش اختصاص میدن، این کار از لحاظ پیاده سازی فنی آسونه و پیچیدگی کمی داره،‌ ولی یه مشکل اساس وجود داره اینکه هر ترد بیشتر زمانش رو صرف منتظر موندن از I/O میکنه، یا منتظر آماده شدن سوکتی هست که روش باز شده تا دیتا بخونه، یا منتظره تا سوکتی که برای سروری origin باز کرده اماده ی نوشتن بشه.(این پست) ولی NGINX اینطوری نیست، با توجه به کانفیگ که من worker_processes رو auto در نظر میگیرم، NGINX میاد و به تعداد هسته های موجود سیستم Worker Process میسازه، یعنی توی دنیای موازی اگر دوتا وب سرور با مشخصات سخت افزاری(۸ هسته) یکسان ولی روی یکیش NGINX و روی دیگری وب سرور x باشه و من ۱۰۰۰ تا رکویست همزمان رو سمت این دوتا سرور کنم وب سرور x به تعداد ۱۰۰۰ تا ترد میسازه ولی NGINX همه ی این ۱۰۰۰ رکویست رو روی همون ۸ تا پروسس(که هر کدوم فقط یک ترد دارند) تمامی این رکویست هارو مدیریت میکنه، اینکار از Contex switching زیاد جلوگیری میکنه چون دیگه نیازی نیست تردی رو بلاک کنیم و به ترد دیگه برای پردازش سوییچ کنیم، در حقیقت پروسس های ورکر NGINX رکویست رو میگیرن و اگه چیزی برای پردازش بود پردازش میکنند و اگه نبود ادامه میدن برای تسک بعدی.

ولی چطور؟! اگه بخوام توی یه خط جواب بدم میشه به کمک مدل Non Blocking I/O و معماری event driven ای که توسط epoll پیاده سازی کرده،‌ توی پست های بعدی همین یه خط رو باز میکنم و تا عمق ماجرا میرم


توی پست بعدی دوباره در مورد Nonblocking I/O خواهم نوشت

@knowpow

توی این تصویر یه نمای کلی از ساختار NGINX رو برای وقتی که تعداد ورکر ها بروی ۳ ست شده میبینیم، تعداد ورکر ها توی رفتار NGINX هیچ تاثیری نداره و فقط قدرت پردازش اون رو بالا میبره و horizontal scaling میکنه

چیزی که برام جالب بود این هست که وقتی کانفیگ جدید لود میشه،‌ پروسس ورکرها دیگه درخواست باز کردن کانکشن جدید قبول نمیکنه، و NGINX دوباره n تعداد با کانفیگ جدید پروسس میسازه، بعد ورکرهایی که با کانفیگ قبلی کار میکردن اگه درخواست در حال پردازش یا keep-alive نداشته باشن خودشون رو terminate میکنن و دارفانی رو وداع میگن

پس میتونیم بگیم لود کردن کانفیگ جدید همون لحظه اعمال نمیشه و با توجه به بار سیستم بارگذاری میشه

@knowpow

چرا NGINX انقدر سریعه؟!
بخش چهارم: Non Blocking I/O

--------------------------------------

توی بخش قبلی فهمیدیم تردها چی هستن و رفتار NGINX در مقابل اونا چیه؟! در مورد worker processes نوشتم و چرایی وجود اونارو با هم بررسی کردیم، توی این پست در مورد NonBlocking I/O مینویسم.


خب توی این پست فهمیدیم که اصلا چرا block میشیم و گفتیم که راه حلمون استفاده از non blocking هست، اما چطور؟ عملا non blocking به هر کاری گفته میشه که برای ورودی خروجی بدون block کردن پروسس انجام میشه.

در حقیقت توی مدل non blocking وقتی ما یک درخواست I/O از کرنل میکینم، اگر امکان انجام اون درخواست به هر دلیل توی همون لحظه نباشه کرنل اون درخواست رو رد میکنه و پروسس ما بجای اینکه منتظر در دسترس بودن I/O بشه میتونه تسک های دیگه رو اجرا کنه، در عوض ما باید دوباره همون تسک رو از کرنل درخواست کنیم یا با مکانیزم های پولینگ زمانی که مناسب بود خبر دار بشیم، این روش کمک میکنه ما زمان سی‌پی‌یو رو صرف منتظر موندن نکنیم و ازش کار مفید بگیریم.

فرض کنید اپ ما فقط یک پروسس داریم و یک سوکت باز کردیم و بعد از non block کردن اون تلاش میکنیم که به ادرس سرور وصل بشم، اگر ارتباط همون لحظه نتونه برقرار بشه کرنل همون لحظه بهمون ارور برمیگردونه و فیلد errno رو به EINPROGRESS ست میکنه، به این معنی هست که تنها پروسس من منتظر وصل شدن سوکت به سرور نمیشه، چون اینکار پتانسیل بلاک کردن ترد اپ رو داره.

حالا فرض کنید ما میخواییم زمانی که ارتباط با سرور برقرار شد شروع به ارسال داده به سرور کنیم، همونطور که گفتم سوکت رو non blocking کانکت میکنیم و توی هی لوپ که بهش busy loop هم میگن وضعیت سوکت رو بررسی میکنم، بعد از وصل شدن شروع به ارسال داده میکنم و از اونجا که ارسال داده هم به صورت non blocking انجام میگیره باید توی یه لوپ دیگه کنترل کنم که آیا کرنل تونسته داده رو ارسال کنه یا درخواست رو رد کرده تا مجدد تلاش کنیم؟!
شاید اینجا از خودتون بپرسین که خب درسته ما الان بلاک نمیشیم ولی داریم با لوپ هایی که برای کنترل در دسترس بودن I/O میکنیم کار بیهوده انجام میدیم، روشی هست که کرنل وقتی سوکت در دسترس بود به ما خبر بده؟ اینجا دقیقا همون نقطه ای هست که پروسس ما باید از مکانیزم های Polling یا Callbacks استفاده کنه تا حین انجام تسک های دیگه از وضعیت I/O هم با خبر بشه.

برگردیم به NGINX، در حقیقت پروسس های ورکر NGINX هر کدوم یه لوپ هستن که با استفاده از مکانیزم پولینگ به صورت نان بلاکینگ کانکشن های جدید رو قبول و داده هارو پردازش
میکنند.

پست بعدی تمرکز کامل روی نحوه ی انجام همین کار توسط NGINX خواهد بود

@knowpow

این پستای انجین‌ایکس رو ریختم توی مدیوم:

https://engineering.teknasyon.com/nginx-in-linux-systems-performance-and-internal-mechanisms-04c1ba1fb730

@knowpow

کد زدن این پروژه رو شروع کردم و اینجا هم کامیت به کامیت توضیح میدم، تا الان چیز خاصی نوشته نشده و فقط برای هر هسته‌ی CPU یه پروسس ساخته میشه، کامیت بعدی باز کردن سوکت روی هر ورکر و شاردینگ اون ها روی یک پورت هست، ریپوی گیت هاب:

https://github.com/aabolfazl/Vortex

چرا NGINX انقدر سریعه؟!
بخش پنجم (آخر): Event Driven I/O

--------------------------------------

توی پست قبلی گفتم که مدل نان بلاکینگ چیه، توی بخش اخر این سری پست ها میخوام در مورد ساختار ورکرها صحبت کنم.

قبلا هم گفتم که وب سرور های سنتی مثل اپاچی از پترنی به اسم thread per connection استفاده میکنند، یعنی برای هر رکویستی که از سمت کلاینت ارسال میشه یک ترد میسازند و کارهای مربوط به اون رکویست رو توی اون ترد انجام میدن، همونطور که قبلا هم گفتم این ساختار مزیت هایی مثل سادگی توی پیاده سازی و راحتی دیباگ کردن رو داره، ولی از دید سیستم اصلا چیز جالبی نیست،‌ سیستم عامل برای هر تردی که باز میکنه باید مموری جدیدی تخصیص بده،‌ اطلاعات اون ترد رو نگهداره و دائم بین بقیه ی ترد ها context switching انجام بده، عمل context switching اصلا چیزی نیست که ما بخواییم ماشینمون به صورت مکرر باهاش درگیر بشه، چرا؟ جواب

توی این معماری میتونیم بگیم که تردها اکثر زمانشون صرف بلاک شدن یا همون منتظر موندن هستن، و ما میدونیم اصلا منتظر موندن I/O چیزی نیست که بخواییم پروسس ما انجام بده، در حقیقت ما داریم ریسورسی رو از سیستم عامل میگیریم به اسم ترد، و باهاش I/O خود کرنل رو مشاهده میکنیم! اگه پست های قبل رو خونده باشین میدونین که چرا میگم این اصلا خوب نیست، حالا بجاش سیستم عامل میاد میگه اقا تو برای هر I/O ای که داری ترد نساز و با بلاک کردن اون وقت CPU‌ من رو نگیر، بجاش من برات یه مکانیزمی رو فراهم میکنم که هروقت I/O اماده بود تو متوجه بشی. خب خوبه دیگه؟ هم ترد برای کرنله،‌ هم I/O پس همه چی رو میدونه، دیگه لازم نیست برای هر کانکشنی که داریم یه ترد بسازیم تا وقتش رو صرف منتظر موندن I/O کنه.

اسم این مکانیزم رو کرنل میزاره ePoll. مکانیزم های قدیمی هم توی کرنل وجود دارن مثل poll , select, signal که تفاوت هایی توی عملکردشون وجود داره،‌ ولی انچه خوبان همه دارن رو ePoll همه یکجا داره.

کاری که NGINX میکنه چیه؟ خیلی جالبه اینجا NGINX میاد برای پروسس های ورکر یه سوکت باز میکنه و اماده میشه برای accept کردن کلاینت جدید، همون سوکت رو به ePoll میده و میگه اقا/خانم کرنل من دیگه همه چی رو میسپارم به شما، هر وقت اتفاق جدیدی توی این سوکت افتاد به من خبر بده،‌ بعد متد epoll_wait رو صدا میزنه و منتظر کرنل میمونه، کرنل این سوکت رو به لیست خودش اضافه میکنه و هروقت تغییری روی این سوکت داشته باشه اون رو به پروسس ورکر میگه.

بعد از اینکه پروسس ورکر کلاینت جدید رو قبول کرد، خود سوکت کلاینت رو هم به لیست ePoll اضافه میکنه و دوباره همه چی رو به کرنل میسپاره، اگه چندین هزار تا کلاینت هم وصل بشن بازم ما ۱ ترد داریم که همشون رو مدیریت میکنه، هر کدوم از این چندین هزار کلاینت خواست چیزی بنویسه روی سوکت ما یا ما چیزی خواستیم بهش برگردونیم همش با event هایی که از طریق کرنل میاد انجام میشه.

اگه مرحله به مرحله بخوام بگم، پروسس ورکر کانکشن باز میکنه و شروع میکنه به گوش کردن،‌ بعد همون سوکت رو به ePoll میده و منتظر کانکشن جدید میشه، وقتی کسی بخواد به سوکت ورکر وصل بشه کرنل به ورکر ایونت میفرسته و ورکر اون کلاینت رو accept میکنه و همون کانکشن کلاینت رو هم به لیست ePoll اضافه میکنه و دوباره منتظر ایونت بعدی میمونه، بعد از اینکه کانکشن برقرار شد کلاینت متوجه میشه و شروع میکنه به ارسال داده، کرنل اینجا میبینه از یه سوکت داده اومده و اون سوکت توی لیست انتظار ePoll پروسس NGINX قرارداره،‌ پس یه ایونت به پروسس ورکر NGINX میفرسته و میگه که از کانکشن x داده ی جدید داری، بعد پروسس ورکر از حالت بلاک که توسط epoll_wait شده بود در میاد و از اون کانکشنی که کرنل بهش گفت شروع میکنه به خوندن داده، بعد از اینکه تمام داده رو خوند، اون رو به کانکشن سرور بالادستی(حواستون باشه که ما اینجا لودبالانسریم) میده و دوباره همون کانکشن سرور بالادستی رو هم به لیست ePoll اضافه میکنه و دوباره منتظر ایونت جدید میمونه، بعد از اینکه سرور بالادستی جواب رو اماده و به سوکت ورکر ارسال کرد کرنلی که روش NGINX داره ران میشه دوباره متوجه میشه و مثل قبل به پروسس ورکر خبر میده ولی اینسری با سوکتی که روی سرور مقصد باز کرده،‌ حالا ورکر داده رو میخونه و به کلاینتی که درخواست داده بود برش میگردونه.

بخش دو:

حواستون باشه دیگه داریم با event ها بازی میکنیم، هر اتفاقی ممکنه بیوفته،‌ یعنی دیگه پروسس من منتظر خوندن داده، اماده شدن و... سوکت نمیشه، در حقیقت پروسس من منتظر ایونتی از سمت کرنل میشه که برای اون سوکت‌ها میوفته، ممکنه بعد از اینکه پروسس ما اطلاعات رو به سرور مقصد فرستاد یه کلاینت جدید بخواد وصل بشه! خب مشکلی نیست کرنل ایونتش رو میده و ما هندلش میکنیم، ولی توی پترن thread per connection پروسس ورکر برای هر کانکشن یه ترد باز میکرد و ولش میکرد به امون کرنل تا وقتی که کارش تموم بشه.

به این معماری میگن معماری Event driven که به خوبی چندین هزار کانکشن رو فقط و فقط روی یه پروسس یا همون ترد مدیریت میکنه.

نکته: توی مدل لینوکسی ترد با پروسس هیچ تفاوتی نداره، تنها امتیازی که ترد داره و توانایی دسترسی به مموری تردهای دیگه یا shared memory هست،‌ پس هر وقت توی این سری پست ها گفتم ترد منظورم میتونه پروسس هم باشه، چون پروسس هم یه ترد محسوب میشه که ID اون برابر با PID هست.

خب این سری پست ها هم تموم شد، ولی اصلا هدف از نوشتن اینا چی بود؟ توی پست بعد میگم، مانا باشید.

@knowpow

برای بخشی که گفتم: اکثر وب سرورها برای هر رکویستی که دریافت میکنند یک ترد یا یک پروسس بهش اختصاص میدن، این کار از لحاظ پیاده سازی فنی آسونه و پیچیدگی کمی داره،‌ ولی یه مشکل اساس وجود داره اینکه هر ترد بیشتر زمانش رو صرف منتظر موندن از I/O میکنه، یا منتظر آماده شدن سوکتی هست که روش باز شده تا دیتا بخونه، یا منتظره تا سوکتی که برای سروری origin باز کرده اماده ی نوشتن بشه.

@knowpow

برای بخشی که گفتم:

نگهداری ترد ها برای سیستم‌عامل هزینه ی بالایی دارن، اولین هزینه ای که اینجا من بهشون اشاره میکنم انجام contex switching روی ترد ها توسط CPU هست، contex switching زمانی اتفاق میوفته که سیستم‌عامل cpu رو از یک ترد بگیره و به ترد دیگه ای بده. برای اینکار سیستم عامل باید اطلاعات فعلی که ترد داره (مثل کانتر برنامه، اطلاعات رجیستر، مموری الوکیت شده و..) رو ذخیره کنه و اطلاعات ترد بعدی روی روی سیستم لود کنه،‌ برای همین اینکار هزینه ی محاسباتی بالایی داره و وقتی خیلی زیاد انجام بشه میتونه لود سیستم رو ببره بالا.

@knowpow

Long story short, NGINX is fast because:
It uses a non-blocking, event-driven, and asynchronous architecture.

@knowpow

طبق حرفی که اقامون فایمن میزنه:

چیزی که نتونم بسازم، همون چیزیه که نمیتونم بفهمم

همون اول که شروع کردم به نوشتن این پست ها گفتم که قرار بود یه پروژه برای عمیق شدن توی مفاهیم شبکه بزنم و سی++ بزنم، چند روزی میشه که پروژه رو شروع کردم و چند روز یه بار یه کامیت میزنم و اینجا توضیحش میدم.

دارم یه لود بالانسر مینویسم که قراره توی نسخه ی اول توی لایه‌ی ۴ باشه و ترافیک رو به سرورهای بالا دستی روت کنه.

لینک ریپوی پروژه:
https://github.com/aabolfazl/Vortex

@knowpow

جالبه بیتکوین هنوز برای فهمیدن اینکه کی باید از سوکت بخونه داره از (2)select و poll() استفاده میکنه:

https://github.com/bitcoin/bitcoin/blob/master/src/util/sock.cpp#L223


@knowpow

ارتباط بین کرنل و کارت شبکه NIC

امروز یه چیز جالبی در مورد کرنل خوندم و این بود که توی کرنل های قبل ۲.۶ هر بار که پکت جدیدی توسط کارت شبکه دریافت میشه، کارت شبکه (NIC) پکت داده رو روی مموری میزاره و وجود پکت رو با اینتراپت به کرنل خبر میده، کرنل با این اینتراپت متوجه وجود پکت جدید میشه و شروع میکنه به خوندن داده، خیلی هم عالی، مشکل کجاست؟!
مشکل وقتی بوجود میاد که ترافیک دریافتی میره بالا و تعداد این اینتراپت ها زیاد میشه و توی کار CPU تداخل ایجاد میکنه. (اگه نیاز هست بگم که هر اینتراپتی که اتفاق میوفته CPU رو مجبور میکنه هر تسکی که داره رو ول کنه و به اینتراپت رسیدگی کنه)

حالا جالبترم میشه، یه حالت دیگه هم وجود داره که کرنل دوره ای کارت شبکه رو چک میکنه و میبینه اگه دیتای جدیدی برای پردازش بود اون رو پردازش میکنه، به این حالت هم میگیم Polling مشکل مورد اول اینه که وقتی ترافیک ورودی از یه حدی زیادتر میره CPU زیر بار اینتراپت میمونه و به اصطلاح Interrupt storm اتفاق میوفته، مشکل مورد دوم هم اینه که latency نسبتا بالایی داره، یعنی اگر کرنل بیاد و هر ۱۰۰ میلی ثانیه قرار باشه که NIC رو چک کنه و یک پکت توی ۷۰ ام میلی ثانیه اماده‌ی پردازش باشه باید ۳۰ میلی ثانیه منتظر تشریف اوردن کرنل بشه.
حالا چطور مشکل رو حل کردن؟ اومدن گفتن اقا ما بیاییم یه Api جدید بنویسیم و اسمش رو بزاریم NAPI و بهش بگم با توجه به ترافیک ورودی بیا و بین حالت اول که interrupt driven هست و مورد دوم که polling هست سوییچ کن، یعنی NIC بیا و ببین وقتی ترافیک بالا نیست روی interrupt باش و وقتی ترافیک حد تعیین شده رو گذشت به polling سوییچ کن جالب شد نه؟ اره ولی‌ ما هنوز مشکل interrupt storm و latency رو حل نکردیم، فقط اومدیم داینامیک کردیم سیستم رو تا بین این حالات سوییچ کنه، پس میاییم با تلفیق این دو مدل چندتا حالت دیگه هم تعریف میکنیم و میگیم که وقتی کارت شبکه اینتراپتی تولید کرد، به یک هسته توی CPU نره و اون رو بین هسته های دیگه هم توزیع بکنه، به این روش میگن Receive Packet Steering (RPS).

روش دیگه استفاده از یک اینتراپت برای پردازش چندین پکت داده اس، یعنی وقتی یه پکت داده وارد NIC میشه و NIC اون رو اماده میکنه،‌ همون لحظه اینتراپت نمیده و صبر میکنه چون احتمال اومدن پکت های دیگه هست، و بعد از مدتی دستور اینتراپت رو میده، اینجا مشکل storm حل شد ولی بازم مشکل latency رو داریم.

روش اخر و فوق العاده جالبی که من رو واقعا شیفته ی خودش کرد این بود که کارت شبکه مستقیم دیتا رو توی کش cpu میزاره و تمام. Cpu میاد و بدون هیچ اینتراپتی داده رو میخونه. به این روش Direct Cache Access (DCA) میگن. اینجا دیگه نوشتن روی مموری توسط NIC حذف شده و مستقیم توی کش cpu نوشته میشه.

روش های متعدد دیگه ای هم هست که من باهاشون حال نکردم اما ایده‌ی اصلی تمامی این روش ها بازی کردن با دوتا مفهوم آشنای دنیای مهندسی نرم افزار به اسم های Inversion of Control (IoC) که میگه تو از من چیزی نپرس، خبری شد خودم بهت میگم و Polling که میگه من نمیتونم بهت خبر بدم، خودت مکرر باید ازم بپرسی هست، به عبارتی یا کرنل باید از کارت شبکه بپرسه که چیز جدیدی برای پردازش داری؟! یا کارت شبکه به کرنل خبر بده که داده‌ی جدیدی برای پردازش دارم.

حین اینکه کرنل و کتابهای مرتبط رو میخونم این چند روز سعی میکنم بیشتر در موردش پست بزارم

@knowpow

گذشته رو میدونیم ولی نمیتونیم تغییرش بدیم، آینده رو نمیدونیم ولی میتونیم کنترلش کنیم.

همتون میدونین جبر بولی چیه ولی نمیدونین که کلود شانون اولین کسی بود که از جبر بولی توی طراحی کامپیوتر استفاده کرد.

@knowpow