وبسایت شخصی حسن هاشمی

برنامه نویس. ایران. قم :))

مباحثی در مورد thread ها در asp.net

حس مقدمه نویسی نیست :) یه راست میرم سر اصل مطلب :)

اول بذارید از نحوه دریافت request توسط web server شروع کنیم:

همونطور که توی پست "مروری بر معماری http" نوشتم، یه http request در اصل یه tcp connection ساده هست پس در نتیجه یه سوکت از کلاینت به سرور باز میشه و reponse هم روی همون نوشته میشه اما نکته اینه که خود iis که response رو نمینوسه :) و باید request رو انتقال بده به application ی که در واقع handler برای این Request هست. نکته  اینه که حافظه IIS از نوع User-Mode هست.

توی این متن منظور از لفظ web server برنامه هایی مشابه IIS, Apache, Nginx و .. هستن

 برای انتقال request  به برنامه شما که php یا asp هست و در یک application pool  مجزا و به صورت isolate شده در حال اجراست اول thread باید به حالت kernel mode سوئیچ کنه این یعنی ی�� بار بافر توی حافظه کرنل کپی بشه و یه بار دیگه از حافظه کرنل به حافظه برنامه شما سوئیچ بشه. و این خودش در حجم بالا مشکل زیادی داره.

برای حل این مشکل 2 کار لازمه : 

اول اینکه IIS و Apache تا حد زیادی Thread های خودشون رو برای serve کردن فایل های استاتیک مثل عکس و text بهینه سازی می کنند.

ولی برای حل مشکل دوم که این context switch های مداوم بین user-mode و kernel-mode هستش از دست web server کاری برنمیاد در این نقطه سیستم عامل ها خودشون برای تسهیل این کار یه سری درایور پیش فرض در فضای kernel پیاده سازی می کنن که اینکارو انجام بده (دریافت درخواست http) به عنوان مثال برای سیستم عامل ویندوز اسم این درایور http.sys هستش.

با این حساب وب سرور های امروزی مثل IIS و Apache دیگه مستقیماً خودشون را تا حد زیادی با سوکت و مباحث مربوط به IPC درگیر نمی کنن.


در نتیجه اگه بخوایم یه جمع بندی تا الان داشته باشیم:

1- در اولین قدم که request به سرور میرسه، توسط http.sys دریافت میشه.

2- request بعد به iis ارسال میشه و در این نقطه یه thread از thread-pool خود iis اون رو دریافت می کنه.

3- تو این نقطه این thread ممکنه یه درخواست در صورت امکان پایان بده، مثلا درخواست یه عکس بوده. و apache یا IIS هم برای پاسخ به این نوع درخواست ها خیلی بهینه هستن.

4- حالا اگه درخواست به این نقطه برسه مثلا فرض کنید درخواست /home/default.aspx بوده. وب سرور درخواست رو به asp.net منتقل می کنه و asp.net هم درخواست رو به Request Queue خودش ارسال می کنه. و اتقاقی که بعد ازون میفته اینه که native thread ی که درخواست رو اول درخواست کرده بود آزاد میشه و request های بعدی رو دریافت می کنه.

5- حالا این Request های توی queue توسط thread های CLR به ترتیب سرویس دهی میشن.

6- این سرویس دهی یعنی اجرای کد برنامه asp.net شما و معنی دیگه ش این هست که این thread به هیچ وجه نمیتونه درخواست دیگه ای که به queue اضافه میشه رو پردازش کنه. (این نکته خیلی مهم هست، بخاطر اینکه اگه ما یه جوری بتونیم این Thread رو بهینه تر استفاده کنیم نتیجه ش این هست که می تونیم به درخواست بیشتری پاسخ بدیم)

و اینجا جائیه که پای async میاد وسط ..


من دیگه سنم رفته بالا و حال نوشتن پست های بلند رو ندارم، so.... :)

فقط یه نکته پایانی رو یکی دوستان ازم پرسید و اونم درایور http برای لینوکس هست، نکته اینه که لینوکس سیستم عاملی هست که معماری خیلی متفاوتی نسبت به ویندوز داره و بخاطر نحوه انتقال به  فضاهای مختلف توی حافظه (منظور انتقال بین 2 فضای کاربر و کرنل توی هر system call) نیاز چندانی به درایور http در سطح کرنل نداره.

نظرات (1) -

Loading