انتقال موتور گردش کار Bing به NET 5.

Bing  یکی از بزرگ‌ترین و پیچیده‌ترین اپلیکیشن‌های بسیار کارآمد و قابل‌اعتماد NET. را در جهان اجرا می‌کند.

در این پست درباره اقدامات لازم برای ارتقا به .NET 5 و دستاوردهای قابل‌توجه عملکردی که به دست آوردیم، بحث می‌شود.

شما می توانید دوره رایگان آموزش asp  را در سایت باگتو مشاهده کنید این دوره  پروژه محور است و در آخر شما می توانید یک نمونه کار عالی داشته باشید.

این اپلیکیشن در میانه معماری Bing قرار دارد و مسئول بسیاری از هماهنگی‌های توزیع شده بین هزاران مؤلفه دیگر است که نتایج را برای همه جستجوها ارائه می‌دهد و همچنین در مرکز بسیاری از دیگر خدمات دیگر بیرون از Bing قرار دارد. تیم صاحب این مؤلفه XAP ("Zap") نامیده می‌شود. من از سال 2008 مدت کوتاهی پس از پیوستن به مایکروسافت (زمانی که Bing جستجوی رایج بود) به عضویت این تیم درآمدم.

در سال 2010 بیشتر stack from خود را از C ++ به .NET Framework انتقال دادیم. تلاش‌ها برای انتقال XAP به .NET Core در جولای 2018 آغاز شد.با تیم‌هایی که قبلاً این انتقال را انجام داده‌اند مانند لایه Bing’s UX و همچنین خود تیم .NET مشورت کردیم. تیم XAP مدت‌هاست که یک رابطه کاری نزدیک با تیم .NET ، به‌ویژه بخش زبان مشترک در زمان اجرا (CLR) دارد. با اعلان NET Core. و علاوه‌برآن، مزایای عملکرد پیش‌بینی‌شده، ماهیت Open Source و توسعه سریع‌تر، باعث بیشتر شدن انگیزه ما برای انتقال شدند. این انتقال با پیشرفت در عملکرد و مهارتی که قبلاً مشهود بود، برای تیم ما یک موفقیت نامحدود است.

XAP: یک آغازگر

اجازه دهید برای نشان‌دادن برخی از زمینه‌ها، تصویر روشنی از معماری XAP را ارائه دهم.

سه سال پیش، Mukul Sabharwal در بلاگ توضیح داد که چگونه تیمش از Bing’s front به NET Core. مهاجرت کرده است.در زیر این لایه UX یک موتور اجرای گردش کار با عملکرد بالا قرار دارد که هماهنگی و ارتباطات را در میان داده‌هایی مختلف بخشی که مستقیم با کاربر سروکار ندارد (سمت سرور) و  Bing را تغذیه می‌کنند، مدیریت می‌کند. این لایه میانی در بسیاری از سرویس‌های غیر بینگ در Microsoft نیز استفاده می‌شود.

شایان‌ذکر است که تیم پیشرو (سمت کاربر) Bing  قبلاً به‌پیش نمایش‌های .NET 6 منتقل شده است. آنها با NET 6. پیش‌نمایش 1 وارد مرحله تولید شدند و اکنون در پیش‌نمایش 4 قرار دارند و پیشرفت‌های قابل‌توجهی داشته‌اند که در درجه اول مربوط به ویژگی‌های جدید Crossgen2 (یک نسخه جدید و جذاب از پلتفرم هیجان‌انگیز و بخشی از نسخه .net6 است).

تیم XAP دارای دو حوزه اصلی مالکیت است:

1. عامل قسمت میانی سایت موجود برای Bing(و دیگر اپلیکیشن‌های مرتبط با جستجو مانند Sharepoint ، Cortana ، Windows Search و ...).

2- ارائهٔ زمان اجرا، موتور گردشکار، ابزارها و SDK برای شرکای داخلی به‌منظور ساختن و اجرای سناریوها در این پلتفرم.

