مقایسه Kestrel و IIS در ASP.NetCore

مقایسه Kestrel و IIS در ASP.NetCore

نزدیک به 2 سال است که از انتشار اولین سری از ASP.NetCore 2.2 می‌گذرد. نسخه‌ای که تحولی بزرگ در سرعت و عملکرد این فریم‌ورک ایجاد کرد. تا پیش از آن Asp.NetCore فقط از Kestrel به عنوان وب سرور استفاده می‌کرد. وب سروری که با واژه سرعت همراه بود. اما بواقع اینگونه نبود!

در ویندوز یا حتی لینوکس به دلایلی که در ادامه به تشریح آن می‌پردازیم مجبور بودیم تا از یک Reverse Proxy برای ارتباط kestrel با IIS و Apache استفاده کنیم. فرایندی که با ایجاد ‌Requesهای بیشتر زمان اجرای پردازه‌ها را افزایش می‌داد به گونه‌ای که از سرعت پروژه کاسته می‌شد! اما چرا IIS یا Apache؟ مگر Kestrel خود به تنهایی چه عیبی داشت که می‌بایست IIS یا Apache را در آن دخیل می‌کردیم؟

در دات نت کور 2.2 و نسخه‌های بعدی یک معماری درون فرایند پیش‌بینی شده است. یعنی ما می‌توانیم Hosting Model را از out of process و غیر مستقیم به In Process و مستقیم تغییر دهیم. با این کار واسط Reverse Proxy حذف شده و به همین دلیل تعداد Requestها کاهش و سرعت افزایش قابل توجهی پیدا می‌کند. در این مقاله به هر دو نوع Hosting Model، تفاوت‌ها و عملکرد هر یک می‌پردازیم تا جایی که با استفاده از In Process، کِسترل را از دور خارج خواهیم کرد!

 

Kestrel چیست و چرا استفاده از آن در گذشته اهمیت داشت؟

وب سرور IIS از سال 1995 میلادی شروع به کار کرد و آن قدر پیشرفت کرد که امروزه هر آنچه به آن نیاز دارید در IIS فراهم شده و یک وب سرور حرفه‌ای و کامل محسوب می‌شود. در گذشته برای ASP.Net حتما بایستی از IIS استفاده می‌کردیم و البته راه درست نیز همین است. اما به هر دلیل یک نیاز احساس شد تا یک وب سرور داشته باشیم که Cross Platform باشد به گونه‌ای که اجازه دهد ASP.Net علاوه بر سیستم عامل ویندوز در دیگر موارد چون Linux و Mac نیز اجرا شود. پس Kestrel معرفی شد تا این بار را به دوش بکشد.

همزمان اقداماتی انجام شد تا این وب سرور نسبتا جدید بتواند سرعت خیلی خوبی داشته باشد که البته در زمان خود به آن دست پیدا کرد. اما بهتر است بگوییم در Kestrel عملکرد فدای سرعت شد! به گونه‌ای که بسیاری از پروتکل‌های مهم در Kestrel غیر قابل اجرا هستند و خیلی از قابلیت‌های اساسی پشتیبانی نمی‌شود. همین موضوع باعث شد تا Kestrel هیچگاه نتواند به عنوان یک وب سرور مستقل فعالیت کند. همیشه باید خود را به یک وب سرور چون IIS یا … متصل می‌کرد تا از ظرفیت آن‌ها برای تکامل خود استفاده کند.

جدول زیر یک مقایسه ساده بین قابلیت‌های کلیدی IIS و ضعف Kestrel نسبت به آن دارد:

  Platform StaticFiles HTTPLogs PortSharing SSL WinAuth WAS
IIS Windows Yes Yes Yes Yes Yes Yes
Kestrel Win/Mac/Linux Yes NO NO NO NO NO
  Platform APIConfig RedirectRules WebSocket FTP Compression Filtering
IIS Windows Yes Yes Yes Yes Optional Yes
Kestrel Win/Mac/Linux No NO Middleware NO Optional NO

جالب است که بدانید Kestrel حتی یک Https ساده و یا حتی FTP را پشتیبانی نمی‌کند! پس حیات آن به شدت به وب سرورهای حرفه‌ای چون IIS و … وابسته هست. یعنی همیشه باید یک Reverse Proxy وجود داشته باشد تا درخواست‌ها را از IIS بگیرد، پردازش کند و بعد به Kestrel هدایت کند. به تصویر زیر دقت کنید:

