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.آموزش داده شده است  و در آخر شما می توانید یک نمونه کار عالی داشته باشید.