در  Bing، بزرگ‌ترین حجم کار ما، XAP  عامل‌های هزاران ماشین در میان مجموعه جهانی از مراکز داده است. در هر دستگاه، XAP بیش از 900000 مورد گردش کار و 5.3 میلیون مورد پلاگین (افزونه) را بارگیری می‌کند که همه در یک پردازش با یک توده 50 گیگابایتی است که 2500 مجموعه منحصربه‌فرد و JIT بیش از 2.1 میلیون متد را بارگیری می‌کند.

ApplicationHost در XAP در اساسی‌ترین حالت خود، یک میزبان برای افزونه‌های (توابع) توسعه‌یافته مستقل است که در یک گراف جهت‌دار غیر مدور به نام گردش کار گروه‌بندی‌شده اند.

گردش کارها شامل افزونه‌ها و سایر گردش کارها هستند. وظیفه XAP اجرای این گردش کارها به همان میزان ممکن کارآمد و سریع می‌باشد.

یک جستجوی معمولی Bing حدود 12000 گره (از جمله بیش از 2000 تماس شبکه) را در چند صد میلی‌ثانیه اجرا می‌کند. یک ماشین به طور معمول بیش از 30000 گره در ثانیه را در اوج اجرا می‌کند.

برای اجرای کارآمد و به‌موازات آن حفظ یک سیستم ایمن، محدودیت‌های متعددی را برای نویسندگان افزونه‌ها اعمال می‌کنیم، از جمله:

•  سطح محدود شده  . API بدون تغییر پردازش APIها ، بدون نخ ها، بدون ورودی و خروجی، بدون همگام‌سازی. این قابلیت‌ها همه از طریق موتور گردش کار وافزونه‌هایی تخصصی مدیریت می شوند(e.g., Xap.HTTP).
• حالت تغییرناپذیر. افزونه‌ها نمی‌توانند به داده‌های استاتیک قابل تغییر رجوع کنند. به‌منظور جلوگیری از همگام‌سازی در وابستگی‌ها و مرتبط کننده‌هایشان، خروجی‌های آنها تغییرناپذیر می‌شوند.
• نظارت دقیق. افزونه‌ها نیازمند تأخیر محکم و مداومی هستند و ما پس از وقفه زمانی شروع به اجرای توابع و وابستگی‌هایشان خواهیم کرد. افزونه‌هایی که اغلب خراب می‌شوند به طور خودکار غیرفعال می‌شوند.

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

نتایج عملکرد

قبل از انتشار محصول تولید شده، ما ساخت‌های مختلفی را در چندین دستگاه آزمایش انجام داده‌ایم و نتایج را به‌دقت تجزیه‌وتحلیل کرده‌ایم و زمانی که مطمئن شدیم، آزمایش‌ها تولید در مقیاس کوچک را بسط و گسترش دادیم. با ده دستگاه تصادفی که روی .NET 5 کار می‌کنند، شروع کردیم، به‌تدریج آزمایش را گسترش دادیم تا زمانی که یک مرکز داده دست‌نخورده، NET5. در حال تولید بود.

نتایج تولید

 ما پیش‌نمایش 6 .NET 5.را برای تولید در یک مرکز داده در 8 ژوئیه 2020 ، تقریباً 2 سال پس از شروع پروژه، شروع کردیم. (ما از آن زمان به RTM NET 5 ارتقا یافتیم.)

رونمایی و عرضه اولیه را در سایر مراکز داده با چندین هفته تاخیر انجام دادیم که فرصت کافی برای نظارت بر پایداری و عملکرد را داشته باشیم.

Latency

 تأخیر یکی از معیارهای اصلی است که در نظر می گیریم .

مهاجرت یک مرکز داده، منحصراً قابل‌توجه است:

اینجا یک خلاصه با سطح بالا برای چندین محیط آورده شده است. این اعداد تقریبی است و از میانگین های روزانه طی چند ماه گرفته شده است. آنها درصد بهبود را در دو صدک 99 و 95 اندازه گرفتند. (مثلا صدک 99 بدان معناست که 99٪ درخواستها باید سریعتر از تأخیر داده شده باشد. به عبارت دیگر ، تنها 1٪ از درخواست ها مجاز به کندی هستند)