اما چه کاریه؟ اصلا چرا بیایم خودمان را به دردسر بیاندازیم و این پروسه طولانی را طی کنیم؟! میخوایم ASP.Net استفاده کنیم؟ خوب از همون IIS و ویندوز خانه اصلی اون استفاده کنیم. میخوایم ASP.NetCore استفاده کنیم؟ خوب از همون IIS و ویندوز خانه اصلی Microsoft استفاده کنیم.

در ادمه خواهیم گفت که چرا استفاده از Kestrel به خصوص برای ASP.NetCore اشتباه است!

 

In Process Hosting Model در ASP.NetCore

به دلیل ساختار ASP.NetCore و اهدافی که برای آن در نظر داشتند، این فریم ورک در ابتدا همراه با Kestrel شروع به کار کرد. تفاوتی نداشت که از ویندوز سرور استفاده می‌کنید یا لینوکس یا Mac. در هر 3 فقط با Kestrel و معماری Out of Process امکان استفاده از این فریم ورک وجود داشت.

پس علارغم معماری و بهینه سازی بسیار خوب ASP.NetCore هنوز یک سد بزرگ به اسم Kestrel وجود داشت که وابسته به Reverse Proxy بود. این مشکل تا قبل از نسخه 2.2 وجود داشت اما در نسخه 2.2 مایکروسافت یک تحول بزرگ رو کرد تا سرعت و قابلیت‌های ASP.NetCore به معنای واقعی دیده و لمس شود.

این تحول در واقع امکان انتخاب Hosting Model و معرفی IIS Http Server بود. حالا نه تنها Reverse Proxy حذف شده بلکه با استفاده از معماری In Process و تکنولوژی IIS Http Server، کسترل به طور کامل از دور خارج شد و در عین حال سرعت به بیش از 2 برابر افزایش یافت!!

سرعت دات نت کور در ویندوز و IIS به لطف In Process Hosting Model دو برابر بیشتر شده است.

دات نت کور در ویندوز و IIS دو برابر سریع تر از لینوکس و Mac می‌باشد.

 

فرایند دات نت کورد در حالت Out Of process با واسط Reverse Proxy و هدایت به Kestrel

فرایند دات نت کور در حالت In Process بدون Kestrel و بدون Reverse Proxy

در ASP.NetCore 2.2 و نسخه های بعدی، In Process Hosting Model در IIS باعث می‌شود تا دات نت کور به صورت مستقیم در IIS و از طریق Application Pool با استفاده از تکنولوژی IISHttpServer بدون نیاز به Proxy و کِسترل، با سرعت بالا اجرا شود.

در گذشته و در حالت Out Of Process، بخش Application Pool هیچ دخالت موثری در اجرای ASP.NetCore نداشت.

با این ویژگی عملکرد دات نت کور به گونه‌ای شگفت انگیز افزایش می‌یابد و سرعت اجرا مطابق با تست‌های انجام شده که در ادامه ذکر می‌شوند به بیش از 2 برابر افزایش پیدا می‌کند.

جالب این است که مایکروسافت برای استفاده از این ویژگی کار را بسیار راحت کرده است. کنترل Hosting Model با یک قطعه کد ساده در فایل web.config فراهم شده است!

 

In Process یا Out Of Process؟ کدام انتخاب ما باشد؟

با مطالبی که گفته شد به نظر می‌رسد جواب این سوال کاملا مشخص است. بله درست حدس زدید: In Process
طبیعیست که با حذف واسط‌هایی چون Proxy و Kestrel دیگر Requestهای اضافی ایجاد نخواهند شد و IISHttpServer خود همه کارها را انجام می‌دهد.

البته ممکن است در مواقعی انتخاب شما Out Of Process و Kestrel باشد. مانند مواقعی که بخواهید پروژه خود را Debug کنید یا برای شما مهم باشد که پروژه خود را در سیستم عامل‌های لینوکس یا Mac اجرا کنید.
اما در هر حال اگر هدف شما سرعت، کیفیت و عملکرد بالاست، پس 100% باید حالت In Process و ویندوز را برگزینید.

لازم به ذکر است که اگر از نسخه‌های جدید ASP.NetCore چون 3 و 3.1 استفاده می‌کنید، باید بگوییم که به صورت پیشفرض In Process فعال می‌شود. اما اگر از نسخه‌های قدیمی استفاده می‌کنید کافیست با استفاده از تنظیمات زیر حالت In Process را فعال کنید.

