نوشته های نوید خلیلیان

انتشار Docker Bake (سورپرایز داکر)

نوید خلیلیان — Mon, 05 May 2025 13:35:31 +0330

خب، قراره یه مقاله‌ی باحال و خودمونی درباره‌ی Docker Bake بنویسم که تازه تو Docker Desktop 4.38 به‌صورت عمومی (GA) منتشر شده.🚀چی هست حالا؟!تصور کن داری یه پروژه‌ی برنامه‌نویسی کار می‌کنی و باید چند تا image داکری بسازی. حالا هر کدوم از این image ها کلی دستور و flag و متغیر محیطی دارن که باید تو خط فرمان (CLI) بنویسی. خب، این کار یه کم اعصاب‌خوردکنه، نه؟ یهو یه پرچم رو اشتباه می‌زنی، یا یه متغیر رو جا می‌ندازی و کل پروسه‌ی ساخت به هم می‌ریزه. 😫 حالا Docker Bake اومده که این دردسرها رو برات حل کنه!ابزار Docker Bake بهت اجازه می‌ده به‌جای اینکه کلی دستور پیچیده تو خط فرمان بنویسی، همه‌چیز رو تو یه فایل مرتب و خوانا تعریف کنی. این فایل می‌تونه به فرمت HCL (زبان HashiCorp)، YAML یا JSON باشه. انگار داری یه فایل شبیه Dockerfile یا docker-compose میسازی، همه‌ی دستورات و مراحل رو یه جا لیست می‌کنی، بعد فقط می‌گی «بیک کن!» و داکر خودش بقیه کار رو انجام می‌ده. 🥮خب، حالا بیایم چند تا دلیل باحال رو با هم ببینیم که چرا Docker Bake این‌قدر جذابه:دیگه لازم نیست خط فرمان رو شخم بزنی!قبلاً باید برای هر image یه دستور docker build طولانی می‌نوشتی، پر از پرچم و متغیر. حالا با Docker Bake، همه‌چیز رو تو یه فایل می‌نویسی و فقط با یه دستور ساده (docker build bake) همه‌چیز رو اجرا می‌کنی. انگار از یه جنگل پر از علف هرز اومدی تو یه باغ مرتب! 🌳همه‌چیز با هم و سریع!اگه چند تا image داری که باید بسازی، Docker Bake می‌تونه همه‌شون رو موازی (parallel) بسازه. این یعنی به‌جای اینکه یکی‌یکی منتظر تموم شدن هر ساخت بمونی، همه با هم ساخته می‌شن و کلی تو وقت صرفه‌جویی می‌شه. تازه، اگه چند تا image سری فایل مشترک دارن، Docker Bake اینا رو یک‌بار می‌خونه و کار رو سریع‌تر می‌کنه (بهش می‌گن deduplication).خوانا و تمیزفایل‌های Bake خیلی خوانا و مرتبن. می‌تونی توشون همه‌ی تنظیمات، وابستگی‌ها و هدف‌ها (targets) رو مشخص کنی. این یعنی اگه یکی دیگه بخواد پروژه‌ت رو ببینه، خیلی راحت می‌فهمه چی به چیه. حتی می‌تونی مثل یه حرفه‌ای، از متغیرها و ارث‌بری (inheritance) استفاده کنی که کدت تمیزتر بشه.منعطف و قدرتمندمی‌تونی با Docker Bake کارهای پیچیده‌ای مثل ساخت image برای چند پلتفرم (مثل linux/amd64 و linux/arm64) یا حتی matrix builds رو انجام بدی. این یعنی می‌تونی یه عالمه تنظیمات مختلف رو با یه فایل ساده مدیریت کنی.دوست خوب Docker Composeاگه از قبل با Docker Compose کار می‌کردی، خبر خوب اینه که Bake می‌تونه مستقیم از فایل‌های Compose استفاده کنه. یعنی لازم نیست همه‌چیز رو از صفر شروع کنی. فقط فایل Compose رو بنداز تو پروژه‌ت و Bake بقیه‌ش رو هندل می‌کنه.یه مثال ساده: چطور با Docker Bake شروع کنیم؟فرض کن یه پروژه داری که دو تا image نیاز داره: یکی برای فرانت‌اند (وب) و یکی برای بک‌اند (سرور). قبلاً باید دو تا دستور docker build جداگونه می‌نوشتی. حالا با Docker Bake، یه فایل به اسم docker-bake.hcl درست می‌کنی و توش این‌جوری می‌نویسی:group "default" { targets = ["frontend", "backend"]}target "frontend" { context = "./frontend" dockerfile = "frontend.Dockerfile" tags = ["myapp/frontend:latest"]}target "backend" { context = "./backend" dockerfile = "backend.Dockerfile" tags = ["myapp/backend:latest"] }حالا فقط کافیه این دستور رو بزنی:docker build bakeچند سالی Docker Bake به‌صورت آزمایشی بود و حالا که عمومی شده، کلی ویژگی باحال بهش اضافه کردن:انتقال سریع‌تر فایل‌ها: اگه چند تا target داری که از یه سری فایل مشترک استفاده می‌کنن، Docker Bake این فایل‌ها رو فقط یه بار منتقل می‌کنه (deduplicated context transfers). این باعث می‌شه سرعت ساخت خیلی بالاتر بره.ویژگی‌های جدید HCL: می‌تونی از توابع سفارشی و ماتریس‌های پیچیده‌تر استفاده کنی.پشتیبانی بهتر از CI/CD: اگه تو خط تولید نرم‌افزارت (CI/CD pipeline) از داکر استفاده می‌کنی، Bake خیلی راحت با ابزارهای مثل Jenkins یا GitHub Actions و Gitlab جور درمیاد.اعتبارسنجی متغیرها: مثل Terraform، می‌تونی قوانین اعتبارسنجی برای متغیرها تعریف کنی که اشتباهات رو زودتر پیدا کنی.کی باید از Docker Bake استفاده کنی؟اگه یکی از این موقعیت‌ها برات آشناست، Docker Bake می‌تونه رفیق شفیقت بشه:داری چند تا image داکری رو همزمان می‌سازی (مثل یه پروژه‌ی میکروسرویس).پروژه‌ مونوریپو (monorepo) هست و کلی سرویس مختلف داری.خسته شدی از نوشتن اسکریپت‌های طولانی برای مدیریت build ها.می‌خوای ساخت‌های چندپلتفرمی (multi-platform) انجام بدی بدون دردسر.می‌خوای یه روش تمیز و استاندارد برای تیم‌ت داشته باشی که همه بتونن بفهمن چی به چیه.چطور شروع کنی؟داکر رو آپدیت کن: مطمئن شو که Docker Desktop 4.38 یا بالاتر رو نصب کردی.📷یه فایل Bake بساز: یه فایل به اسم docker-bake.hcl یا docker-bake.json تو پروژه‌ت درست کن.تنظیماتت رو بنویس: هدف‌ها (targets) و گروه‌ها (groups) رو تو فایل تعریف کن.دستور رو اجرا کن: با docker build bake ساخت رو شروع کن.لذت ببر! 😎حرف آخرابزار Docker Bake مثل یه دستیار باحاله که میاد و کارای سخت و تکراری ساخت image داکری رو برات ساده می‌کنه. چه برنامه‌نویس تازه‌کاری باشی که تازه داری با داکر کار می‌کنی، چه یه حرفه‌ای که تو CI/CD غرق شدی، این ابزار می‌تونه کلی وقت و اعصاب برات ذخیره کنه. ممنونم که وقت گذاشتی و مقاله رو خوندی.