تنوع و تغییرگسترده ای بین این مراکز داده وجود دارد که می تواند با تفاوت در ترافیک و پیکربندی ماشین توضیح داده شود.

تأخیر سربار

کل زمانی که ApplicationHost به اجرای کوئری اضافه می کند 11٪ کاهش یافته است.

CPU

به طور کلی استفاده از CPU حدود 27٪ کاهش را نشان می دهد و تفاوت به ویژه هنگامی آشکار می شود که زمان کلی CPU را که توسط افزونه های غیر I/O  گرفته شده،در جستجو(کوئری)  BingFirstPageResults بررسی کنیم:  

Garbage Collection

اندازه گیری تأثیر دقیق GC در Builds با شمارنده ها دشوار است.

پیاده سازی GC نه تنها به طور قابل توجهی تغییر کرده،بلکه پیکربندی جدیدی را در .NET Core اعمال کرده ایم.درصد زمان در شمارنده GC افزایش یافته است:

از متوسط 0.3٪ به 0.8٪ رسیده است که از نظر نسبی بسیار زیاد اما از نظر مطلق خیلی زیاد نیست.

ما این تغییر را پس از سنجش‌های فراوان و با مشاوره تیم  CLRبرای کاهش اندازه بودجه نسل 0(generation 0) ایجاد کردیم. این امر باعث می‌شود که GCها (زباله روبی ها) سریع‌تر اما مکررتر باشند که به طور مستقیم در بهبود کوئری کلی تأخیر  P99نقش دارد،اما به‌صرف زمان بیشتری در GC منجر می‌شود.این یک ناحیه فعال برای بررسی اینکه ببینیم می‌توانیم پیشرفت بیشتری داشته باشیم و در برخی دیگر از تنظیمات پیکربندی راهکارهای امیدوارکننده‌ای وجود دارد یا خیر؟

Exceptions

میانگین میزان استثنا به طور قابل‌توجهی کاهش یافت:

به طور متوسط از 7.8 در ثانیه به 3.5ثانیه رسید یعنی 55 درصد بهبودیافته است.

Lock Contention

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

به طور متوسط، از 645 رقابت در ثانیه به 410 رقابت در ثانیه کاهش‌یافته یعنی 36 درصد بهبود پیدا کرده است. واقعیت قابل‌توجه این است که NET Core. الگوریتم قفل‌ها را تغییر داده و بسیار سریع‌تر از حالت NET Framework به حالت انتظار می‌رود (مدتی حالت چرخشی دارد)؛ بنابراین، بخش قابل‌توجهی از مجادلات تحت .NET Core ممکن است اصلاً در .NET Framework محاسبه نشده باشد.

زمان راه‌اندازی

کاهش زمان راه‌اندازی مهم است چون به این معنی است که در هنگام استقرار ما (چندین بار در روز) کمتر از هر مرکز داده‌ای، غیرفعال است و منجر به تأخیر اوج کمتر و در دسترس بودن بیشتر در اوج بار می‌شود.

زمان راه‌اندازی به طور قابل‌توجهی کاهش یافت:

زمان استارتاپ در درجه اول تحت کنترل زمان آماده‌شدن است. جایی که کوئری‌های غیر کاربر را قبل از پذیرش ترافیک واقعی، از طریق سیستم اجرا می‌کنیم. زمان آماده‌شدن با زمان CPU تعیین می‌شود. کاهش 28 درصدی، همبستگی قوی با کاهش در کل استفاده افزونهٔ CPU دارد.

ThreadPool  (مخزن نخ)

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

میانگین زمان تأخیر P95 در حدود 31٪ و میانگین زمان تأخیر P99 در حدود 26٪ کاهش‌یافته است.

Migration Approach

