❇️ عیب یابی و رفع مشکلات پرفرمنسی
در یکی از شرکت هایی که مشاور هستم از من خواسته شده تا مشکلات پرفرمنسی پروژه را پیدا کرده و مناسب ترین راه حل را به آنها پیشنهاد دهم
در هر پروژه ای احتمالا قسمت های زیادی قابل بهبود هستند (چه از لحاظ پرفرمنسی و چه از لحاظ معماری و کدنویسی تمیز و...) اما برای یافتن موثر ترین راه و البته کم هزینه ترین، باید ابتدا Bottleneck (گلوگاه) های سیستم را کشف کرده و سپس بر اساس «هزینه، زمان و منفعت» آنها را الویت بندی کنیم
برای کشف گلوگاه های سیستم (جاهایی که عامل اصلی افت پرفرمنس هستند) باید از ابزار های Profiler استفاده کنیم.
در کل پروفایلر های مختلفی وجود دارند که اکثرا پولی هستند در اینجا میخواهم بهترین آنها رو معرفی کنم
بهترین ابزار های Performance Profiler
1️⃣ برنامه ANTS Performance Profiler (محصول شرکت Redgate)
2️⃣ برنامه dotTrace (محصول شرکت JetBrains)
3️⃣ برنامه PerfView (محصولی "رایگان و سورس باز" از شرکت Microsoft)
4️⃣ برنامه CodeTrack (محصولی "رایگان و سورس باز")
هر چهار برنامه قابلیت های قوی و زیادی دارند از مهمترین شون میشه به موارد زیر اشاره کرد
🔸 قابلیت ثبت سلسله مراتب فراخوانی متد ها
توسط این قابلیت که اصلاحا بهش Call tree میگن میشه فهمید که چه متدی چه متد های دیگه ای رو فراخوانی کرده یا مثلا یک متد کلا چندبار صدا زده شده و هر متد چقدر به طول انجامیده (در قالب یک Timeline کامل) و ....
🔹 قابلیت ثبت تمام کوئری های اجرا شده بر روی دیتابیس
توسط این قابلیت میشه دید چه کوئری هایی و مثلا یک کوئری چندبار روی دیتابیس اجرا شده و هرکدوم چقدر زمان بره و...
🔸 قابلیت ثبت تمام Exception های رخ داده به همراه جزئیات و stacktrace
🔹 قابلیت نمایش تمام Thread های ایجاد شده و فرایند های انجام شده داخلش هر کدومشون و یا کلیه فرایند های انجام شده داخل یک Process
🔸 قابلیت پروفایل کردن همه برنامه ها از جمله
.NET Framework, .NET Core و ASP.NET, ASP.NET Core, Webservices, WCF, Windows Forms, Windows services, WPF ,IIS Website, IIS Express Website, Attach to a running process
❇️ این قابلیت ها برای عیب یابی به شدت مفید هستند چون توی یه سیستم با تراکنش بالا که بعضی مشکلات رو نمیشه پیش بینی کرد با این به راحتی میشه متد ها و یا کوئری های سنگین و اضافه ای که باعث افت پرفرمنس میشه رو پیدا کرد
❇️ هر دو برنامه ANTS و dotTrace پولی بوده و جز بهترین و محبوبترین برنامه های Performance Profiler هستند.
برنامه dotTrace یکپارچگی خوبی با Resharper داره و Visual Studio داره ولی شخصا با توجه به تجربه کاری با جفتشون، برنامه ANTS رو بیشتر می پسندم؛ کارکردن باهاش راحته و UX خوبی داره گزارشات و خروجی کاربردی تری نشون میده
ANTS Performance Profiler overview (ویدئو دمو برنامه)
https://www.youtube.com/watch?v=8mhC-Ji6-uU
❇️ برنامه PerfView هم تقریبا همین قابلیت ها رو داره ولی کارکردن باهاش سخت تره و UX خوبی نداره ولی چون رایگانه محبوبه
برنامه CodeTrack هم قابلیت هاش (نسبت به قبلی ها) کمتره ولی کارکردن باهاش راحته و UX متوسطی داره ونیز رایگانه
❇️ یه قابلیت خوبی که فقط dotTrace داره قابلیت Remote Profiling هست که توسط اون میتونین به برنامه هاتون روی یه سرور Remote دیگه متصل بشین و پرفایلش کنین
🔰در ادامه تصمیم دارم یه سری از مشکلات مهمی که توی اون پروژه مذکور پیدا و رفع میکنم رو با هشتگ زیر منتشر کنم
#PerformanceTuning
______________
@IranAspMvc
در یکی از شرکت هایی که مشاور هستم از من خواسته شده تا مشکلات پرفرمنسی پروژه را پیدا کرده و مناسب ترین راه حل را به آنها پیشنهاد دهم
در هر پروژه ای احتمالا قسمت های زیادی قابل بهبود هستند (چه از لحاظ پرفرمنسی و چه از لحاظ معماری و کدنویسی تمیز و...) اما برای یافتن موثر ترین راه و البته کم هزینه ترین، باید ابتدا Bottleneck (گلوگاه) های سیستم را کشف کرده و سپس بر اساس «هزینه، زمان و منفعت» آنها را الویت بندی کنیم
برای کشف گلوگاه های سیستم (جاهایی که عامل اصلی افت پرفرمنس هستند) باید از ابزار های Profiler استفاده کنیم.
در کل پروفایلر های مختلفی وجود دارند که اکثرا پولی هستند در اینجا میخواهم بهترین آنها رو معرفی کنم
بهترین ابزار های Performance Profiler
1️⃣ برنامه ANTS Performance Profiler (محصول شرکت Redgate)
2️⃣ برنامه dotTrace (محصول شرکت JetBrains)
3️⃣ برنامه PerfView (محصولی "رایگان و سورس باز" از شرکت Microsoft)
4️⃣ برنامه CodeTrack (محصولی "رایگان و سورس باز")
هر چهار برنامه قابلیت های قوی و زیادی دارند از مهمترین شون میشه به موارد زیر اشاره کرد
🔸 قابلیت ثبت سلسله مراتب فراخوانی متد ها
توسط این قابلیت که اصلاحا بهش Call tree میگن میشه فهمید که چه متدی چه متد های دیگه ای رو فراخوانی کرده یا مثلا یک متد کلا چندبار صدا زده شده و هر متد چقدر به طول انجامیده (در قالب یک Timeline کامل) و ....
🔹 قابلیت ثبت تمام کوئری های اجرا شده بر روی دیتابیس
توسط این قابلیت میشه دید چه کوئری هایی و مثلا یک کوئری چندبار روی دیتابیس اجرا شده و هرکدوم چقدر زمان بره و...
🔸 قابلیت ثبت تمام Exception های رخ داده به همراه جزئیات و stacktrace
🔹 قابلیت نمایش تمام Thread های ایجاد شده و فرایند های انجام شده داخلش هر کدومشون و یا کلیه فرایند های انجام شده داخل یک Process
🔸 قابلیت پروفایل کردن همه برنامه ها از جمله
.NET Framework, .NET Core و ASP.NET, ASP.NET Core, Webservices, WCF, Windows Forms, Windows services, WPF ,IIS Website, IIS Express Website, Attach to a running process
❇️ این قابلیت ها برای عیب یابی به شدت مفید هستند چون توی یه سیستم با تراکنش بالا که بعضی مشکلات رو نمیشه پیش بینی کرد با این به راحتی میشه متد ها و یا کوئری های سنگین و اضافه ای که باعث افت پرفرمنس میشه رو پیدا کرد
❇️ هر دو برنامه ANTS و dotTrace پولی بوده و جز بهترین و محبوبترین برنامه های Performance Profiler هستند.
برنامه dotTrace یکپارچگی خوبی با Resharper داره و Visual Studio داره ولی شخصا با توجه به تجربه کاری با جفتشون، برنامه ANTS رو بیشتر می پسندم؛ کارکردن باهاش راحته و UX خوبی داره گزارشات و خروجی کاربردی تری نشون میده
ANTS Performance Profiler overview (ویدئو دمو برنامه)
https://www.youtube.com/watch?v=8mhC-Ji6-uU
❇️ برنامه PerfView هم تقریبا همین قابلیت ها رو داره ولی کارکردن باهاش سخت تره و UX خوبی نداره ولی چون رایگانه محبوبه
برنامه CodeTrack هم قابلیت هاش (نسبت به قبلی ها) کمتره ولی کارکردن باهاش راحته و UX متوسطی داره ونیز رایگانه
❇️ یه قابلیت خوبی که فقط dotTrace داره قابلیت Remote Profiling هست که توسط اون میتونین به برنامه هاتون روی یه سرور Remote دیگه متصل بشین و پرفایلش کنین
🔰در ادامه تصمیم دارم یه سری از مشکلات مهمی که توی اون پروژه مذکور پیدا و رفع میکنم رو با هشتگ زیر منتشر کنم
#PerformanceTuning
______________
@IranAspMvc
❇️ خواهشا از HttpClient درست استفاده کنیم! (قسمت اول)
#PerformanceTuning
کلاس HttpClient محبوب ترین کلاس برای ارتباطات Http است ولی متاسفانه اکثرا از آن بدستی استفاده نمیکنند!
در این پست میخواهیم Best Practice های آن را بررسی کنیم.
در دات نت، 3 کلاس پایه برای ارتباطات Http داریم :
1️⃣ کلاس HttpWebRequest : اولین و low-level ترین کلاس که کنترل بیشتری به شما می دهد
2️⃣ کلاس WebClient : یک محصور کننده hight-level بر روی HttpWebRequest که کنترل کمتری به شما می دهد ولی طرز استفاده آن ساده تر است
3️⃣ کلاس HttpClient : بهینه ترین کلاس موجود برای ارتباطات Http که مزایای هر دو کلاس قبل را داشته و در دات نت 4.5 به بعد (و نیز تمامی ورژن های NETCore) اضافه شد (البته پکیج Nuget آن برای دات نت 4.0 هم وجود دارد)
کلاس HttpClient نسبت به دو کلاس قبلی پرفرمنس بیشتری داشته و متد های اصلی آن (از جمله GetAsync و PostAsync و...) thread-safe است درنتیجه میتوان یک نسخه از آن به صورت Singleton ایجاد و به صورت concurrent استفاده شود.
یک قابلیت مهم دیگر این آن، امکان Chain کردن HttpMessageHandlers ها در HttpClient است (چیزی شبیه به Pipeline میدلور ها در ASP Core) که میتوان از آن برای Logging، Caching و Error handling و ... استفاده کرد (مثال)
4️⃣ کتابخانه RestSharp نیز یک کتابخانه third-party برای ارتباطات Http و مخصوصا REST بوده ولی درون خود از HttpWebRequest استفاده میکند نه HttpClient و پرفرمنس کمتری دارد (نزدیک به نصف!)
5️⃣ کتابخانه Refit هم هست که با قابلیت های مدرن زیادی داره و کار با RESTful API ها رو خیلی راحت میکنه و البته از HttpClient هم استفاده میکنه (در حال حاضر بهترین کتابخانه third-party)
🔰 نکته بسیار مهم، استفاده بهینه و صحیح از این کلاس است که متاسفانه خیلی ها به اشتباه از آن استفاده میکنند
🔸کلاس HttpClient نباید هربار و به ازای هر درخواست، ساخته (new) شود که در این صورت پرفرمنس را به شدت کاهش میدهد!
🔹با وجود اینکه استفاده از یک شی Singleton آن نسبت به ایجاد هر باره آن بهتر است ولی باز هم صحیح نیست و باعث میشود از تغییرات DNS آگاه نشود!
🔸قبلا گفتیم که فقط متد های اصلی آن thread-safe است، پس پروپرتی های آن مانند (DefaultRequestHeaders و BaseAddress و Timeout و ...) thread-safe نیست و نباید بین ترد های مختلف به صورت مشترک استفاده شود
مثلا اگر یک شی Singleton یا static از HttpClient داشته باشید و در میان ترد های مختلف از آن استفاده کنید ممکن است در آن واحد که یک ترد در حال درخواست زدن به یک url است، ترد دیگری BaseAddress آن را تغییر دهد
🔹با وجود اینکه کلاس کلاس HttpClient یک شی Disposable است ولی نباید به صورت دستی Dispose شود درنتیجه استفاده از آن در کنار using (برای Dispose خودکار) به شدت اشتباه است و باعث مشکل حادی را به نام sockets exhaustion (اشباع سوکت های باز) میشود.
🔸نکته قبل، برای خروجی متد های آن، یعنی کلاس HttpResponseMessage صادق نیست و آن هارا باید حتما توسط using یا به صورت دستی Dispose کرد (البته در حالت دستی اگر exception ایی رخ دهد Dispose رخ نخواهد داد پس باید در بلاک try finaly نوشته شود)
🔹نکته بسیار مهم دیگر این است که به هیچ عنوان از کلاس HttpClient به صورت sync استفاده نکنید، ارتباطات network یکی از مهمترین عوامل block کننده thread بوده و دلیل اصلی اینکه کلاس HttpClient فقط و فقط دارای متد های async است همین بوده.
در نتیجه، استفاده از متد های آن به صورت sync همراه با Task.Wait و Task.Result به شدت اشتباه است و باعث بلاک شدن ترد می شود. (این مقوله برای تمامی متد های async صادق است و حتی می تواند باعث dead-lock شود)
در قسمت بعد اصولی ترین و بهینه ترین روش کار با HttpClient را بررسی خواهیم کرد
___________
@IranAspMvc
#PerformanceTuning
کلاس HttpClient محبوب ترین کلاس برای ارتباطات Http است ولی متاسفانه اکثرا از آن بدستی استفاده نمیکنند!
در این پست میخواهیم Best Practice های آن را بررسی کنیم.
در دات نت، 3 کلاس پایه برای ارتباطات Http داریم :
1️⃣ کلاس HttpWebRequest : اولین و low-level ترین کلاس که کنترل بیشتری به شما می دهد
2️⃣ کلاس WebClient : یک محصور کننده hight-level بر روی HttpWebRequest که کنترل کمتری به شما می دهد ولی طرز استفاده آن ساده تر است
3️⃣ کلاس HttpClient : بهینه ترین کلاس موجود برای ارتباطات Http که مزایای هر دو کلاس قبل را داشته و در دات نت 4.5 به بعد (و نیز تمامی ورژن های NETCore) اضافه شد (البته پکیج Nuget آن برای دات نت 4.0 هم وجود دارد)
کلاس HttpClient نسبت به دو کلاس قبلی پرفرمنس بیشتری داشته و متد های اصلی آن (از جمله GetAsync و PostAsync و...) thread-safe است درنتیجه میتوان یک نسخه از آن به صورت Singleton ایجاد و به صورت concurrent استفاده شود.
یک قابلیت مهم دیگر این آن، امکان Chain کردن HttpMessageHandlers ها در HttpClient است (چیزی شبیه به Pipeline میدلور ها در ASP Core) که میتوان از آن برای Logging، Caching و Error handling و ... استفاده کرد (مثال)
4️⃣ کتابخانه RestSharp نیز یک کتابخانه third-party برای ارتباطات Http و مخصوصا REST بوده ولی درون خود از HttpWebRequest استفاده میکند نه HttpClient و پرفرمنس کمتری دارد (نزدیک به نصف!)
5️⃣ کتابخانه Refit هم هست که با قابلیت های مدرن زیادی داره و کار با RESTful API ها رو خیلی راحت میکنه و البته از HttpClient هم استفاده میکنه (در حال حاضر بهترین کتابخانه third-party)
🔰 نکته بسیار مهم، استفاده بهینه و صحیح از این کلاس است که متاسفانه خیلی ها به اشتباه از آن استفاده میکنند
🔸کلاس HttpClient نباید هربار و به ازای هر درخواست، ساخته (new) شود که در این صورت پرفرمنس را به شدت کاهش میدهد!
🔹با وجود اینکه استفاده از یک شی Singleton آن نسبت به ایجاد هر باره آن بهتر است ولی باز هم صحیح نیست و باعث میشود از تغییرات DNS آگاه نشود!
🔸قبلا گفتیم که فقط متد های اصلی آن thread-safe است، پس پروپرتی های آن مانند (DefaultRequestHeaders و BaseAddress و Timeout و ...) thread-safe نیست و نباید بین ترد های مختلف به صورت مشترک استفاده شود
مثلا اگر یک شی Singleton یا static از HttpClient داشته باشید و در میان ترد های مختلف از آن استفاده کنید ممکن است در آن واحد که یک ترد در حال درخواست زدن به یک url است، ترد دیگری BaseAddress آن را تغییر دهد
🔹با وجود اینکه کلاس کلاس HttpClient یک شی Disposable است ولی نباید به صورت دستی Dispose شود درنتیجه استفاده از آن در کنار using (برای Dispose خودکار) به شدت اشتباه است و باعث مشکل حادی را به نام sockets exhaustion (اشباع سوکت های باز) میشود.
🔸نکته قبل، برای خروجی متد های آن، یعنی کلاس HttpResponseMessage صادق نیست و آن هارا باید حتما توسط using یا به صورت دستی Dispose کرد (البته در حالت دستی اگر exception ایی رخ دهد Dispose رخ نخواهد داد پس باید در بلاک try finaly نوشته شود)
🔹نکته بسیار مهم دیگر این است که به هیچ عنوان از کلاس HttpClient به صورت sync استفاده نکنید، ارتباطات network یکی از مهمترین عوامل block کننده thread بوده و دلیل اصلی اینکه کلاس HttpClient فقط و فقط دارای متد های async است همین بوده.
در نتیجه، استفاده از متد های آن به صورت sync همراه با Task.Wait و Task.Result به شدت اشتباه است و باعث بلاک شدن ترد می شود. (این مقوله برای تمامی متد های async صادق است و حتی می تواند باعث dead-lock شود)
در قسمت بعد اصولی ترین و بهینه ترین روش کار با HttpClient را بررسی خواهیم کرد
___________
@IranAspMvc
www.nuget.org
System.Net.Http 4.0.0
Provides modern classes for sending HTTP requests and receiving HTTP responses from a resource identified by a URI.
Commonly Used Types:
System.Net.Http.HttpResponseMessage
System.Net.Http.DelegatingHandler
System.Net.Http.HttpRequestException
System.Ne…
Commonly Used Types:
System.Net.Http.HttpResponseMessage
System.Net.Http.DelegatingHandler
System.Net.Http.HttpRequestException
System.Ne…
❇️ خواهشا از HttpClient درست استفاده کنیم! (قسمت دوم)
#PerformanceTuning
در قسمت قبل روش های کار با Http و مزایا و معایب هرکدام را بررسی کردیم و به نکات و Best Practice های استفاده از HttpClient پرداختیم
در این قسمت میخواهیم بهترین روش استفاده از آن را بررسی کنیم
اصولی ترین و بهینه ترین حالت استفاده از HttpClient، استفاده از کلاس HttpClientFactory موجود در NET Core 2.1. به بعد است
این کلاس وهله سازی HttpClient و Dispose کردن آن را به صورت خودکار و استاندارد به عهده میگیرد و توسط مکانیزم Pooling (استخری از HttpClient ها) وهله های ایجاد شده را مجددا برای درخواست های بعدی استفاده می کند
بدین ترتیب HttpClientFactory از HttpClient های خود، به بهینه ترین نحو استفاده‌ی مجدد میکند و همچنین سربار ایجاد HttpClientهای جدید نیز به حداقل می‌رسند.
در این روش دیگر مشکل نشتی حافظه یا کمبود منابع ناشی از Dispose نشدن HttpClient ها را نخواهیم داشت زیرا Lifetime وهله ها توسط HttpClientFactory مدیریت می شود
همچنین دیگر مشکل sockets exhaustion (اشباع سوکت های باز) و آگاه نشدن از تغییرات DNS را نخواهیم داشت
برای استفاده از این کلاس 4 روش موجود است
Basic usage
Named clients
Typed clients
Generated clients
روش Basic روش ساده و معمول آن است ولی معمولا در پروژه ها لازم است یک سری کانفیگ خاص را برای هر HttpClient تنظیم کنیم
مثلا HttpClient ایی که قرار است به سایت A درخواست بزند BaseAddress و Timeout و DefaultRequestHeaders (هدرهای پیشفرض) خود را دارد
از انجایی که این پروپرتی ها thread-safe نیستند بهترین راه استفاده از روش های Named clients و Typed clients است
نکته و محدودیت ای که در ورش Typed clients وجود دارد اینست که کلاس استفاده کننده از آن HttpClient الزاما به صورت Transient رجیستر میشود که باید مد نظر داشت و در صورت نیاز از روش Named clients یا ترفند های دیگر استفاده کرد.
روش Generated clients هم مخصوص استفاده از HttpClient توسط کتابخانه های third-party مانند Refit (که در قسمت قبل بررسی کردیم) است
برای یادگرفتن روش صحیح استفاده از HttpClient پیشنهاد میکنم حتما این 3 مقاله را بخوانید
https://www.dotnettips.info/post/2801
https://www.dotnettips.info/post/3022
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-2.2
___________
@IranAspMvc
#PerformanceTuning
در قسمت قبل روش های کار با Http و مزایا و معایب هرکدام را بررسی کردیم و به نکات و Best Practice های استفاده از HttpClient پرداختیم
در این قسمت میخواهیم بهترین روش استفاده از آن را بررسی کنیم
اصولی ترین و بهینه ترین حالت استفاده از HttpClient، استفاده از کلاس HttpClientFactory موجود در NET Core 2.1. به بعد است
این کلاس وهله سازی HttpClient و Dispose کردن آن را به صورت خودکار و استاندارد به عهده میگیرد و توسط مکانیزم Pooling (استخری از HttpClient ها) وهله های ایجاد شده را مجددا برای درخواست های بعدی استفاده می کند
بدین ترتیب HttpClientFactory از HttpClient های خود، به بهینه ترین نحو استفاده‌ی مجدد میکند و همچنین سربار ایجاد HttpClientهای جدید نیز به حداقل می‌رسند.
در این روش دیگر مشکل نشتی حافظه یا کمبود منابع ناشی از Dispose نشدن HttpClient ها را نخواهیم داشت زیرا Lifetime وهله ها توسط HttpClientFactory مدیریت می شود
همچنین دیگر مشکل sockets exhaustion (اشباع سوکت های باز) و آگاه نشدن از تغییرات DNS را نخواهیم داشت
برای استفاده از این کلاس 4 روش موجود است
Basic usage
Named clients
Typed clients
Generated clients
روش Basic روش ساده و معمول آن است ولی معمولا در پروژه ها لازم است یک سری کانفیگ خاص را برای هر HttpClient تنظیم کنیم
مثلا HttpClient ایی که قرار است به سایت A درخواست بزند BaseAddress و Timeout و DefaultRequestHeaders (هدرهای پیشفرض) خود را دارد
از انجایی که این پروپرتی ها thread-safe نیستند بهترین راه استفاده از روش های Named clients و Typed clients است
نکته و محدودیت ای که در ورش Typed clients وجود دارد اینست که کلاس استفاده کننده از آن HttpClient الزاما به صورت Transient رجیستر میشود که باید مد نظر داشت و در صورت نیاز از روش Named clients یا ترفند های دیگر استفاده کرد.
روش Generated clients هم مخصوص استفاده از HttpClient توسط کتابخانه های third-party مانند Refit (که در قسمت قبل بررسی کردیم) است
برای یادگرفتن روش صحیح استفاده از HttpClient پیشنهاد میکنم حتما این 3 مقاله را بخوانید
https://www.dotnettips.info/post/2801
https://www.dotnettips.info/post/3022
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-2.2
___________
@IranAspMvc
🔰 یک نکته پرفرمنسی درباره Logging
🔸استفاده از تامین کننده Console برای Logging در حین ارائه نهایی (Production) به شدت باعث کند شدن و کاهش کارآیی برنامه خواهد شد. بهتر است این تامین کننده را صرفا در محیط Development تنظیم کنید (مانند تصویر)
🔹اگر از WebHost.CreateDefaultBuilder استفاده می‌کنید، به صورت پیشفرض سه تامین کننده Console و Debug و EventSource ثبت خواهند شد پس لازم است ابتدا آن ها را توسط متد ClearProviders حذف کنید
#PerformanceTuning
_____________
@IranAspMvc
🔸استفاده از تامین کننده Console برای Logging در حین ارائه نهایی (Production) به شدت باعث کند شدن و کاهش کارآیی برنامه خواهد شد. بهتر است این تامین کننده را صرفا در محیط Development تنظیم کنید (مانند تصویر)
🔹اگر از WebHost.CreateDefaultBuilder استفاده می‌کنید، به صورت پیشفرض سه تامین کننده Console و Debug و EventSource ثبت خواهند شد پس لازم است ابتدا آن ها را توسط متد ClearProviders حذف کنید
#PerformanceTuning
_____________
@IranAspMvc
✅ حرفه ای ترین سلوشن Logging در NETCore. با استفاده از Serilog و ElasticSearch و Kibana
#PerformanceTuning
کتابخانه های مختلفی برای لاگ کردن خطا ها در دات نت وجود داره، از جمله Elmah، NLog, Log4net و ...
کتابخانه Elmah بهترین انتخاب برای پروژه های کوچک و متوسطه، کار باهاش راحته و پنل ساده ای هم داره، ولی توی پروژه های بزرگ که تعداد لاگ ها خیلی زیاد میشه، دیگه Elmah جوابگو نیست، هم به خاطر سرعت کمش نسبت به بقیه کتابخانه ها و هم به خاطر پنل ضعیف اش که حتی یه سرچ هم نداره
در این شرایط راه های مختلفی هست مثل استفاده از سرویس های نگهداری لاگ Cloud-based مثل setry.io , elmah.io و ...
راه حل بعدی استفاده از برنامه های مدیریت لاگ مثل Seq هستند که بر خلاف مورد قبلی، یک سرویس خارجی نیست و روی سرور خودتون لاگ ها رو نگهداری میکنه و داشبورد قدرتمندی برای سرچ و کوئری گرفتن در اختیارتون میذاره (ولی پولیه)
🔰 راه حل حرفه ای تر و البته رایگان، استفاده از Serilog و ElasticSearch و Kibana هست
🔸دیتابیس ElasticSearch در واقع یک دیتابیس NoSql و یک Search Engine (موتور جستجو) سورس باز و فوق سریع (بر پایه Lucene) هست که قابلیت جستجو و کوئری زدن زدن (به صورت full text search) با سرعت و قدرت بالا رو داره از اون برای نگهداری لاگ ها استفاده خواهیم کرد
🔹پنل Kibana هم یه پلاگین داشبور سورس باز و قدرتمند با امکانات زیاد برای نمایش اطلاعات دیتابیس Elastic هست و از اون برای نمایش خطا ها و جستجو کردن و نمودار گرفتن استفاده می کنیم
🔸 کتابخانه Serilog هم میشه گفت بهترین کتابخانه Logging هست. نسبت به NLog جدید تره و طراحی مدرن تری داره و میزان رشد محبوبیتش هم بیشتره؛ پس میشه گفت از NLog هم بهتره (البته خیلی اختلاف ندارند)
این کتابخونه قابلیت های زیادی داره که به لطف پلاگین های زیادی که برای Serilog وجود داره (اصطلاحا بهش میگن Sinks) براش فراهم شده و از لحاظ پرفرمنسی هم از NLog سریع تره.
🔹 تنها نکته مهم، استفاده از روش Structred Logging نسبت به حالت معمولی است. شاید فکر کنید دو دستور زیر هیچ تفاوتی نمیکنه!
ولی عملکرد این دو یکسان نبوده و خط دوم که به صورت Structred هست اطلاعات را به صورت جداگانه ضبط و ثبت میکنه درنتیجه در کنار متن خطا، یک فیلد به نام username با مقدار Ali نیز ذخیره میکنه که کار جستجو و کوئری زدن رو راحت تر میکنه
مقالات آموزش این سلوشن :
https://bit.ly/2EAjpTh
https://bit.ly/2EBUYFc
https://bit.ly/2X7g1Xn
https://bit.ly/2Exvs3C
مخزن نمونه کد :
https://github.com/thecarlo/elastic-kibana-netcore-serilog
___________
@IranAspMvc
#PerformanceTuning
کتابخانه های مختلفی برای لاگ کردن خطا ها در دات نت وجود داره، از جمله Elmah، NLog, Log4net و ...
کتابخانه Elmah بهترین انتخاب برای پروژه های کوچک و متوسطه، کار باهاش راحته و پنل ساده ای هم داره، ولی توی پروژه های بزرگ که تعداد لاگ ها خیلی زیاد میشه، دیگه Elmah جوابگو نیست، هم به خاطر سرعت کمش نسبت به بقیه کتابخانه ها و هم به خاطر پنل ضعیف اش که حتی یه سرچ هم نداره
در این شرایط راه های مختلفی هست مثل استفاده از سرویس های نگهداری لاگ Cloud-based مثل setry.io , elmah.io و ...
راه حل بعدی استفاده از برنامه های مدیریت لاگ مثل Seq هستند که بر خلاف مورد قبلی، یک سرویس خارجی نیست و روی سرور خودتون لاگ ها رو نگهداری میکنه و داشبورد قدرتمندی برای سرچ و کوئری گرفتن در اختیارتون میذاره (ولی پولیه)
🔰 راه حل حرفه ای تر و البته رایگان، استفاده از Serilog و ElasticSearch و Kibana هست
🔸دیتابیس ElasticSearch در واقع یک دیتابیس NoSql و یک Search Engine (موتور جستجو) سورس باز و فوق سریع (بر پایه Lucene) هست که قابلیت جستجو و کوئری زدن زدن (به صورت full text search) با سرعت و قدرت بالا رو داره از اون برای نگهداری لاگ ها استفاده خواهیم کرد
🔹پنل Kibana هم یه پلاگین داشبور سورس باز و قدرتمند با امکانات زیاد برای نمایش اطلاعات دیتابیس Elastic هست و از اون برای نمایش خطا ها و جستجو کردن و نمودار گرفتن استفاده می کنیم
🔸 کتابخانه Serilog هم میشه گفت بهترین کتابخانه Logging هست. نسبت به NLog جدید تره و طراحی مدرن تری داره و میزان رشد محبوبیتش هم بیشتره؛ پس میشه گفت از NLog هم بهتره (البته خیلی اختلاف ندارند)
این کتابخونه قابلیت های زیادی داره که به لطف پلاگین های زیادی که برای Serilog وجود داره (اصطلاحا بهش میگن Sinks) براش فراهم شده و از لحاظ پرفرمنسی هم از NLog سریع تره.
🔹 تنها نکته مهم، استفاده از روش Structred Logging نسبت به حالت معمولی است. شاید فکر کنید دو دستور زیر هیچ تفاوتی نمیکنه!
logger.Debug("UserName is : Ali");
logger.Debug("UserName is : {username}", "Ali");
ولی عملکرد این دو یکسان نبوده و خط دوم که به صورت Structred هست اطلاعات را به صورت جداگانه ضبط و ثبت میکنه درنتیجه در کنار متن خطا، یک فیلد به نام username با مقدار Ali نیز ذخیره میکنه که کار جستجو و کوئری زدن رو راحت تر میکنه
مقالات آموزش این سلوشن :
https://bit.ly/2EAjpTh
https://bit.ly/2EBUYFc
https://bit.ly/2X7g1Xn
https://bit.ly/2Exvs3C
مخزن نمونه کد :
https://github.com/thecarlo/elastic-kibana-netcore-serilog
___________
@IranAspMvc
✅ حرفه ای ترین سلوشن Logging در NETCore. با استفاده از Serilog و ElasticSearch و Kibana
#PerformanceTuning
کتابخانه های مختلفی برای لاگ کردن خطا ها در دات نت وجود داره، از جمله Elmah، NLog, Log4net و ...
کتابخانه Elmah بهترین انتخاب برای پروژه های کوچک و متوسطه، کار باهاش راحته و پنل ساده ای هم داره، ولی توی پروژه های بزرگ که تعداد لاگ ها خیلی زیاد میشه، دیگه Elmah جوابگو نیست، هم به خاطر سرعت کمش نسبت به بقیه کتابخانه ها و هم به خاطر پنل ضعیف اش که حتی یه سرچ هم نداره
در این شرایط راه های مختلفی هست مثل استفاده از سرویس های نگهداری لاگ Cloud-based مثل setrny.io , elmah.io و ...
راه حل بعدی استفاده از برنامه های مدیریت لاگ مثل Seq هستند که بر خلاف مورد قبلی، یک سرویس خارجی نیست و روی سرور خودتون لاگ ها رو نگهداری میکنه و داشبورد قدرتمندی برای سرچ و کوئری گرفتن در اختیارتون میذاره (ولی پولیه)
🔰 راه حل حرفه ای تر و البته رایگان، استفاده از Serilog و ElasticSearch و Kibana هست
🔸دیتابیس ElasticSearch در واقع یک دیتابیس NoSql و یک Search Engine (موتور جستجو) سورس باز و فوق سریع (بر پایه Lucene) هست که قابلیت جستجو و کوئری زدن زدن (به صورت full text search) با سرعت و قدرت بالا رو داره از اون برای نگهداری لاگ ها استفاده خواهیم کرد
🔹پنل Kibana هم یه پلاگین داشبور سورس باز و قدرتمند با امکانات زیاد برای نمایش اطلاعات دیتابیس Elastic هست و از اون برای نمایش خطا ها و جستجو کردن و نمودار گرفتن استفاده می کنیم
🔸 کتابخانه Serilog هم میشه گفت بهترین کتابخانه Logging هست. نسبت به NLog جدید تره و طراحی مدرن تری داره و میزان رشد محبوبیتش هم بیشتره؛ پس میشه گفت از NLog هم بهتره (البته خیلی اختلاف ندارند)
این کتابخونه قابلیت های زیادی داره که به لطف پلاگین های زیادی که برای Serilog وجود داره (اصطلاحا بهش میگن Sinks) براش فراهم شده و از لحاظ پرفرمنسی هم از NLog سریع تره.
🔹 تنها نکته مهم، استفاده از روش Structred Logging نسبت به حالت معمولی است. شاید فکر کنید دو دستور زیر هیچ تفاوتی نمیکنه!
مقالات آموزش این سلوشن :
https://bit.ly/2EAjpTh
https://bit.ly/2EBUYFc
https://bit.ly/2X7g1Xn
https://bit.ly/2Exvs3C
مخزن نمونه کد :
https://github.com/thecarlo/elastic-kibana-netcore-serilog
_____________
@DotNetZoom
#PerformanceTuning
کتابخانه های مختلفی برای لاگ کردن خطا ها در دات نت وجود داره، از جمله Elmah، NLog, Log4net و ...
کتابخانه Elmah بهترین انتخاب برای پروژه های کوچک و متوسطه، کار باهاش راحته و پنل ساده ای هم داره، ولی توی پروژه های بزرگ که تعداد لاگ ها خیلی زیاد میشه، دیگه Elmah جوابگو نیست، هم به خاطر سرعت کمش نسبت به بقیه کتابخانه ها و هم به خاطر پنل ضعیف اش که حتی یه سرچ هم نداره
در این شرایط راه های مختلفی هست مثل استفاده از سرویس های نگهداری لاگ Cloud-based مثل setrny.io , elmah.io و ...
راه حل بعدی استفاده از برنامه های مدیریت لاگ مثل Seq هستند که بر خلاف مورد قبلی، یک سرویس خارجی نیست و روی سرور خودتون لاگ ها رو نگهداری میکنه و داشبورد قدرتمندی برای سرچ و کوئری گرفتن در اختیارتون میذاره (ولی پولیه)
🔰 راه حل حرفه ای تر و البته رایگان، استفاده از Serilog و ElasticSearch و Kibana هست
🔸دیتابیس ElasticSearch در واقع یک دیتابیس NoSql و یک Search Engine (موتور جستجو) سورس باز و فوق سریع (بر پایه Lucene) هست که قابلیت جستجو و کوئری زدن زدن (به صورت full text search) با سرعت و قدرت بالا رو داره از اون برای نگهداری لاگ ها استفاده خواهیم کرد
🔹پنل Kibana هم یه پلاگین داشبور سورس باز و قدرتمند با امکانات زیاد برای نمایش اطلاعات دیتابیس Elastic هست و از اون برای نمایش خطا ها و جستجو کردن و نمودار گرفتن استفاده می کنیم
🔸 کتابخانه Serilog هم میشه گفت بهترین کتابخانه Logging هست. نسبت به NLog جدید تره و طراحی مدرن تری داره و میزان رشد محبوبیتش هم بیشتره؛ پس میشه گفت از NLog هم بهتره (البته خیلی اختلاف ندارند)
این کتابخونه قابلیت های زیادی داره که به لطف پلاگین های زیادی که برای Serilog وجود داره (اصطلاحا بهش میگن Sinks) براش فراهم شده و از لحاظ پرفرمنسی هم از NLog سریع تره.
🔹 تنها نکته مهم، استفاده از روش Structred Logging نسبت به حالت معمولی است. شاید فکر کنید دو دستور زیر هیچ تفاوتی نمیکنه!
logger.Debug("UserName is : Ali");
logger.Debug("UserName is : {username}", "Ali");
ولی عملکرد این دو یکسان نبوده و خط دوم که به صورت Structred هست اطلاعات را به صورت جداگانه ضبط و ثبت میکنه درنتیجه در کنار متن خطا، یک فیلد به نام username با مقدار Ali نیز ذخیره میکنه که کار جستجو و کوئری زدن رو راحت تر میکنهمقالات آموزش این سلوشن :
https://bit.ly/2EAjpTh
https://bit.ly/2EBUYFc
https://bit.ly/2X7g1Xn
https://bit.ly/2Exvs3C
مخزن نمونه کد :
https://github.com/thecarlo/elastic-kibana-netcore-serilog
_____________
@DotNetZoom
🔰 یک نکته پرفرمنسی درباره Logging
🔸استفاده از تامین کننده Console برای Logging در حین ارائه نهایی (Production) به شدت باعث کند شدن و کاهش کارآیی برنامه خواهد شد. بهتر است این تامین کننده را صرفا در محیط Development تنظیم کنید (مانند تصویر)
🔹اگر از WebHost.CreateDefaultBuilder استفاده می‌کنید، به صورت پیشفرض سه تامین کننده Console و Debug و EventSource ثبت خواهند شد پس لازم است ابتدا آن ها را توسط متد ClearProviders حذف کنید
#PerformanceTuning
_________
@DotNetZoom
🔸استفاده از تامین کننده Console برای Logging در حین ارائه نهایی (Production) به شدت باعث کند شدن و کاهش کارآیی برنامه خواهد شد. بهتر است این تامین کننده را صرفا در محیط Development تنظیم کنید (مانند تصویر)
🔹اگر از WebHost.CreateDefaultBuilder استفاده می‌کنید، به صورت پیشفرض سه تامین کننده Console و Debug و EventSource ثبت خواهند شد پس لازم است ابتدا آن ها را توسط متد ClearProviders حذف کنید
#PerformanceTuning
_________
@DotNetZoom