استفاده از MassTransit و RabbitMQ در Windows service

نوید خلیلیان — Fri, 13 Oct 2023 22:45:12 +0330

سلام دوستان. توی یکی از پروژه ها مجبور شدیم برای استفاده از یک سرویس خاص که از Com Object ها استفاده میکرد و فقط در پلتفرم ویندوز قابل اجرا بود یک ویندوز سرویس(Service A) بنویسیم. با توجه به اینکه سیستم اصلی(Service B) تحت لینوکس داکرایز شده بود مجبور شدیم یک راه برای ارتباط دو سرویس ویندوز و لینوکس در نظر بگیریم.راه های مختلفی وجود داشت برای برقراری ارتباط ولی ما ترجیح دادیم از یک Message broker استفاده کنیم.برای راحتی استفاده من سورس کد رو اینجا آپلود کردم.MassTransit.WindowsServiceبرای پیش نیاز باید با RabbitMQ یا MassTransit آشنایی داشته باشید.سوالی بود کامنت کنید.موفق و پیروز باشید.

سلام SigNoz ، خداحافظ ELK

نوید خلیلیان — Fri, 20 Jan 2023 13:54:44 +0330

شروع این مقاله یکمی سخته چون واقعا نمیدونم از کجا باید شروع کنم.ابزار های مختلفی در حوزه مانیتورینگ سرویس ها و اپلیکیشن ها وجود دارند که تقریبا همه روی سه موضوع Trace و Log و Metric مانور میدن. کار کردن با بعضی هاشون خیلی سخت و پیچیده بنظر میاد. بعضی ها هم خیلی ساده هستند ولی کامل نیستند.با توجه به تجربه ای که داشتم از SigNoz میشه بعنوان یکی از کاملترین و ساده ترین ابزارها اسم برد. SigNoz یک ابزار متن باز هست که میتونید در گیت هاب سورس کدش رو مشاهده کنید. اکثر سیستم های مانیتورنیگ از یک collector برای جمع آوری اطلاعات مربوط به Trace,Log,Metric استفاده میکنند. SigNoz برای اینکار از OpenTelemetry استفاده میکنه و اطلاعات جمع آوری شده رو توی یک پنل در اختیار شما قرار میده.دقت کنید که گفتیم در یک پنل. یعنی نیاز نیست برای Trace به ابزاری مثل Jeager یا برای ویژال کردن دیتاهایی مثل Metric به ابزاری مثل Kibana رجوع کنید. داکیومنت SigNoz خیلی کامله و برای همه زبان ها نمونه کد های کاملی رو قرار داده. چون داکیومنت ها و مقالات خودش کامل و واضح هست دیگه من مثال نمیزنم و پیشنهاد میکنم طبق داکیومنت خودش برای پیاده سازی پیش برید. هر زبانی که توسط OpenTelemetry پشتیبانی بشه میتونه از SigNoz هم استفاده کنه.برای اینکه ببینید چه زبان هایی توسط OpenTelemetry پشتیبانی میشه به این لینک نگاهی بندازید.چه کارهایی میتونیم با SigNoz انجام بدیم؟مانیتورینگ سرویس یا اپلیکیشن بر اساس معیار های مختلف مثل : latency, requests per second, error ratesمانیتورینگ زیرساخت مثل میزان استفاده از CPU و Ram و Disk I/O و ...ردیابی درخواست کاربر از زمان شروع تا جایی که response برای کاربر ارسال میشه.تنظیم هشدار هایی بر اساس Metric ها. مثلا اگر میزان استفاده از CPU از 80 درصد بیشتر شد به ما هشدار بده.کمک میکنه که بفهمیم در چه حالتی باگ بوجود اومده. یعنی میفهمیم که دقیقا کاربر چه کاری انجام داده که منجر به خطا شده.بر اساس داشبورد ها و نمودار های مختلف میتونیم گزارشات مختلفی را ببینیم. مثلا ببینیم فلان API چقدر استفاده شده و در چه بازه زمانی زیر بار بوده.خیلی موارد دیگه ای هم هست اگه بخوام لیست کنم خوندن مقاله حوصله سر بر میشه.در کل با این ابزار دیگه نیازی به Elastic,Logstash,Kibana,Grafana,Jaeger و خیلی چیزهای دیگه ندارید.اینجا یدونه عکس داریم که معماری استفاده شده برای طراحی خود SigNoz رو میتونیم مشاهده کنیمتوضیحات بیشتر راجع به معماری SigNoz رو میتونید اینجا ببینید.گام اول :Trace چیست؟در واقع همونطور که موقع دیباگ کردن برنامه شما از Trace سورس کد استفاده میکنید برای اینکه بفهمید اشکال از کجاست، سرویس Trace در SigNoz همون دیتا هارو در محیط Production در اختیار شما قرار میده که لازم نباشه به سختی دنبال اشکال بگردید.یعنی از زمانی که یک درخواست به سمت سرویس شما میاد تا زمانی که خروجی به کاربر ارسال میشه اطلاعات کاملی از پارامتر های ارسالی کاربر، ارتباطات با دیتابیس ، ارتباطات با سرویس های خارجی و ... رو برای شما ذخیره میکنه که از روی اونها کامل متوجه اشکال میشید و نیاز به پیدا کردن خطا نباشید.گام دوم: Log چیست؟همونطور که میدونید شما برای کاربرد ها مختلفی نیاز به ثبت لاگ دارید. لاگ ها میتونند در سطوح مختلفی ذخیره بشن. مثلا در سطح Information یا Debug. ابزار SigNoz این امکان رو به شما میده که لاگ هارو بر اساس سطحی که نیاز دارید ذخیره کنید.گام سوم: Metric چیست؟برای توضیح Metric یک مثال میزنم. فرض کنید می خواهید یک حد آستانه در نظر بگیرید برای کار خاصی و اگر به اون حد رسید به شما هشدار داده بشه. مثلا اگر تعداد کاربران آنلاین از 1000 نفر بیشتر شد به شما هشدار داده بشه. به اینها میگن Metric. که البته این یک مثال ساده بود برای آشنایی با Metric ها.گام چهارم: نصب SigNozبرای نصب SigNoz پیشنهاد میکنم به داکیومنت خودش مراجعه کنید، چون بر اساس محیط های مختلف روش های نصب متفاوتی داره. شما میتونید بر اساس محیطی که دارید روش نصب رو بر اساس داکیومنت دنبال کنید.داکیومنت نصب رو از اینجا ببینیدگام پنجم: بلاگ SigNozپیشنهاد میکنم یه نگاهی به بلاگ SigNoz به این آدرس بندازید. اونجا افراد مختلف برای زبان ها و پلتفرم های مختلف داکیومنت هایی از تجربه هاشون رو آوردن که میتونه خیلی کمک کننده باشه.امیدوارم که اطلاعات مفید بوده باشه. موضوع APM خیلی گسترده هست و ابزار ها و روش های زیادی داره. من اینجا سعی کردم یک ابزار خوب رو معرفی کنم و سعی کردم برای اون دسته از مخاطبانی که کمتر روی موضوع APM کار کردند توضیحات ابتدایی بیشتری بدم. در صورتی که سوالی داشتید کامنت بنویسید سعی میکنم در حد دانشی که دارم پاسخگو باشم.اگر می خواهید از من و زمانی که برای نوشتن این مقالات صرف می شود حمایت کنید، می توانید برای من قهوه بخرید.