اعداد و ارقام عملکرد عالی هستند، اما در مورد کارهایی که برای دستیابی به آنها انجام شده است چطور؟ ارزش هایلات کردن و نشان‌دادن اهداف انتقال ما را دارد:

1- انعطاف‌پذیری در انتخاب اینکه آیا ماشین تحت .NET Framework یا .NET Core بارگیری شده است. این به ما اجازه می‌دهد:

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

2- Single code base

3- Single copy of binaries

4- اجتناب از نیاز به انتقال همه شرکای ما باهدف netcore / net standard از ابتدا (این غیرممکن بود).

با درنظرداشتن این اصول، ما از رویکرد ترکیبی برای ساخت و اجرای پلتفرم XAP استقبال کردیم:

1- ادامه ساخت پلت فرم تحت  NET Framework 4.7.2.

2-استفاده از ابزار ApiPort (API Portability) برای تأیید سازگاری در سطح API و اطمینان از این که همه فراخوانی‌های NET library . که در پلتفرم خود قرار داده‌ایم، در NET Core . نیز وجود داشته است.

3- توسعه یک اپلیکیشن میزبان سفارشی CoreCLR-based که به‌صورت پویا باینری‌های Framework-built  را بارگیری و اجرا می‌کند.

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

ما در نهایت همه باینری‌های خود را انتقال خواهیم داد که مستقیماً در برابر netstandard2.0 و .NET 5 یا .NET 6 ساخته شوند و دیگر نیازی به رویکرد ترکیبی نخواهیم داشت.

چالش‌ها

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

یک مشکل باینری

چند تا از مجموعه‌هایی که XAP استفاده می‌کند برای سرویس یا حتی برای استارت‌آپ یا پردازش یک کوئری واحد، ضروری هستند. بدون تعمیر و رفع هر وابستگی، حتی نمی‌توان آزمایش را شروع کرد. ده ها مورد از این وابستگی‌ها وجود دارد. این یک نوع مشکل "همه یا هیچ‌چیز" است.

          C++/CLI

زمانی که ما روند انتقال را شروع کردیم، NET Core . در نسخه 2.0 بود که از C ++ / CLI پشتیبانی نمی‌کرد. این DLL ها(Dynamic-Link Library) حتی بارگیری نمی‌شوند.  Bing از تعدادی مؤلفه‌های مشترک زیرساختی استفاده می‌کند که از طریق رابط‌های C ++ / CLI برای کد مدیریت شده ظاهر می‌شوند. بدون این مجموعه‌ها، پردازش حتی نمی‌تواند خود را راه‌اندازی کند، چه برسد به پردازش کوئری‌ها. با کمک و همکاری تمامی تیم‌های شرکت، همه آنها را به استفاده از رابط‌های P / Invoke(Platform Invoke  )تبدیل کردیم. حتی با پشتیبانی از آخرین نسخه .NET Core    برای پروژه‌های C ++ / CLI ، این مجموعه‌ها نیاز به بازسازی دارند. ازآنجاکه ما در حال استفاده از رابط‌های جدید هستیم، لازم نیست که این کار را پیگیری کنیم.

کد ناسازگار

زمان اجرا XAP عمدتاً از یک پردازش میزبانی به نام ApplicationHost و به‌موازات آن کلیه کتابخانه‌هایی که برای اجرا بر روی پلتفرم خود به شرکا ارائه می‌دهیم، تشکیل شده است. ما به بسیاری از کتابخانه‌های مدیریت شده که قطعات کوچکی داشتند با استفاده از APIهایی که در NET Core. وجود نداشتند، تکیه کردیم.

مثال‌ها عبارت‌اند از:

- حافظه پنهان در حافظه که از کتابخانه .NET MemoryCache استفاده می‌کند

- یک کتابخانه محاسباتی Hash

- .NET remoting (WCF) (مخفف Windows Communication Foundation)، سرویس‌دهنده و سرویس‌گیرنده باید از Net . پشتیبانی کنند.

- قابلیت HTTP(پروتکل انتقال ابر متن ها)

- بارگذاری هم‌گذاری سفارشی

