و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
اگر یک گزارش Power BI دارید که هر بار باز میشود چند ثانیه مکث میکند، یا ویژوالها یکییکی و آرام بالا میآیند، طبیعی است که اولین سوال همین باشد:
«مشکل دقیقاً از کجاست؟ مدل؟ DAX؟ ویژوال؟ یا شبکه؟»
در چنین لحظهای تنها یک ابزار به شما راستگوترین تصویر را میدهد: Performance Analyzer.
این مقاله یک مرور سطحی نیست. در اینجا مرحلهبهمرحله میبینید:
- این ابزار چطور رفتار گزارش را باز میکند
- چه عددهایی واقعاً معنیدار هستند
- چه نوع کندیهایی معمولاً دیده میشود
- و مهمتر اینکه چطور میتوان همان لحظه مشکل را رفع کرد
این محتوا مخصوص مدیران، طراحان BI و تیمهای Performance است. هدف این نیست که صرفاً ابزار را توصیف کنیم، بلکه میخواهیم کمک کنیم آن را مثل یک متخصص استفاده کنید.
Performance Analyzer دقیقاً به چه درد میخورد؟
بسیاری از کاربران Power BI تصور میکنند این ابزار فقط زمان بارگذاری ویژوالها را نمایش میدهد. اما در عمل، Performance Analyzer سه کار کلیدی انجام میدهد که هیچ ابزار داخلی دیگری چنین تصویری ارائه نمیدهد:
۱. شکستن رفتار ویژوال به سه بخش قابل اندازهگیری
هر ویژوال به سه بخش اصلی تقسیم میشود:
- DAX Query
زمان پردازش کوئری و محاسبات. - Visual Display
مدت زمانی که Power BI برای رسم ویژوال نیاز دارد. - Other
شامل فعالیتهایی مثل Interactions یا آمادهسازی داده.
این سه بخش، ستون فقرات تحلیل Performance هستند.
۲. تشخیص اینکه ریشه کندی در مدل است یا در ویژوال
گاهی دادهها عالی طراحی شدهاند اما ویژوال سنگین است.
گاهی هم ویژوال ساده است ولی مدل مشکل دارد.
این ابزار تفاوت این دو را کاملاً روشن میکند.
۳. ثبت دقیق زمان پردازش در لحظه تعامل
هر بار که فیلتر تغییر میکند، یک سشن جدید از Performance ثبت میشود.
این ویژگی در گزارشهایی که از Slicers زیاد استفاده میکنند، طلا است.
سه دسته کندی که همیشه در Power BI دیده میشود
با تجربه دهها پروژه عملی، تقریبا تمام مشکلات کندی را میتوان در سه گروه قرار داد:
۱. کندی ناشی از مدل
این مشکل معمولاً زمانی رخ میدهد که:
- جدولها رابطه نامناسب دارند
- Keyها از نوع مناسب نیستند
- کاربر دادههای بسیار حجیم را وارد مدل کرده
- ستونهای بدون استفاده حذف نشده
- یا از DirectQuery به صورت اشتباه استفاده شده است
نشانهها در Performance Analyzer:
- زمان DAX Query نسبتاً زیاد
- مدل به طور غیرمعمول حافظه مصرف میکند
- Visual Display کم است اما Query Time بالاست
۲. کندی ناشی از ویژوالها
بعضی ویژوالها واقعاً سنگین هستند.
به خصوص:
- Mapها
- ماتریسهای چندسطحی
- کارتهای گروهبندیشده
- Custom Visual هایی که رندرشان پیچیده است
نشانهها:
- Visual Display از DAX Query بیشتر است
- هنگام اسکرول یا Resize کردن ویژوال، مکث دارید
۳. کندی ناشی از DAX
وقتی نویسنده گزارش، Measures را زنجیرهای، پیچیده یا تودرتو طراحی کرده باشد، DAX کار را سنگین میکند.
مخصوصاً:
- استفاده بیجا از CALCULATE
- فیلترسازیهای متعدد
- Measures مرتبط با Row Context
- استفاده از توابع تکراری مانند SUMX با جدولهای بزرگ
نشانهها:
- زمان DAX Query بالاتر از ۱۵۰ میلیثانیه
- رشد زمان پردازش هنگام اضافه کردن Slicer
چگونه از Performance Analyzer به صورت حرفهای استفاده کنیم؟
اکثر کاربران فقط Record را شروع میکنند. اما متخصصان BI چند مرحله دقیق را دنبال میکنند. این مراحل کمک میکند تحلیل به نتایج قابلاتکا برسد.
اول: پاکسازی نتایج قبلی
در ابتدا همیشه Clear کنید.
با این کار مطمئن میشوید تمام زمانها مربوط به همان سناریوی مورد نظر است.
دوم: بارگذاری کامل صفحه
در این مرحله اندازهگیریها باید شامل تمام ویژوالها باشد.
صفحه را یک بار رفرش کنید تا دادههای پایه ثبت شوند.
سوم: تست سناریوهای تعاملی
این یکی از ارزشهای واقعی ابزار است.
مثل مثالهای زیر:
- تغییر یک Slicer کلیدی
- فیلتر کردن بازه زمانی
- تغییر حالت نمودار
- کلیک روی ماتریس چندسطحی
هر Interaction یک Insight جدید میدهد.
چهارم: بررسی Component Breakdown
در اینجا باید دقت کنید کدام بخش بیشترین سهم را دارد:
DAX Query بلند باشد: مشکل در مدل یا محاسبات است.
Visual Display بلند باشد: مشکل از ویژوال یا تعداد نقاط داده است.
Other زیاد باشد: لایه Interaction پیچیده است.
پنجم: Copy Query برای تحلیل حرفهای
هر DAX Query قابل کپی و انتقال به DAX Studio است.
اینجا محل تحلیل عمیقتر است:
- Query Plan
- Storage Engine vs Formula Engine
- تعداد Scanها
- Row Count
- Cardinality
این مرحله ستون فقرات تحلیلهای عمیق عملکردی است.
کندیهای رایج و راهکارهای فوری
در ادامه مجموعهای از فیکسهای فوری وجود دارد که در اغلب پروژههای واقعی کاربرد دارند. اینها نکاتی هستند که معمولاً همان روز اول مشکل را حل میکنند.
۱. ویژوالهایی که بیش از حد سنگین هستند
گاهی مشکل در Query نیست.
در Screen Trace مشخص میشود Visual Display خیلی زیاد است.
راهکارهای بلافاصله:
- حذف Mapهای غیرضروری
- سادهسازی ماتریسها
- محدود کردن تعداد ستونها در Table ویژوال
- استفاده از Line/Bar به جای Custom Visual
۲. مدل دادهای که نیاز به Diet دارد
مدلهایی که بدون بررسی وارد Import شدهاند، معمولا پر از ستونهای بدون مصرف هستند.
راهکارها:
- حذف ستونهای Unused
- تبدیل ستونهای Text به دستهبندی مناسب
- ساختن Factهای باریک و فشرده
- کم کردن تعداد جدولهای Lookup غیرضروری
۳. DirectQuery بدون طراحی
DirectQuery اگر درست طراحی نشود، مثل ترمز دستی است.
فیکسهای فوری:
- کاهش تعداد Queryهای پشتسرهم
- ایجاد Aggregation Table
- انتقال بخشی از محاسبات به SQL
۴. مشکلات ناشی از DAX
Measureهای سنگین بزرگترین عامل گزارشهای کند هستند.
راهکارهای سریع:
- Simplify کردن Measures تودرتو
- استفاده نکردن از SUMX روی جدولهای بزرگ
- ایجاد Measures پایه و استفاده از آنها برای جلوگیری از محاسبات تکراری
- استفاده صحیح از Variables برای کاهش پردازش
مثال واقعی: صفحهای که ۶ ثانیه برای لود زمان میگرفت
در یکی از پروژهها، صفحه داشبورد فروش به شکل واضح کند بود.
مشتری فکر میکرد مشکل از سرور SQL است. اما پس از اندازهگیری دقیق:
- Visual Display یک ماتریس بیشتر از ۳ ثانیه بود
- DAX Query کمتر از ۰.۴ ثانیه
مشکل از مدل یا DAX نبود؛ مشکل از ویژوال بود.
با جایگزین کردن ماتریس چندسطحی با یک Matrix سادهتر، سرعت بارگذاری به ۱.۲ ثانیه رسید.
این همان کاربرد واقعی Performance Analyzer است. بدون حدس، بدون آزمون خطای بیپایان.
راهکارهای ساختاری برای جلوگیری از کندی
بهبودهای فوری لازم است، اما در کنار آن یک سری راهکار پایه وجود دارد که سرعت گزارشها را در بلندمدت تضمین میکند.
۱. مدل را ستارهای نگه دارید
مهندسی مدل، مهمترین عامل Performance است.
۲. ویژوالها را فقط تا حد لازم نگه دارید
هر صفحه با بیش از ۱۲ ویژوال معمولاً قابل بهینهسازی است.
۳. از Aggregation هوشمند استفاده کنید
Aggregation Tables یکی از مؤثرترین ابزارهای Power BI هستند.
۴. از DAX Studio برای مانیتورینگ Query Plan استفاده کنید
Performance Analyzer کافی نیست؛ DAX Studio تصویر کاملتری میدهد.
سوالات متداول FAQ
۱. آیا Performance Analyzer جایگزین DAX Studio است؟
خیر، این ابزار برای تحلیل رفتار UI است، نه اجرای موتور.
برای تحلیل Query Plan باید از DAX Studio استفاده کنید.
۲. زمان مناسب برای Visual Display چقدر است؟
معمولاً کمتر از ۲۰۰ میلیثانیه قابل قبول است.
بیشتر از ۵۰۰ میلیثانیه یعنی ویژوال باید بازنگری شود.
۳. زمان مناسب برای DAX Query چقدر است؟
در مدلهای معمولی، DAX Query زیر ۱۰۰ میلیثانیه ایدهآل است.
بین ۱۰۰ تا ۳۰۰ قابل قبول.
بیشتر از ۳۰۰ یعنی نیاز به بهبود دارد.
۴. آیا DirectQuery همیشه کند است؟
خیر. اگر پایگاه داده سریع باشد و Aggregation درست طراحی شود، کاملاً قابل قبول است.
۵. آیا میتوان تعاملات بین ویژوالها را کاهش داد؟
بله. Disable Interaction برای ویژوالهای غیرضروری یکی از سریعترین راهکارهاست.
۶. چطور بفهمیم مشکل از مدل است یا DAX؟
اگر DAX Query بالا باشد، مشکل در مدل یا محاسبات است.
اگر Visual Display بالا باشد، مشکل از ویژوال است.
تماس و مشاوره
اگر سازمان شما با گزارشهای کند، ویژوالهای دیربارگذاری یا رفتار غیرقابل پیشبینی DAX مواجه است، یک تحلیل تخصصی Performance Analyzer میتواند همین امروز تغییر را شروع کند.
تیم متخصص لاندا در کمتر از چند ساعت میتواند:
نقاط گلوگاه مدل را شناسایی کند
DAXهای پرهزینه را تحلیل و اصلاح کند
معماری مدل را استاندارد کند
و یک برنامه بهبود عملکرد قابل اندازهگیری ارائه دهد
برای دریافت تحلیل تخصصی سرعت گزارشها، همین حالا با متخصصان لاندا تماس ✆ بگیرید.
نظری داده نشده