افت عملکرد در ساعات شلوغ
ورود همزمان کاربران، ثبت سفارش یا فراخوانی APIها با تأخیر و Timeout همراه میشود.
بررسی: همزمانی و ظرفیتبهینهسازی و مقیاسپذیری سامانههای داده و نرمافزار
کاربران بیشتر شدهاند، داده رشد کرده و حالا گزارشها دیر باز میشوند یا سامانه در ساعات شلوغ نفس کم میآورد. مسیر کندی را پیدا میکنیم، اصلاحات مؤثر را اولویت میدهیم و نتیجه را در شرایط قابل مقایسه میسنجیم.
برای مقایسه، یکی از دو ساختار را انتخاب کنید.
یک الگوی احتمالی برای وباپلیکیشن؛ اجرا به مدیریت Session، وضعیت مشترک، کنترل سلامت و ظرفیت پایگاه داده نیاز دارد.
این نشانهها نقطه شروع بررسی هستند. علت میتواند در کد، مدل داده، پایگاه داده یا زیرساخت باشد.
ورود همزمان کاربران، ثبت سفارش یا فراخوانی APIها با تأخیر و Timeout همراه میشود.
بررسی: همزمانی و ظرفیتبازشدن داشبورد، اعمال یک فیلتر ساده یا دریافت خروجی، جریان کار مدیر و کارشناس را متوقف میکند.
بررسی: مدل و مسیر کوئریبهروزرسانی داده یا تولید خروجی سنگین همزمان با استفاده روزانه، فشار ناگهانی به سامانه وارد میکند.
بررسی: زمانبندی و وابستگیهامنابع و هزینه افزایش یافتهاند، اما تجربه کاربر هنوز بهتر نشده و علت اصلی کندی مشخص نیست.
بررسی: گلوگاه و مصرف منابعبهینهسازی یعنی پیداکردن جایی که زمان، منابع یا ظرفیت هدر میرود؛ مقیاسپذیری یعنی برنامهریزی برای افزایش بار، بدون اینکه هر مرحله رشد به یک بحران تبدیل شود. دامنه کار میتواند از اصلاح یک مدل داده تا بازطراحی بخشی از معماری باشد.
نوع سامانه را انتخاب کنید تا دامنه بررسی و اصلاحات متناسب با آن را ببینید.
مدیر فروش فیلتر شعبه را عوض میکند، اما صفحه مدت زیادی در حالت انتظار میماند؛ همزمان Refresh هم کند شده است.
مسیر اجرای گزارش را از منبع داده تا مدل و نمایش بررسی میکنیم تا مشخص شود کندی از کدام لایه شروع میشود.
گزارش تشخیص کندی، فهرست اصلاحات اولویتدار و سنجش دوباره گزارش پس از تغییرات توافقشده.
برای Power BI Service، معماری و ظرفیت همان سرویس بررسی میشود؛ Load Balancer عمومی جایگزین بهینهسازی مدل یا ظرفیت Power BI نیست.
دامنه پروژه از میان این حوزهها انتخاب میشود؛ لازم نیست همه اجزا یا ابزارها در هر سامانه به کار گرفته شوند.
کندی همیشه از سرور نیست. مسیر درخواست را از رابط کاربر تا برنامه، پایگاه داده و سرویسهای وابسته دنبال میکنیم تا زمان و منابع واقعاً کجا مصرف میشوند.
اگر بازشدن گزارش یا تغییر فیلتر کند است، مدل، محاسبات و مسیر دریافت داده را با هم بررسی میکنیم؛ نه فقط ظاهر داشبورد را.
کوئریهای طولانی، قفلها و خواندنهای غیرضروری میتوانند چندین بخش سامانه را همزمان کند کنند. اصلاحات را با توجه به بار خواندن و نوشتن انتخاب میکنیم.
وقتی یک نمونه برنامه پاسخگوی بار موردنیاز نیست، گزینههای افزایش منابع یا توزیع بار بین چند نمونه را از نظر هزینه، پیچیدگی و پایداری مقایسه میکنیم.
درخواست کاربر نباید بیدلیل منتظر محاسبات تکراری یا کارهای طولانی بماند. مسیر استفاده از کش و صف را با توجه به تازگی داده و حساسیت عملیات طراحی میکنیم.
تغییرات فقط وقتی معنا دارند که نتیجهشان قابل سنجش باشد. رفتار سامانه را در بار تعریفشده اندازه میگیریم و نشانههای نزدیکشدن به محدودیت ظرفیت را مشخص میکنیم.
تغییر معماری باید دلیل داشته باشد. افزودن کش، Load Balancer، سرویس جدید یا سرور بیشتر، بعد از اندازهگیری و ارزیابی هزینه و پیچیدگی نگهداری پیشنهاد میشود. هدف، رفع گلوگاه واقعی و رشد قابل اتکای سامانه است.
یک سناریوی کند یا ناپایدار انتخاب میکنیم. مسیر اجرا، الگوی مصرف و محدودیتها اندازهگیری میشوند تا مسئله و نقطه شروع قابل استناد باشد.
گزارش ارزیابی و گلوگاههاگزینهها بر اساس اثر، ریسک و هزینه مقایسه میشوند. دامنه اجرا، معیار پذیرش و روش سنجش قبل از تغییر مشخص خواهد شد.
معماری هدف و نقشه اجرااصلاحات ابتدا در محیط توافقشده آزموده میشوند. انتشار با هماهنگی تیم شما، بررسی اثر و برنامه بازگشت انجام میشود.
اصلاحات و نتایج آزمونمستندات و راهنمای بهرهبرداری تحویل میشود. تیم شما از تصمیمها و تنظیمات آگاه خواهد بود و دامنه پشتیبانی بعدی توافق میشود.
مستندات و انتقال دانشبا توجه به مسئله و آمادگی تیم شما، دامنه همکاری مشخص میشود.
بررسی وضعیت موجود، اندازهگیری سناریوی منتخب و ارائه پیشنهادهای اولویتبندیشده؛ مناسب تیمی که پیش از تغییر، به تصمیم فنی مستند نیاز دارد.
تمرکز روی یک گزارش، مسیر API، کوئری یا فرآیند کند؛ با دامنه اجرایی مشخص و سنجش نتیجه بر اساس معیارهای توافقشده.
بررسی ظرفیت فعلی، معماری هدف و وابستگیها؛ همراه با برنامه انتقال مرحلهای، الزامات پایش و ارزیابی هزینه نگهداری.
محدوده تحویل پیش از اجرا توافق میشود. بسته مستندات متناسب با دامنه پروژه میتواند شامل موارد زیر باشد تا تصمیمها، تغییرات و روش نگهداری برای تیم شما روشن بماند.
وضعیت فعلی، شواهد اندازهگیری و گلوگاههای اولویتدار.
راهکار منتخب، گزینههای بررسیشده و دلیل انتخاب هر تغییر.
ترتیب اجرا، پیشنیازها و اقدام لازم در صورت بروز اختلال.
شرایط آزمون، محدودیتها و نتایج قابل مقایسه قبل و بعد.
انتقال دانش به تیم داخلیمرور تنظیمات، روش پایش و نکات بهرهبرداری در محدوده توافقشده پروژه.
میانه و صدک ۹۵ زمان پاسخ، برای دیدن تجربه معمول و درخواستهای کندتر.
تعداد درخواست یا کاری که در واحد زمان و با نرخ خطای قابل قبول انجام میشود.
تعداد خطاها، Timeoutها و رفتار وابستگیها هنگام افزایش بار.
بررسی پردازنده، حافظه، ورودی/خروجی و نشانههای اشباع.
مدت Refresh یا اجرای فرآیند نسبت به پنجره زمانی موردنیاز کسبوکار.
ابتدا خط مبنا ثبت میشود، سپس هدف عددی توافق خواهد شد. بهبود هر پروژه به معماری، داده و محدودیتهای همان سامانه بستگی دارد.
برای انتخاب مسیر درست، ابتدا باید نیاز و محدودیتهای سامانه شما مشخص شود.
درباره سامانهتان صحبت کنیمتمرکز این خدمت روی سامانهای است که وجود دارد و با کندی، رشد بار یا دشواری نگهداری روبهرو شده است. خروجی میتواند ارزیابی معماری، برنامه اصلاح یا اجرای بهینهسازی باشد. ساخت قابلیتهای جدید یا توسعه سامانه از ابتدا، دامنه جداگانه دارد.
ابتدا نوع استقرار، کاربران همزمان، الگوی استفاده و لایه کند را بررسی میکنیم. در Power BI، مدل داده، DAX، Visualها، منبع، Gateway و ظرفیت ارزیابی میشوند. در داشبورد سفارشی، API، کوئریها، کش و زیرساخت برنامه هم در بررسی قرار میگیرند.
خیر. ممکن است مشکل با اصلاح کوئری، مدل داده، زمانبندی پردازش یا تنظیم منابع برطرف شود. چندنمونهسازی زمانی مطرح میشود که نتیجه ارزیابی آن را توجیه کند و برنامه برای مدیریت Session و وضعیت مشترک آماده باشد.
در بسیاری از پروژهها امکان اصلاح مرحلهای وجود دارد؛ اما پیش از ارزیابی، نمیتوان دامنه آن را قطعی دانست. اولویت با تغییرات قابل سنجش و کمریسک است. اگر بازطراحی بخشی از سامانه لازم باشد، دلیل، هزینه و مسیر مهاجرت آن مشخص میشود.
دامنه و روش دسترسی پیش از شروع توافق میشود. تا جای ممکن از محیط آزمایشی و داده ناشناسسازیشده استفاده میکنیم. هر دسترسی باید حداقلی و مشخص باشد و تغییرات محیط عملیاتی با هماهنگی تیم شما انجام شود.
پیش از اندازهگیری، درصد یا ظرفیت مشخصی وعده نمیدهیم. ابتدا خط مبنا، سناریوی تست و معیار پذیرش توافق میشود. نتیجه اصلاحات با همان بار و شرایط قابل مقایسه ارزیابی و مستند خواهد شد.
شرح مشکل، فناوریهای اصلی، شیوه استقرار، تعداد تقریبی کاربران همزمان، زمانهای اوج مصرف و نمونه لاگ یا اندازهگیری موجود کمککننده است. در فرم اولیه، رمز عبور، کلید دسترسی یا داده محرمانه ارسال نکنید.
نوع سامانه، نشانه مشکل و زمانهای اوج مصرف را توضیح دهید. در گفتوگوی اولیه، دامنه ارزیابی و اطلاعات لازم برای بررسی را مشخص میکنیم.