هر مورد به‌وضوح و دقت جداگانه‌ای نیاز داشت. در برخی موارد، APIهای فرعی در .NET وجود داشت که می‌توان آنها را تعویض کرد. در برخی موارد دیگر، ما باید کتابخانه‌ها را ارتقا دهیم و این اغلب منجر به یک زنجیره طولانی از وابستگی‌های ارتقا یافته می‌شود. صدها افزونه شرکای ما همچنین از APIهای مختلفی که در NET Core. وجود نداشت استفاده کردند. تعداد APIهای منحصربه‌فرد شکسته نسبتاً اندک بود، شاید حدود ده دوازده مورد. اما تعداد افزونه‌ها و تیم‌های شریک مالک این افزونه‌ها دلهره‌آور بود.

ما با بیش از 800 توسعه‌دهنده در سراسر جهان کار می‌کنیم و برقراری ارتباط با همه آنها یک چالش برای تیم XAP بود؛ بنابراین ما ابزارهای خودکاری را برای اسکن همه افزونه‌ها با استفاده از ابزار ApiPort تیم NET ایجاد کردیم. ما این موارد را به‌عنوان بخشی از پردازش‌های استقرار خودکار قرار داده‌ایم که همه نویسندگان پلاگین باید ابتدا به‌عنوان یک هشدار و سپس به‌عنوان یک خطای انسداد عبور کنند. ما اسناد و مدارک مربوط به رایج‌ترین ناسازگاری‌ها و تغییرات توصیه شده را برای انطباق آنها، جمع کردیم. افزونه‌هایی که توسط تیم‌هایشان رها شده بودند برای همیشه غیرفعال شدند.

گیر اشکالات NET. و تغییرات عملکردی

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

Loader(بارگذار)

XPA   به برخی از قابلیت‌های بسیار خاص متکی است،برای این راه ما مجموعه های شرکای خود را برای رسیدن به بارگذاری مونتاژ کنار هم مصرف می کنیم.
این بخش اساسی از مدل جداسازی ما است.