هاست دات نت کور با قابلیت پشتیبانی از دات نت کور 3.1 و سایر موارد

 

تنظیمات In Process در ASP.NetCore

تغییر Hosting Model بسیار آسان است. کافیست تغییرات زیر را در فایل web.config یا فایل .csproj ایجاد کنید.

تغییر در تنظیمات پروژه

با استفاده از تگ <AspnetCoreHostingModel> کد زیر را در فایل پروژه (Web Project’s File .csproj) قرار دهید.

<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>

اگر تگ AspNetCoreHostingModel در فایل پروژه وجود نداشته باشد به آن معناست که به صورت پیشفرض حالت Out Of Process در نظر گرفته می‌شود.

این تنظیم باعث می‌شود تا dotnet Publish فایل web.config را بر اساس In Process ایجاد کند.

تغییر در فایل web.config

تنظیم AspNetCoreHostingModel در فایل پروژه، باعث می‌شود تا فایل web.config در Publish یا خروجی پروژه به شکل زیر ساخته شود:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" />
</handlers>

<!-- hostingModel is the new property here -->
<aspNetCore processPath="dotnet" arguments=".\WebApplication1.dll"
stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"
hostingModel="InProcess" />

</system.webServer>
</location>
</configuration>

در واقع Hosting Model به تگ اضافه می‌شود.

اگر مقدار تگ در فایل پروژه Out Of Process تنظیم شود و یا اصلا تگ را درج نکرده باشید، فایل web.config بدون درج Hosting Model ایجاد می‌شود.

توجه کنید بعد از Publish پروژه برای تبدیل Hosting Model کافیست کد hostingModel=”InProcess” را در web.config حذف یا اضافه کنید. به عنوان مثال در هنگام Debugging این کد را حذف کنید تا در حالت Out Of Process امکان Debug بهتر فراهم شود. سپس می‌توانید دوباره کد را اضافه کنید تا In Process فعال شود. به همین سادگی!

 

اطلاعات بیشتر: تحلیل استفاده از IIS

تا اینجا از مزایایی In Process و جایگزینی IIS با Kestrel سخن گفتیم. اما در ادامه می‌خواهیم به تحلیل این موضوع با جزییات بیشتر بپردازیم. اگر به جزییات علاقه دارید به ادامه مقاله توجه کنید…

برای درک بهتر ابتدا به چگونگی میزبانی ASP.Net Core در ویندوز و IIS و نحوه فعالیت آن در این سیستم قدرتمند می‌پردازیم.

 

یک برنامه ASP.Net Core چیست و چگونه کار می کند؟

هنگامی که شما یک برنامه ASP.NetCore می‌سازید در واقع یک برنامه مستقل (Standalone Console application) ایجاد می‌کنید که با dotnet .\MyApplication.dll کار می‌کند. هنگامی که شما یک برنامه کنسول را اجرا می‌کنید، پلتفرم ASP.NetCore وب سرور Kestrel را به طور مستقل در دل برنامه نگهداری می‌کند تا در موقع لزوم از آن استفاده کند.

برنامه‌ها یا اپلیکیشن‌های ساخته شده با ASP.NetCore از یک وب سرور سرخود به نام Kestrel برخوردار هستند که آن را در دل خود جای داده‌اند.

 

چرا IIS باید همزمان با Kestrel کار کند؟ مگر Kestrel مستقل نیست؟!

به طور کلی در ویندوز برای اجرای برنامه‌های تحت وب معمولا از IIS به عنوان Front End Server استفاده می‌شود به همین دلیل Kestrel نمی‌تواند به صورت مستقیم درخواست‌ها را دریافت و به موتور ASP.NetCore هدایت کند.

از طرفی درست است که Kesterl تا حدودی شبیه یک وب سرور عمل می‌کند اما در فضای اینترنت یک وب سرور به معنای واقعی محسوب نمی‌شود. به عبارت بهتر می‌توانیم آن را یک Edge Server نامگذاری کنیم که وظیفه دارد تا داده‌های بسیار مشخص و محدودی را با وظایف کنترل شده پردازش کند.

