چرا NGINX انقدر وحشتناک سریعه؟!
بخش دوم: Blocking I/O
توی بخش قبلی فهمیدیم که NGINX ترافیک روتینگ رو توی لایه‌ی چهار و لایه‌ی هفت مدل OSI انجام میده و از مدل Reverse Proxy استفاده میکنه ./
بخش دوم: Blocking I/O
توی بخش قبلی فهمیدیم که NGINX ترافیک روتینگ رو توی لایه‌ی چهار و لایه‌ی هفت مدل OSI انجام میده و از مدل Reverse Proxy استفاده میکنه ./
https://twitter.com/_AbolfazlAbbasi/status/1760959876166045861
حالا باید بدونیم چطور NGINX چندین هزار رکویست رو در لحظه میتونه مدیریت کنه؟!
خب NGINX میاد از Nonblocking I/O برای مدیریت کانکشن ها استفاده میکنه، ولی من اول میخوام بریم ببینیم که اصلا Blocking I/O چیه که Nonblocking I/O هم وجود داره؟ اصن چرا باید بلاک بشه چیزی؟ ./
خب NGINX میاد از Nonblocking I/O برای مدیریت کانکشن ها استفاده میکنه، ولی من اول میخوام بریم ببینیم که اصلا Blocking I/O چیه که Nonblocking I/O هم وجود داره؟ اصن چرا باید بلاک بشه چیزی؟ ./
زمانی که برنامه ای میخواد به IO دسترسی پیدا بکنه باید یه سری فرایند رو بگذرونه که این کارها زمانبره و به صورت blocking انجام میشه، یعنی فرض کنید اگر برنامه‌ای میخواد یک فایلی باز کنه تا اون رو بخونه باید فرایند زیر رو طی کنه: ./
۱- سیستم کال: باید درخواست باز کردن فایل رو با سیستم کال open بدین
۲- تغییر حالت CPU: کرنل برای اینکه بتونه این درخواست رو پردازش کنه نیاز داره که CPU رو به حالت کرنل تغییر بده (سوئیچ ضروریه و دسترسی مستقیم به سیستم فایل و سخت افزار کاری محسوب میشه که فقط کرنل مجازه انجام بده) ./
۲- تغییر حالت CPU: کرنل برای اینکه بتونه این درخواست رو پردازش کنه نیاز داره که CPU رو به حالت کرنل تغییر بده (سوئیچ ضروریه و دسترسی مستقیم به سیستم فایل و سخت افزار کاری محسوب میشه که فقط کرنل مجازه انجام بده) ./
۳- صحت سنجی آدرس: اول کرنل شروع میکنه ببینه ادرس فایلی که دادین درسته بعد هم چک میکنه ببینه که آیا شما مجازین که این کار رو انجام بدین یا نه
۴-تخصیص فایل: در نهایت اگه مراحل قبل موفق باشه، کرنل یه file handler یا file descriptor به این فایل تخصیص میده ./
۴-تخصیص فایل: در نهایت اگه مراحل قبل موفق باشه، کرنل یه file handler یا file descriptor به این فایل تخصیص میده ./
۵- بررسی قفل فایل: کرنل اینجا چک میکنه ببینه کسی قبل از شما این فایل رو قفل کرده یا نه و اگه کسی نباشه به این فایل یک lock در نظر میگیره و فایل رو باز میکنه ./
۶-بازگشت توصیفگر فایل: بعد از باز کردن فایل، کرنل file descriptor رو بعد از اینکه CPU به حالت یوزر برگشت به شما برمیگردونه و شما باقی کارها رو با اون file descriptor انجام میدین ./
خب این مسیر کلی بود که پروسس شما برای باز کردن یه فایل ساده انجام میداد، الان میخوام بگم کدوم مراحل ممکنه پروسس شمارو بلاک کنه و بیشتر از طبق معمول طول بکشه، تغییر حالت CPU از کرنل به یوزر یه کار هزینه بره ولی چون توی همه‌ی سیستم کال ها اینکارو انجام میدیم دیگه درنظرش نمیگیرم ./
حالا توی مرحله ی ۳ اگه ادرسی که دادین روی یه هارد مکانیکی باشه یا روی دیسکتون بار خوندن و نوشتن بالایی وجود داشته باشه میتونه اینکار بلاک بشه، توی مرحله ی ۳ چک کردن دسترسی ها نیازی به کار خاصی نداره و سریع انجام میشه، توی مرحله ی ۴ هم کارا سریع انجام میشن ولی اگه کرنل به حد ./
مجاز توصیفگرهای فایل(file descriptor)هایی که باز هستن نزدیک بشه و نیاز به مدیریت و تخصیص مجدد ریسورس داشته باشه ممکنه بیشتر از حد معمول طول بکشه
توی مرحله ی ۵ هم پتانسیل بلاک شدن وجود داره چون اگر پروسس دیگه ای فایل رو قفل کرده باشه، کرنل باید منتظر آزاد شدن قفل باشه که طبیعتا./
توی مرحله ی ۵ هم پتانسیل بلاک شدن وجود داره چون اگر پروسس دیگه ای فایل رو قفل کرده باشه، کرنل باید منتظر آزاد شدن قفل باشه که طبیعتا./
منتظر موندن کرنل یعنی بلاک شدن پروسس ما.
توی مرحله‌ی اخر تنها کاری که مجبوری انجام بدیم و بازگشت به حالت کاربر هست و تمام
جمع بندی: ./
توی مرحله‌ی اخر تنها کاری که مجبوری انجام بدیم و بازگشت به حالت کاربر هست و تمام
جمع بندی: ./
هر کاری که نیاز به I/O داشته باشه به احتمال خیلی زیاد پروسس شمارو بلاک میکنه و باید منتظر تموم شدن کاری که درخواست کردیم باشیم، چرا گفتم به احتمال خیلی زیاد؟! چون توی حالت عادی که باری روی سیستم نیست تمامی باس های داده خالیه و همه میتونن راحت رفت و آمد کنن، ولی وقتی بار سیستم ./
میره بالا و باس های داده مثل اتوبان کرج-تهران میشه و دیگه همه چی مثل قبل نیست، باید برای باز کردن فایل که یه کار ساده محسوب میشه صبر کنیم و پروسسمون رو بلاک کنیم، و این اصلا برای سیستسم خوب نیست. دقت کنید که ما حاضریم هزینه ی انجام دادن تسک رو بدیم ولی نباید ریسورس سیستم رو ./
برای کاری مثل منتظر موندن برای خلوت شدن باس داده یا در دسترس بودن lock انجام بدیم، اینکاره که سیستم رو کند میکنه، مگر نه من اگه بخوام یه فایل یه میلیون سطری رو بخونم هیچ چاره ای ندارم جز اینکه خط به خط این فایل رو بخونم و هزینه ی این تسک رو باید بدم چون هیچ راه فراری وجود نداره./
غیر از اینکه خط به خط فایل خونده بشه، ولی میتونم یه مکانیزم استفاده کنم که سیستم رو منتظر باز شدن قفل فایل، ازاد شدن باس داده و هرچیز دیگه ای نکنم! اسم این مکانیزم Nonblocking I/O هست که توی پست های بعدی صحبت میکنم در موردش.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