برخی از تفاوتهای ظریف در بارگذار NET. ما را ملزم به بررسی دقیق کرد و در نهایت به توسعه دهندگان CLR رسیدیم،که حداقل دو اشکال  پیدا کردند، (dotnet/runtime #12072 و dotnet/runtime #11895 )یکی از آنها خرابی بسیار زیاد پشته بود. ما هم ملزم به ایجاد تغییراتی در کد خود بودیم.

علاوه بر این ، به دلیل پیگیری ها و تحقیقات ما ، آنها یک اشکال عملکرد وضوح همگذاری(اسمبلی) را برطرف کردندکه برای ما مهم بود. معماری و مقیاس ویژه ما، به ما امکان می دهد این اشکالات مبهم را قبل از اینکه دیگران آنها را پیدا کنند ،پیداکنیم.

EWTو TraceEvent (ردیابی رویداد )

چالش مهم دیگر با کتابخانه Microsoft.Diagnostics.Tracing.TraceEvent بود. زمانی که ApplicationHost برای اولین‌بار ساخته شد و ما تصمیم گرفتیم ETW را به‌عنوان مکانیسم خود ثبت کنیم، فناوری‌های ETW هنوز در .NET Framework نبودند و نسخه‌های متن‌باز در مراحل اولیه بودند. ما کد EventSource و TraceEvent را به نسخه‌های خصوصی خود منشعب کردیم. به دلایل مختلف، انتقال به نسخه رسمی، زمانی که بیشتر در دسترس بودند، برای ما دشوار و پرهزینه بود. سرانجام، با یافتن چند اشکال کوچک در طول مسیر، به پکیج رسمی انتقال یافتیم. چند اشکال قابل‌توجه دیگر که با آنها روبرو شده‌ایم و در NET 5 . برطرف شده‌اند مربوط به ارائه‌دهنده رویداد CLR است. زمانی که کد لاگر ما روی فایل‌ها می‌چرخد، لازم است اشتراک خود را در رویدادهایی که می‌شنود، از جمله رویدادهای CLR ، لغو کند. وقتی لاگر مجدداً در رویدادها برای فایل‌های جدید مشترک می‌شود، دیگر هرگز رویدادهای CLR را دریافت نمی‌کند. حتی ابزارهای خارجی مانند PerfView (ابزاری برای تجزیه‌وتحلیل عملکرد است که به جداکردن پردازنده و مشکلات مربوط به حافظه کمک می‌کند) که برای اشکال‌زدایی و ترسیم نیمرخ (نمایه‌سازی) عملکرد به آنها متکی هستیم، دیگر نمی‌توانند این رویدادهای CLR را دریافت کنند. این باگ بیشتر چالش‌برانگیز بود زیرا تکثیر آن بسیار دشوار بود و الگوی استفاده ما احتمالاً کمی غیرمعمول بود.

شمارنده عملکرد

XAP بسیار متمرکز بر متریک است. ما 6 میلیارد رویداد در دقیقه از میان 500 میلیون سری زمانی را جمع‌آوری می‌کنیم. بیشتر این موارد مربوط به خود ماست، اما ما به تعداد زیادی سیستم و شمارنده‌های سطح .NET  متکی هستیم. این زیرساخت در NET Core 2.x وجود نداشت و ما در بسیاری از مناطق کور بودیم. با شروع از NET Core 3.x ، برخی از شمارنده‌های عملکرد در دسترس قرار گرفتند. ما موارد زیاد دیگری برای افزودن درخواست کردیم. بسیاری از این موارد در NET 5 . اضافه شدند.

باگ Exception-Handling

اگرچه اکیداً یک اشکال ناشی از انتقال نبود، این مسئله همراه با بسیاری از مسائل دیگر در حین انجام تحقیق مورد بررسی قرار گرفت و ما هم‌زمان با تحقیقات دیگر در مورد عملکرد CLR ، به رسیدگی آن پرداختیم. مدت‌زمان طولانی XAP وقفه‌های طولانی را در مکان‌های غیرمعمول در اجرای کوئری مشاهده می‌کرد، در مکان‌هایی که هیچ دلیل مشخصی وجود نداشت. با کمک تیم CLR ، ما ردیابی‌هایی را جمع‌آوری کردیم و متوجه شدیم که قطع زنجیره توسط مکانیزم مدیریت استثنا که I / O دیسک را در برخی موارد بسیار خاص انجام می‌دهد، مسدود شده است.

این یک اشکال اعلام شده بود، اما جالب اینکه همه relevant stacks مربوطه از یک افزونه واحد است که تقریباً هر کوئری را به استثناها می‌انداخت (و آنها را می‌گرفت). ما با رویدادهای ETW دیدیم که این بزرگ‌ترین منبع استثنا در این پردازش است و از مالک کد خواستیم قبل از اینکه با API پرتاب استثنا تماس بگیرد، اعتبارسنجی انجام دهد (این یک تعمیر جزئی برای آنها بود). به‌محض استقرار تیم شریک، مکث‌های مبهم نخ برطرف شد و بزرگ‌ترین منبع کوئری‌های با تأخیر بالا پاک شد. از آن زمان تیم CLR این اشکال را برطرف کرده است.

این نمودار ایده‌ای از تأثیر این تعمیر را نشان می‌دهد که تغییر در درصد درخواست‌های تأخیر بسیار بالا را نشان می‌دهد:

تغییرات GC

یک تغییر بزرگ که به ما کمک کرد ،چگونگی از بین بردن حافظه بود. این تغییر منجر به توقف GC برای سرور  GC شد و تعدادی از تغییرات دیگر را برای بهبود عملکرد ایجاد کرد.

HTTP Stack

یکی از چالش‌برانگیزترین مناطق گذار، HTTP Stackگیرنده ما بود. در سراسر جهان، افزونه HTTP ما بیش از 7.5 میلیون بار در ثانیه توسط شرکای ما فراخوانی می‌شود.

NET Framework .و NET Core .دارای پشته های سرویس گیرنده HTTP بسیار متفاوتی هستند. با توجه به اینکه یکی از اهداف مهم ما این بود که یک پایگاه کد واحد داشته باشیم و فقط با راه‌اندازی مجدد پردازش بتوانیم بین Framework و Core جابه‌جا شویم، باید مسئله بسیار مهمی را حل می‌کردیم.

در NET Framework. ، ما به عملکردهای ServicePointManager و WebRequestHandler متکی بودیم، هیچ یک از آنها درNET Core. وجود ندارد. در ابتدا پیشنهاد شد که به WinHttpHandler بروید، اما این رده عملکردهای زیادی را که به آن متکی هستیم از دست می‌دهد. در صورت استفاده ما از آن، پیامدهای واقعی برای آن به وجود خواهد آمد، زیرا برخی از تیم‌های پسگرد در Bing بالانس بار را اجرا کردند که دستیابی به آن با استفاده از WinHttpHandler (پیام‌های مبتنی بر رابط WinHTTP ویندوز را مدیریت می‌کند) امکان‌پذیر نبود.

 آخرین نظریه اینکه، SocketsHttpHandler (کنترل‌کننده پیام پیش‌فرض استفاده شده توسط HttpClient در NET Core 2.1. به بعد) فقط برای NET Core .در دسترس بود.

جدول زیر خلاصه موقعیت ما را نشان می دهد:

ما نمی خواهیم به WinHttpHandler برویم و در نهایت در بدترین وضع ما نمی‌خواهیم به WinHttpHandler برویم و در نهایت در بدترین وضعیت هر دو حالت قرار بگیریم. در پایان، ما یک رابط HTTP ایجاد کردیم که بسته به مدت‌زمان استفاده، WebRequestHandler یا SocketsHttpHandler را به‌صورت پویا بارگیری می‌کند. هر دوی این کلاس‌ها از عملکرد مشابهی برخوردار هستند، اما از رابط مشترکی برخوردار نیستند، بنابراین ما رده خود را توسعه دادیم. علاوه بر این، در .NET Framework ، برخی تنظیمات TCP از طریق ServicePointManager در کل پردازش تنظیم می‌شوند، اما در .NET Core ، آنها روی شی SocketsHttpHandler تنظیم می‌شوند.

تلاش مهندسی مقیاس‌گذاری

به دلیل ماهیت باینری بودن بسیاری از قسمت‌های این پروژه عظیم، مسدود شدن کامل آن به‌ویژه در مراحل اولیه ساده بود. به‌عنوان‌مثال، وقتی در انتظار انتقال کتابخانه‌های C ++ / CLI به P / Invoke بودیم، فقط روی مواردی کار کردیم که می‌دانستیم باید تغییر کنند. هیچ راهی برای راه‌اندازی ApplicationHost و آزمایش آن و یا مشاهده خرابی‌های دیگر وجود نداشت. البته کارهای دیگری هم به طور هم‌زمان انجام می‌شد، مثل ساخت سیستم‌های خودکار برای تجزیه‌وتحلیل کد شرکای ما.

نتیجه

به‌طورکلی، NET5. بهبود عملکرد قابل‌توجهی نسبت به .NET Framework در سناریوی XAP نشان می‌دهد. درحالی‌که هنوز کارهای بیشتری برای انجام وجود دارد، اما تصویر کلی به‌وضوح نشان می‌دهد که .NET 5 از بسیاری جهات از لحاظ ظاهری برتر است. امیدواریم تیم‌های دیگر در مایکروسافت و صنعت بزرگ‌تر بتوانند از درس‌هایی که XAP  در طی انتقال و هنگام بررسی انتقال به .NET 5 و فراتر از آن آموخته‌اند، راهنمایی بگیرند.

شما می توانید دوره رایگان آموزش asp  را در سایت باگتو مشاهده کنید این دوره  پروژه محور است و با Net Core5.آموزش داده شده است  و در آخر شما می توانید یک نمونه کار عالی داشته باشید.