به طور خلاصه، Kestrel برای یک برنامه با سناریوی مشخص بهینه سازی شده و لذا نمی‌تواند همه جوانب را مثل یک وب سرور شناسایی، پردازش و هدایت کند. از مهمترین مواردی که از پشتیبانی Kestrel خارج است می‌توان به عناوین زیر اشاره داشت:

Port Sharing:
در Kestrel نمی‌توان چند برنامه یا وبسایت را بر روی یک پورت مشخص اجرا کرد. مثلا نمی‌توانید چند وبسایت را همزمان بر روی پورت 80 اجرا کنید!

Lifetime Management:
اگر برنامه خود را بدون هیچ زیرساخت پشتیبانی اجرا کنید، هر گونه خرابی، وقوع خطا یا Crash می‌تواند منجر به توقف برنامه و Shut Down شدن وبسایت یا پروژه شود.

بنابراین شما به ساختاری نیاز دارید تا آن‌ها را مانیتور کند و در چنین مواقعی مکانیزمی وجود داشته باشد تا برنامه دوباره و به طور اتوماتیک شروع به کار کند. IIS با قابلیت Lifetime Management براحتی در چنین مواقعی اقدام به Restart خودکار Application Pool می‌کند تا برنامه دوباره اجرا شود. Kestrelاین قابلیت را ندارد.

Static File Serving:
Kestrel نمی‌تواند فایل‌های استاتیک را به خوبی مدیریت کند. در مقابل در IIS؛ مدیریت، ذخیره و فشرده سازی فایل‌های Static با بهترین شیوه انجام می‌شود. بنابراین Kestrel در این بخش حرفی برای گفتن ندارد و بسیار کند است.

SSL و SNI:
در Kestrel گواهینامه SSL و پروتکل https پشتیبانی نمی‌شود ضمن اینکه قابلیت SNI نیز به همراه Host Header از توانایی آن خارج است.

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

به همین دلیل هیچگاه نمی‌توانید Kestrel را به صورت مستقل به کار ببرید و قدرت کامل یک وب سرور سطح بالا چون IIS را فدای مواردی خاص تعریف شده در Kestrel کنید. پس با استقلال Kestrel برنامه شما با محدودیت‌های فراوانی مواجه می‌شود.

شاید بد نباشد که بگوییم همین شرایط را در لینوکس در NGINX نیز داریم. وب سروری که بواقع وب سرور نیست و نمی‌تواند خود به تنهایی فعالیت گسترده داشته باشد لاجرم به Apache متصل می‌شود تا به عنوان یک Edge Server برای داده‌هایی خاص عمل کند.

 

Out of Process Hosting

در این روش ابتدا تمامی درخواست‌ها به IIS می‌رسند بعد ASP.NetCore و ماژول‌های مربوط به آن و سپس برای اجرا به Kestrel هدایت می‌شوند.

قبل از ASP.NetCore 2.2 تنها راه میزبانی از ASP.Net Core استفاده از IIS با استفاده از مدل Out Of Process بود. در این مدل بواسطه یک Reverse Proxy وب سرور IIS تمامی Requestها را دریافت می کند و سپس هر یک را به صورت مجزا با کنسول .Net Core پردازش و جهت اجرا به Kestrel هدایت می کند. پس در 3 مرحله ابتدا IIS، سپس ماژول های ASP.netCore و در نهایت Kestrel. توجه کنید ارتباط با Kestrel یک فرایند درونی نیست بلکه IIS و ماژول‌های ASP.NetCore در IIS درخواست‌ها را به بیرون از IIS در Kestrel هدایت می کنند.

همانطور که در تصویر مشاهده می‌کنید، مدل Out Of Process اقدام به ایجاد Requestهای بیشتر و تو در تو، هم در IIS و هم در ASP.NetCore و Kestrel می‌کند. درست است که این فرایند مانند همه فرایندهای دیگر در وب و شبکه با سرعت اجرا می‌شود اما در مقایسه با اجرای مستقیم در IIS زمان بسیار بیشتری تلف می‌شود. فرایندهای رفت و برگشت، call کردن یکدیگر و مشکلاتی که در هر مرحله ممکن است ایجاد شود همه در سرعت اجرای پروژه تاثیر مستقیم دارند.

 

In Process Hosting

