مقالات باگتو

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

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

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

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

 

 bugeto_bing migration

 

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

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

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

  1. حالت تغییرناپذیر. افزونه‌ها نمی‌توانند به داده‌های استاتیک قابل تغییر رجوع کنند. به‌منظور جلوگیری از همگام‌سازی در وابستگی‌ها و مرتبط کننده‌هایشان، خروجی‌های آنها تغییرناپذیر می‌شوند.
  2. نظارت دقیق. افزونه‌ها نیازمند تأخیر محکم و مداومی هستند و ما پس از وقفه زمانی شروع به اجرای توابع و وابستگی‌هایشان خواهیم کرد.افزونه‌هایی که اغلب خراب می‌شوند به طور خودکار غیرفعال می‌شوند.

موتور زمان اجرا نیز برای اجرای کارآمد این افزونه‌ها به‌شدت بهینه‌سازی‌شده است. تا آنجا که ممکن است از همگام‌سازی نخ جلوگیری می‌کنیم، تخصیص حافظه را به حداقل می‌رسانیم. اشیاء بزرگ را یکپارچه کرده تا از تخصیص مکررLarge Object Heapجلوگیری و کدی را برای اجرای کارآمدتر افزونه‌های بارگذاری شده به‌صورت پویا (دینامیک) تولید می‌کنیم.

نتایج عملکرد

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

نتایج تولید

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

 

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

 

Latency

 

تأخیر یکی از معیارهای اصلی است که ما پیگیری می‌کنیم. مهاجرت یک مرکز داده، منحصراً قابل‌توجه است:

 


bing migaratiom

 

 

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

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

تأخیر سربار

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


bing migration

CPU

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


bing migration

 

 

 

Garbage Collection

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

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


bing migration

 

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

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

Exceptions

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

 

bing migrstion .net

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

 

Lock Contention

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

قفل رقابت مدیریت شده افت زیادی در قله‌ها را نشان داد، اما سطح خط مبنا کمی بالاتر بود:

bing migration . net

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

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

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

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

bing migration .net

 

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

ThreadPool  (مخزن نخ)

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

 


bing migration .net

میانگین زمان تأخیر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(بارگذار)

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

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

ETWو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این اشکال را برطرف کرده است.

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

 


 

bing migration .net

تغییراتGC

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

HTTP Stack

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

HTTP Stackسرویس گیرنده بسیار متفاوت هستند. با توجه به اینکه یکی از اهداف مهم ما این بود که یک پایگاه کد واحد داشته باشیم و فقط با راه‌اندازی مجدد پردازش بتوانیم بین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و آزمایش آن و یا مشاهده خرابی‌های دیگر وجود نداشت. البته کارهای دیگری هم به طور هم‌زمان انجام می‌شد، مثل ساخت سیستم‌های خودکار برای تجزیه‌وتحلیل کد شرکای ما.

نتیجه

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

 

 


تگ‌ها
اشتراک

2 نظرات

  • عکس پروفایل arman در سایت باگتو
  • |
  • ارسال شده توسط : arman
  • |
  • زمان : 1400/04/29

سلام.

مقاله جالب و زیبایی بودش.

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

باز هم ممنون بابت مقاله مفیدتون، موفق باشید.


  • عکس پروفایل رامین در سایت باگتو
  • |
  • ارسال شده توسط : رامین
  • |
  • زمان : 1400/04/29

ممنونم از تیم باگتو

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



;