افزایش پرفورمنسAPI با استفاده از FastEndpoints

نوید خلیلیان — Fri, 16 Dec 2022 17:47:33 +0330

سلام به همه دوستان. در این مقاله کوتاه می خواهیم به معرفی FastEndpoints بپردازیم.معرفی FastEndPointsطبق توضیح سایت طراح این پکیج می تونیم FastEndpoints را بعنوان جایگزین MVC و Netcore Minimal APIs معرفی کنیم. در واقع طبق گفته های سازنده و بنچ مارک انجام شده این پکیج توانایی هندل کردن 35K درخواست بیشتر در ثانیه داره.درواقع این پروژه از Minimal API در Dotnet 6 الگو برداری کرده و سعی میکنه مباحث Clean code را جهت نگهداری کد تمیزتر در پروژه پوشش بده.یکی از دلایل تمیزتر بودن کد ها با FastEndpoints به دلیل جایگزین کردن الگوی MVC با REPR هست.معرفی کوتاه الگوی REPR[R]EQUEST [E]ND[P]OINTS [R]ESPONSEدر واقع MVC یک رویکرد سنتی بود که مایکروسافت از اون بعنوان ترویج دات نت استفاده کرد. یکی از مشکلاتی که MVC داره پیچیده شدن پروژه ها و خارج شدن از چهارچوب استاندارد مبتنی بر REST هست.الگوی REPR هر Endpoint را به سه بخش تقسیم میکنه:Requestداده ای که API انتظار دارد بعنوان ورودی بگیره2. Endpointمنطقی که در بدنه API پیاده سازی شده3. Responseخروجی که API برمیگردونه.این الگو اصل Single Responsibility از SOLID را مبنای پیاده سازی قرار داده و فقط ورودی و خروجی برای اون اهمیت داره.بعضی موافق API هیچ ورودی یا خروجی نداره و فقط یک کد Status برمیگردونه.بریم یدونه مثال در ادامه باهم ببینیماستفاده از FastEndpoints در DotNet 6.0اول یدونه پروژه DotNet 6.0 می سازیم و بسته های زیر رو نصب میکنیمdotnet add package FastEndpoints // The actual library dotnet add package FastEndpoints.Swagger // For Swagger suppoبسته اول رو برای استفاده از FastEndpointsو دومی رو برای کانفیگ Swagger نصب کردیم.پروژه قراره یدونه API داشته باشه که لیست مشتریان رو برمیگردونه. اول یدونه پوشه به اسم Features توی Root پروژه میسازیم و درون اون یدونه پوشه دیگه به اسم Customers ایجاد میکنیم.قراره API های ما که توسط فرانت استفاده میشن توی این پوشه قرار بگیره.ساختار پروژه شبیه این میشهSolution - Project -- Features --- Customers ---- GetAllCustomers ----- Models.cs ----- Endpoint.cs ----- (Mapper.cs)همونطور که میدونید با توجه به استاندارد نام گذاری از Get ابتدای نام Name space استفاده کردیم.خوب بریم فایل Program.cs رو به این شکل تغییر بدیم:global using FastEndpoints;global using FastEndpoints.Validation;var builder = WebApplication.CreateBuilder();builder.Services.AddFastEndpoints();var app = builder.Build();app.UseAuthorization();app.UseFastEndpoints();app.Run();حالا کلاس request و response را میسازیمpublic class Request{ public Guid Id { get; init; } public string FirstName { get; set; } public string LastName { get; set; } public string CustomerNo { get; set; }}public class Response{ public string FirstName { get; set; } public string LastName { get; set; } public string CustomerNo { get; set; }}حالا می تونیم کلاس Endpoint رو بسازیم:public class Endpoint : EndpointWithoutRequest>{ public override void Configure() { Verbs(Http.GET); Routes("/Customers/GetAllCustomers"); AllowAnonymous(); } public override async Task HandleAsync(CancellationToken ct) { var customers = new List(); customers.Add( new Response { CustomerNo = "1", FirstName = "NAVID", LastName = "KHALILIAN", }); customers.Add( new Response { CustomerNo = "2", FirstName = "ALI", LastName = "KHALILIAN", }); await SendAsync(customers, cancellation: ct); }}کلاس Endpoint از اینترفیس EndpointWithoutRequest ارث بری کرده و خروجی اون لیستی از کلاس های response هست. اینجا ما از EndpointWithoutRequest ارث بری کردیم چون متد ما ورودی نداره.حالا باید دو قسمت Configure و Handle رو مطابق چیزی که توضیح دادیم پیاده سازی کنیم.در کل 4 تا اینترفیس برای ارث بری وجود داره:Endpoint از این اینترفیس وقتی که تایپ ورودی مشخصه ولی خروجی تایپ مشخصی نداره مثل Generic استفاده میشهEndpoint این اینترفیس رو زمانی که تایپ ورودی و خروجی مشخصه استفاده میکنیم. استفاده از این اینترفیس دو تا مزیت داره. اولیش قابلیت تست نویسی راحت تر و دومی پیاده سازی ولیدیشن های بهتر هست.EndpointWithoutRequest از این اینترفیس وقتی که ورودی نداریم و تایپ خروجی هم میتونه Generic باشه استفاده میکنیمEndpointWithoutRequest از این اینترفیس زمانی که تایپ ورودی مشخص نیست ولی خروجی مشخصه استفاده میکنیمنکته: اگر API ورودی و خروجی نداشته باشه میتونه به شکل زیر پیاده سازی بشه:public class MyEndpoint : Endpoint { }وقتش رسیده که بریم Swagger رو کانفیگ کنیممحتوای فایل program.cs رو به شکل زیر تغییر میدیم:global using FastEndpoints;global using FastEndpoints.Validation;using FastEndpoints.Swagger; var builder = WebApplication.CreateBuilder();builder.Services.AddFastEndpoints();builder.Services.AddSwaggerDoc(); var app = builder.Build();app.UseAuthorization();app.UseFastEndpoints();app.UseOpenApi();app.UseSwaggerUi3(c => c.ConfigureDefaults());app.Run();اگر همه چیز به شکل صحیح کانفیگ شده باشه حالا میتونیم API رو با کمک Swagger تست کنیم. من فرض رو بر این گذاشتم که مخاطب این مقاله قبلا با Swagger کار کرده و توضیحات اضافه نمیدم. فقط تصویر Swagger رو پیوست کردم که خروجی رو با کار خودتون مقایسه کنید.حالا که تا اینجای موضوع رو بررسی کردیم بهتره یه نگاهی هم به موضوع Dependency Injection موقع استفاده از FastEndpoints بندازیم.بیایید یدونه اینترفیس به اسم ICustomerService و یدونه سرویس به اسم CustomerService بسازیمpublic interface ICustomerService{ Task> GetCustomers();} public class CustomerService : ICustomerService{ public Task> GetCustomers() { return Task.FromResult(new List { new Response { CustomerNo = "1", FirstName = "NAVID", LastName = "KHALILIAN"}, new Response { CustomerNo = "2", FirstName = "ALI", LastName = "KHALILIAN"}, }); }}حالا سرویس رو رجیستر میکنیمbuilder.Services.AddScoped();حالا کلاس Endpoint رو تغییر میدیم و از سرویسی که ساختیم استفاده میکنیمpublic class Endpoint : EndpointWithoutRequest>{ private readonly ICustomerService _customerService; public Endpoint(ICustomerService customerService) { _customerService = customerService; } public override void Configure() { Verbs(Http.GET); Routes("/Customers/GetAllCustomers"); AllowAnonymous(); } public override async Task HandleAsync(CancellationToken ct) { var customers = await _customerService.GetCustomers(); await SendAsync(customers, cancellation: ct); }}همونطور که متوجه شدید بحث Dependency Injection مثل قبل قابل استفاده هست و نحوه استفاده از اون در FastEndpointتغییری نسبت به MVC نداشته.نتیجه گیری:به نظر من کد های نوشته شده با FastEndpoints نسبت به MVC واقعا تمیز تر و خوانا تره. البته هنوز از این پکیج توی پروژه واقعی استفاده نکردم و نتونستم پرفورمنس اون رو توی پروژه تجاری بررسی کنم ولی طبق بررسی که روی سایت توسعه دهنده و گیتهاب اون داشتم مستندات واقعا کامل و جامع هست. همچنان پروژه داره رشد میکنه و شاید در آینده این مکانیزم جایگزین MVC بشه. میتونید Github پروژه رو بررسی کنید و اگه خوشتون اومد لایک کنید که بیشتر مورد توجه قرار بگیره و به رشد اون کمک کنه.امیدوارم این مقاله برای شما مفید بوده باشه.اگر می خواهید از من و زمانی که برای نوشتن این مقالات صرف می شود حمایت کنید، می توانید برای من قهوه بخرید.موفق و پیروز باشید.