در مدل In Process دیگر از Kestrel استفاده نمی‌شود پس تمامی فرایندها همانند دیگر پلتفرم‌های برنامه نویسی صفر تا صد در IIS اجرا می‌شوند. با این توضیح که بخشی با عنوان IISHttpServer درون IIS وظیفه این کار را به عهده می‌گیرد. این بخش همه Requestها را دریافت و تجمیع می‌کند و سپس از طریق یک خط لوله داخلی به موتور ASP.NetCore که درون IIS می‌باشد هدایت می‌کند. ASP.NetCore آن را اجرا می‌کند و با استفاده از دامنه یا آدرس مشخص شده، نتیجه را نمایش می‌دهد.

نکته: موتور ASP.NetCore در IIS یا همان ASP.NetCore Module در حالت In Process حتما بایستی به ازای هر وبسایت یا برنامه یک Application Pool مجزا و اختصاصی داشته باشد. بنابراین هاست شما باید به ازای هر دامنه یا وبسایت یک Application Pool مجزا در اختیار شما قرار دهد.

خبر خوب اینکه در هاست ویندوز و هاست دات نت کور HiSupport این فرایند به درستی اجرا می‌شود و به هر یک از وبسایت‌ها یک Application Pool مجزا، اختصاص داده می‌شود 😊

 

هاست ایده‌آل برای In Process Hosting Model

برای استفاده از مزایای کامل In Process دقت کنید که هاست شما قابلیت‌های زیر را داشته باشد. ( در هاست ویندوز و هاست دات نت کور HiSupport تمامی موارد زیر تامین شده است):

1- Application Pool اختصاصی به ازای هر وبسایت و دامنه
2- استفاده از IIS 10 (در های‌ساپورت ویندوز سرور 2019 به همراه آخرین نسل از IIS 10 مورد استفاده قرار گرفته است.)
3- پشتیبانی از ASP.Net Core 2.2 به بالا. (در های‌ساپورت همواره ASP.NetCore در جدیدترین نسخه مورد استفاده قرار می‌گیرد. به عنوان مثال در تاریخ نگارش این مقاله نسخه 3.1.7 در تمامی سروهای HiSuppoet به بهره‌برداری رسیده است.)

حالا به همه این‌ها پنل پیشرفته Plesk Obsidian، سخت افزار بسیار قدرتمند چون پردازنده 16 هسته‌ای، هارد پر سرعت NVMe، رم از نوع DDR4 و Raid سخت افزاری را اضافه کنید. سرعت و کیفیتی بی نظیر در HiSupport با قابلیت‌های فراوان.

با استفاده از مدل جدید In Process سرعت اجرای پردازه‌ها افزایش یافته و منابع مصرفی به دلیل ارتباط مستقیم با IIS و Application Pool اختصاصی کاهش می‌یابد.

با انتخاب In Process همچنین ترافیک داخلی در بخش HTTP حذف می‌شود و به صفر تبدیل می‌گردد و Requestها بدون تاخیر به سرعت اجرا می‌شوند.

 

چگونه تشخیص دهیم که پروژه ما در کدام حالت اجرا شده است؟ Out Of Process یا In Process ؟

ممکن است از خود بپرسید خوب حالا ما همه این کارها را کردیم و انتظار داریم برنامه یا وبسایت ما در حالت In Process کار کند. چطور از این موضوع مطمئن شویم؟

سوال خوبیه. دو روش وجود دارد که روش دوم مرسوم و شفاف‌تر است:

1- بررسی از طریق سرور
چنانچه از سرور مجازی یا اختصاصی استفاده می‌کنید و امکان دسترسی به محیط سیستم عامل دارید کافیست Task Manager را در سرور باز کنید. اگر مطابق با تصویر نام پردازه مربوط به وبسایت شما به صورت dotnet.exe درج شده باشد، به آن معناست که وبسایت شما در حالت Out of Process در حال فعالیت است و In Process برای آن فعال نشده است.

همچنین در حالت Out Of Process ستون Command Line نیز نام فایل اجرایی پروژه را که معمولا به صورت exe یا dll است پس از نام dotnet درج کرده است.

2- بررسی از طریق Response Server Header

براحتی می‌توانید با بررسی Response Server Header متوجه شوید که In Process برای وبسایت شما فعال است یا Out Of Process.

کافیست برنامه یا وبسایت خود را در Chrome اجرا کنید. سپس بر روی صفحه کلیک راست کرده و به بخش Inspect و در ادامه به سربرگ network مراجعه کنید و یک بار وبسایت خود را Reload یا Refresh کنید.
با این کار لیست Requestها نمایش داده می‌شود. بر روی نام دامنه در لیست Network کایک کنید تا مطابق با تصویر در سمت راست اطلاعات Response Server Header نمایش داده شود.

اگر مقدار درج شده در بخش Server برابر Kestrel بود به آن معناست که شما از مدل Out Of Process استفاده می‌کنید. اما اگر مقدار آن IIS بود به آن معناست که مدل مورد استفاده در وبسایت شما In Process بوده و شما از حداکثر سرعت بهره‌مند هستید.

 

تست سرعت و عملکرد با آمار و ارقام

قبل از شروع تست به خاطر داشته باشید این تست نمی‌تواند به عنوان نماینده همه وبسایت یا برنامه‌ها باشد چراکه شرایط هر یک می‌تواند متفاوت باشد. اما می‌تواند نشان دهد که در شرایط یکسان توان بالقوه در In Process به طرز چشمگیری بهبود یافته است. به آن معنا که درخواست‌ها با تاخیر کمتر اجرا می‌شوند، زمان پاسخگویی سریع‌تر می‌شود و منابع کمتری مصرف می‌گردد.

برای این تست ما از یک پروژه استاندارد ASP.NET Core API استفاده کردیم که یک کلاس کوچک و ساده به آن اضافه شده و اساسا مبتنی بر یک HelloWorld است:

public class TestController : Controller
{
[Route("api/helloworld")]
public string HelloWorld()
{
return "Hello World. Time is: " + DateTime.Now.ToString();
}
[Route("api/helloworldjson")]
public object HelloWorldJson()
{
return new
{
Message = "Hello World. Time is: " + DateTime.Now.ToString(),
Time = DateTime.Now
};
}
[HttpPost]
[Route("api/helloworldpost")]
public object HelloWorldPost(string name)
{
return $"Hello {name}. Time is: " + DateTime.Now.ToString();
}
... informational requests removed
}

 

نتیجه تست در حالت Out Of Process

این نتیجه در یک لپ تاپ با پردازنده i7 12 هسته‌ای حاصل شده است. همانطور که مشاهده می‌کنید حدود 8200 درخواست در ثانیه با مدل Out Of Process اجرا می‌شود.

 

نتیجه تست در حالت In Process

حالا فقط با اضافه کردن کد زیر به web.config برای تبدیل به In Process همان تست را مجدد انجام دادیم:
hostingModel=”InProcess”

در این تست تعداد درخواست در ثانیه حدود 19000 ثبت شد. رقمی بیش از دو برابری نسبت به حالت قبل!
جالبه فقط با یک تغییر ساده و درج کد In Process در web.config سرعت اجرای پردازه‌ها بیش از 2 برابر افزایش یافت. پیشرفت از این ساده‌تر؟

فقط برای اطلاع اگر این تست را با صفحات ساده و استاتیک در مدل In Process انجام می‌دادیم عدد 50000 درخواست در ثانیه دور از انتظار نبود.

 

Raw kestrel

همچنین بد نیست یک تست فقط با Kestrel بدون Reverse Proxy و به صورت مستقل انجام دهیم. نتیجه این تست همانطور که در تصویر مشاهده می‌کنید حدود 14000 درخواست در ثانیه است!

شاید تعجب آور باشد اما حتی Kestrel به تنهایی بدون واسط و بدون اتصال به IIS هم از مدل In Process ضعیف‌تر است! Kesterl با این شعار پا به عرصه گذاشت که اول Cross Platform است به آن معنا که در سیستم عامل‌های مختلف قابل استفاده است و دوم سرعت بالا در پردازش حداقل داده‌های Dynamic دارد اما این تست نشان می‌دهد که با IIS و IISHTTPServer دیگر این ادعا معنایی ندارد!

اگر نظر ما را بخواهید برای ASP.NetCore حتما از ویندوز 2019 و IIS 10 و صد البته In Process Hosting Model استفاده کنید! پس از سلامت لاستیک‌ها مطمئن شوید و فشار باد آن‌ها را چک کنید چراکه قرار است با یک Start خیلی خوب با حداکثر سرعت حرکت کنیم 😉