عملکرد API های خود را با NBomber آزمایش کنید(بخش دوم)

نوید خلیلیان — Tue, 13 Dec 2022 19:30:41 +0330

عملکرد API های خود را با NBomber آزمایش کنید

نوید خلیلیان — Fri, 09 Dec 2022 20:23:40 +0330

اگر سی شارپ زبان مورد استفاده شما نیست، نگران نباشید. فقط به اصول اولیه این تکنیک تست نیاز دارید. اگر می خواهید اصول اولیه تکنیک تست بار را یاد بگیرید، می توانم خواندن این مطلب را به شما توصیه کنم.جهت جلوگیری از خستگی خواننده کل مطلب را در دو بخش تقسیم میکنم:1- بخش اول شامل توضیح اصول تست و مشاهده یک نمونه(شما در حال خواندن این بخش هستید)2- بخش دوم شامل آموزش تست نویسی واقعی و بررسی عمیق تر نتایج تست بارتست بار چیست؟تست بار ، تعاملات n کاربر با سیستم را شبیه سازی می کند و اطلاعاتی از قبیل زمان پاسخ دهی به کاربر را بر اساس معیارهایی مانند استفاده از RAM و CPU جمع آوری میکند. تست بار به شما کمک میکند تا مشکلات عملکردی را پیدا کنید که ممکن است فقط برای بیش از 1000 کاربر رخ دهد، و پس از آن باعث مشود مشکلات بزرگی برای عملکرد سرویس شما ایجاد کند. این تجربه برای ما یک کوئری نا کارآمد بود که باعث می شد به طور مکرر نیاز به راه اندازی مجدد سرویس و مقیاس بندی عمودی و افقی(سخت افزاری و نرم افزاری) شود.موضوع تست بار چیزی فراتر از این است که بپرسیم آیا یک سرور می تواند اتصال همزمان n کاربر را مدیریت کند؟ بعنوان مثال ممکن است بگویید در عمل این اتفاق هیچ وقت برای سرویس من اتفاق نخواهد افتاد و نباید به آن اهمیت بدهیم!ممکن است این اتفاق زمانی که مورد حمله DDos قرار میگیریم مورد توجه قرار گیرد، که البته در این مطلب راجع به آن صحبت نمی کنیم. علاوه بر این ، ما باید رفتار واقعی کاربران با سیستم را شبیه سازی کنیم و سپس اطلاعات جمع آوری شده توسط تست بار را جهت محاسبه زمان پاسخ دهی واقعی سرویس خودمان بدست بیاوریم.این کار برای پیدا کردن درخواست هایی که باعث ایجاد مشکل در سرویس دهی شما می شوند و بررسی آنها توسط ابزار های نظارت بر عملکرد سرویس شما بسیار مفید است.ابزار NBomber عملکرد بسیار خوبی در شبیه سازی درخواست ها برای پیدا کردن مشکلات عملکردی سرویس شما دارد.چرا باید سرویس خودمان را تست کنیم؟یاکوب نیلسن(راجع به ایشان بیشتر بخوانید) سه محدودیت زمان پاسخ را برای برنامه ها تعریف کرده است:0.1(صد میلی ثانیه) حدود زمانی است که کاربر احساس کند سیستم به صورت آنی واکنش نشان میدهد، به این معنی که هیچ باز خورد خاصی(مثلا نمایش ProgressBar) به جز نمایش نتیجه درخواست لازم نیست.1(یک) ثانیه حدود زمانی برای بدون وقفه ماندن جریان فکری کاربر است.حتی اگر کاربر متوجه تاخیر شود. معمولا در تاخیر هعای بیش از 100 میلی ثانیه تا 1 ثانیه بازخورد خاصی لازم نیست، اما کاربر احساس کار کردن با سیستم بصورت آنی را از دست میدهد.10(ده) ثانیه حدود زمانی است که می توان توجه کاربر را بر روی سیستم متمرکز نگه داشت.برای تاخیر های طولانی تر کاربران معمولا می خواهند تا زمان اتمام درخواست کار دیگری انجام دهند.بنا بر این باید به آنها بازخورد داده شود که چه مدت زمان باید معطل بمانند. در طول تاخیر ، بازخورد دادن به کاربر بسیار مهم است مخصوصا مواقعی که زمان انجام کار بسیار متغیر باشد(مانند آپلود فایل که کاملا به سرعت شبکه و حجم فایل وابسته است)، زیرا کاربران نمیداند چه انتظاری از سیستم داشته باشند. شما نمی خواهید کاربران شما از سرویس شما به نحوی استفاده کننده که زمان پاسخ دهی آن بیشتر از 10 ثانیه باشد. بنابراین عملکرد سیستم می تواند تاثیر مستقیم روی جذب کاربر یا از دست دادن وی باشد.تست بار ابزاری است که قابلیت آزمایش تست عملکرد سیستم در شرایط واقعی، بدون داشتن کاربران واقعی را به ما می دهد.هنگامی که در یک استارت آپ هستید و در حال حاضر مانند من در حال آماده سازی برنامه خود برای انتشار هستید، آیا می توانید مطمعن باشید که این برنامه می تواند تعداد کاربران را که می خواهید داشته باشید مدیریت کند؟برای من همیشه یک نگرانی بزرگ وجود داشت که آیا برنامه می تواند به 10 نفر سرویس دهی کند؟ برای 1000 نفر چطور؟ یا حتی بیشتر؟ آیا میتواندی چنین آزمایشی را چندین بار در روز انجام دهید؟ من اینطور فکر نمی کنم. شما هرگز نمی توانید این کار را انجام دهید چون هیچ راهی برای آزمایش دستی وجود ندارد. اینجاست که تست بار وارد عمل می شود. با تست بار می توانید برنامه خود را تست استرس کنید و با اطمینان بگویید که برای صدها کاربر کار خواهد کرد. این موضوع نه تنها قبل از راه اندازی یک سرویس مهم است، بلکه قبل از راه اندازی یک ویژگی جدید نیز اهمیت دارد. زیرا ممکن است عملکرد برنامه شما را تحت تاثیر قرارداده و خراب کند بطوری که قبل از بروزرسانی نسخه جدید متوجه آن نخواهید شد. در بالا می‌توانید کاربری را مشاهده کنید که از برنامه‌ای که بدون آزمایش بارگذاری توسعه یافته است استفاده می‌کند. شما چنین کاربری را نمی خواهید! کاربرانی که قبلاً خوشحال بودند، اکنون می توانند ناراضی باشند، برنامه شما را ترک کنند یا ممکن است اشتراک را لغو کنند. مطمئناً امتیازات اعتماد کاربران خود را از دست خواهید داد. بنابراین پیشنهاد میکنم لطفاً برخی از تست های بار را نیز در CI خود ادغام کنید.چرا از NBomber استفاده کنیم؟بهتر است بگویم NBomber یک ابزار با کاربری راحت برای آزمایش عملکرد برنامه شماست که علاوه بر نوشتن و اجرا کردن سریع تست ها داده های مفیدی را در اختیار شما می گذارد تا با خیال راحت بصورت واقعی سرویس خود را تست کنید.بزرگترین مزیت شبیه سازی تست بار این است که شما فقط 100 درخواست را بصورت همزان اجرا نمی کنید بلکه رفتار واقعی کاربران را با توجه به اطلاعات ارائه شده توسط NBomber شبیه سازی می کنید.از آنجایی که خود تست ها به سادگی فراخوانی API های شماست، می توان گفت این یک تست از نوع جعبه سیاه است. این بدان معناست که با NBomber می توانید هر پروژه ای را بدون در نظر گرفتن زبان برنامه نویسی آن آزمایش کنید.یک مثال ساده از NBomber ببینیم!ابتدا یک پروژه Console Application ایجاد میکنیم.dotnet new console -n [project_name] -lang ["F#" or "C#"]dotnet new console -n NBomberTest -lang "F#"cd NBomberTestاضافه کردن پکیج NBomberdotnet add package NBomberمطمعن شوید که بسته Http را برای ارسال درخواست های http نصب کنیدdotnet add package NBomber.httpدر مرحله بعد بیایید یک مثال اجرایی را از تست وب سایت NBomber ببینیمusing System; using NBomber; using NBomber.Contracts; using NBomber.CSharp; using NBomber.Plugins.Http.CSharp; using NBomber.Plugins.Network.Ping;namespace NBomberTest { class Program { static void Main(string[] args) { var step = Step.Create("fetch_html_page", clientFactory: HttpClientFactory.Create(), execute: context => { var request = Http.CreateRequest("GET", "https://nbomber.com") .WithHeader("Accept", "text/html"); return Http.Send(request, context); }); var scenario = ScenarioBuilder .CreateScenario("simple_http", step) .WithWarmUpDuration(TimeSpan.FromSeconds(5)) .WithLoadSimulations( Simulation.InjectPerSec(rate: 100, during: TimeSpan.FromSeconds(30)) ); // creates ping plugin that brings additional reporting data var pingPluginConfig = PingPluginConfig.CreateDefault(new[] { "nbomber.com" }); var pingPlugin = new PingPlugin(pingPluginConfig); NBomberRunner .RegisterScenarios(scenario) .WithWorkerPlugins(pingPlugin) .Run(); } } }کد بالا را در فایل Program.cs پروژه که ایجاد کردید کپی کنید.مطمعن شوید که از C# نسخه 9 به بعد استفاده میکنید. اگر از نسخه قدیمی تر استفاده می کنید می توانید نسخه C# را در فایل .csproj پروژه خود به روز کنید.برای این کار تگ زیر را در فایل .csproj داخل تگ کپی کنید یا در صورت وجود مقدار آن را تغییر دهید.10.0حالا پروژه را اجرا کنید تا نتیجه بمباران را مشاهده کنید. :)نتیجه ای که در Console خواهید دید چیزی شبیه این می باشد:12:24:20 [INF] NBomber '2.1.5' Started a new session: '2022-03-23_11.24.44_session_787459f0'. 12:24:21 [INF] NBomber started as single node. 12:24:21 [INF] Plugins: no plugins were loaded. 12:24:21 [INF] Reporting sinks: no reporting sinks were loaded. 12:24:21 [INF] Starting init... 12:24:21 [INF] Target scenarios: 'simple_http'. 12:24:21 [INF] Init finished. 12:24:21 [INF] Starting warm up... simple_http ---------------------------------------- 100% 00:00:30 load: keep_constant, copies: 112:24:53 [INF] Starting bombing... simple_http ---------------------------------------- 100% 00:01:01 load: keep_constant, copies: 112:25:54 [INF] Stopping scenarios... 12:25:54 [INF] Calculating final statistics...────────────────────────────────────────────────────── test info ───────────────────────────────────────────────────────test suite: 'nbomber_default_test_suite_name' test name: 'nbomber_default_test_name'──────────────────────────────────────────────────── scenario stats ────────────────────────────────────────────────────scenario: 'simple_http' duration: '00:01:00', ok count: 662, fail count: 0, all data: 0 MB load simulation: 'keep_constant', copies: 1, during: '00:01:00' ┌────────────────────┬────────────────────────────────────────────────────────┐ │ step │ ok stats │ ├────────────────────┼────────────────────────────────────────────────────────┤ │ name │ fetch_html_page │ │ request count │ all = 662, ok = 662, RPS = 11 │ │ latency │ min = 59,66, mean = 90,47, max = 367,5, StdDev = 32,04 │ │ latency percentile │ 50% = 79,61, 75% = 92,48, 95% = 158,98, 99% = 209,15 │ └────────────────────┴────────────────────────────────────────────────────────┘──────────────────────────────────────────────────────── hints ─────────────────────────────────────────────────────────hint for Scenario 'simple_http': Step 'fetch_html_page' in scenario 'simple_http' didn't track status code. In order to track status code, you should use Response.Ok(statusCode: value)hint for Scenario 'simple_http': Step 'fetch_html_page' in scenario 'simple_http' didn't track data transfer. In order to track data transfer, you should use Response.Ok(sizeInBytes: value)12:25:55 [INF] Reports saved in folder:...بنا بر این NBomber سرویس را آزمایش کرد و اطلاعاتی در مورد آن جمع آوری کرد.برای درک خروجی تولید شده، اجازه دهید به اصول تست بار نگاه کنیم.اصول اولیه تست بار:در اسناد راهنمای NBomber توضیحات خوب و کاملی در مورد اصول اولیه تست بار وجود دارد. من سعی میکنم در اینجا به خلاصه ای از آنها اشاره کنم:مهمترین معیارهای تست بار:ابتدا نگاهی به آمار تولید شده در محله قبل داشته باشیم:┌────────────────────┬────────────────────────────────────────────────────────┐│ step │ ok stats │├────────────────────┼────────────────────────────────────────────────────────┤│ name │ fetch_html_page ││ request count │ all = 662, ok = 662, RPS = 11 ││ latency │ min = 59,66, mean = 90,47, max = 367,5, StdDev = 32,04 ││ latency percentile │ 50% = 79,61, 75% = 92,48, 95% = 158,98, 99% = 209,15 │└────────────────────┴────────────────────────────────────────────────────────┘Request count آمار مربوط به تعداد درخواست هاRPS تعداد درخواست های ارسال شده در ثانیهall تعداد همه درخواست هایی که در طول تست ارسال شدهok تعداد درخواست هایی که سیستم ما می تواند در یک ثانیه پاسخ دهد. این یک شاخص مهم برای ارزیابی عملکرد سیستم ما می باشد.Latency زمان بین ارسال درخواست و دریافت پاسخ. این پارامتر باید با تعداد در خواست در ثانیه(RPS) ارتباط خوبی داشته باشد.Latency percentileصدک تاخیر نشان دهنده چند درصد در یک زمان خاص است. بطور کلی نشان میدهد که ما چند درخواست را به خوبی پاسخ داده ایم و مدت زمان چند درصد پاسخ ها بد بوده است.این مثال فقط چند درخواست با تاخیر بیش از 200 میلی ثانیه دارد، اما نیمی از آن کمتر از 80 میلی ثانیه است.این به شما کمک میکند تا داده های فوق را طبقه بندی کنید.تقسیم بندی سیستم خود را در تست بار بشناسیددر تست بار سیستم ها به دو نوع تقسیم بندی می شوند:سیستم های بسته:تعداد کاربران ثابتی دارند، هر کاربر یک درخواست ارسال می کند و سپس منتظر پاسخ می ماند.این ارتباط بین API و Database خواهد بود. بنابر این پایگاه داده یک سیستم بسته است.سیستم های باز:تعداد کابران مشخص نیست. هرچیزی که از پروتکل هایی مانند HTTP استفاده میکند باید یک سیستم باز در نظر گرفته شود(مانند وب سایت ها).بر اساس این دانش نامه ما بعدا شبیه سازی صحیح را برای سیستم خود انتخاب خواهیم کرد. برای سیستم های بسته پارامتر های شبیه سازی می تواند بصورت ثابت در نظر گرفته شود، اما پیشنهاد من برای سیستم های باز استفاده از پارامتر های تصادفی است.ادامه را در بخش دوم بخوانید!