درباره نویسنده
سجاد ابراهیمی
سجاد سالهاست که در حوزه وب هاستینگ و مدیریت سرور فعالیت می کند، او عاشق طبیعت، کوه نوردی و طراحی گرافیک هست و سعی می کند به عنوان هماهنگ کننده در های‌ساپورت بهترین ها را برای کاربران فراهم کند.
7 دیدگاه برای “مقایسه Kestrel و IIS در ASP.NetCore
  1. hojjat pirnia - 12 مهر, 1399 at 7:28 ب.ظ

    سلام در سایت http://www.techempower.com نتیجه تست حدود 7 میلیون درخواست در ثانیه هست شبیه آزمونی که شما انجام دادید در حالت متن ساده . چرا تفاوت اینقدر زیاده ؟
    7 میلیون در مقابل 19000 ؟
    ایا تمام این مربوط میشه به سخت افزاری که اونا استفاده کردند ؟ Dell R440 Xeon Gold + 10 GbE
    ؟
    یا به تنظیمات نرم افزاری هم مربوطه ؟

    پاسخ
    • سجاد ابراهیمی - 12 مهر, 1399 at 9:45 ب.ظ

      با سلام و تشکر از توجه شما،
      7 میلیون درخواست در ثانیه عدد بسیار بالاییست و بعید به نظر می‌رسد که سخت افزار یا حتی کانفیگ نرم افزاری بتواند این عدد را نتیجه دهد.
      ممکن است عدد 7 میلیون، مجموع کل درخواست‌ها بوده باشد. در تصاویر تست ما در بخش Total Requests میزان مجموع درخواست‌ها در بازه 60 ثانیه اندازه گیری شده که بین 400هزار تا کمی بیشتر از یک میلیون است.
      همچنین نسخه مورد استفاده در تست ما، 2.2 و پردازنده استفاده شده Core i7 در یک لپ تاپ نسبتا متوسط بوده.

      پاسخ
      • hojjat pirnia - 12 مهر, 1399 at 10:38 ب.ظ

        درضمن درخواست در ثانیه هست نه مجموع درخواست ها
        request per second
        در دات نت کور 3 تونستند به بیش از 7 میلیون درخواست در ثانیه برسند
        سوالی که من دارم اینه که ایا من مثلا با یک سرور ابری که 256 گیگ یا 512 گیگ رم داره و مثلا 50 تا 80 هسته سی پی یو داره
        ایا میتونم همچین کاری انجام بدم ؟
        میتونم با دات نت کور 3 و همچین سرور قدرتمندی به 7 میلیون یا مثلا 2 میلیون درخواست در ثانیه پاسخ بدم
        ؟

        پاسخ
        • سجاد ابراهیمی - 12 مهر, 1399 at 11:09 ب.ظ

          وقت بخیر،

          شرایط و نوع تست بسیار اهمیت دارد. همانطور که در این مطلب ذکر شده این تست هرگز نمی‌تواند نماینده انواع تست‌های ممکن باشد ولیکن هدف مقایسه و تفاوت عملکرد Kestrel با IIS بوده است.
          در لینک شما در تست شماره 3 با همان سرور و سخت افزار این عدد حدود 15 برابر کمتر بوده است. بنابراین علاوه بر قدرت سخت افزار شرایط و نوع تست بسیار اهمیت دارد.
          در صورت تمایل می‌توانید شرایط تست ما را در لینک زیر که در مقاله نیز ذکر شده مشاهده کنید: (تست ما از نوع API بوده و در بستر نرم افزار West Wind Web Surge انجام شده است.)
          https://github.com/RickStrahl/AspetCoreIISInprocessHostingSample

          موفق باشید.

          پاسخ
          • hojjat pirnia - 13 مهر, 1399 at 12:51 ق.ظ

            بله در تست سوم اگر منظورتون تست Fortunes هست این تست برای بازیابی دیتا (سطرها) از دیتابیس استفاده شده و قطعا سرعت پایین میاد . منظور من بدون درگیر کردن دیتابیس هست یعنی فقط اطلاعات رو از رم بازیابی کنیم . در این صورت سرعت بسیار بالاتر خواهد بود .
            در ضمن من اگه به کمک نیاز داشته باشم برای تست سرور خودم میتونم از راهنمایی شما استفاده کنم ؟

          • سجاد ابراهیمی - 13 مهر, 1399 at 11:49 ق.ظ

            شما می تونید با ثبت نام در HiSupport به واحد فنی تیکت ارسال کنید.

دیدگاه خود را ارسال کنید