Вимірюйте в LuckyTemplates: поради та методи оптимізації

У цьому підручнику ви дізнаєтесь, як оптимізувати показник у LuckyTemplates. Оптимізація показників у вашому звіті покращує продуктивність ваших кодів у створенні цінної інформації та даних. Ви також дізнаєтеся про різні методи оцінювання та про те, як їх застосовувати для оптимізації звіту. Ви можете переглянути повне відео цього підручника внизу цього блогу.

Зміст

• 1. Проаналізуйте ефективність коду
  • Змінні в мірі
  • Холодний кеш для DAX Studio
• 2. Проаналізуйте міру в LuckyTemplates
  • Вимірювання % заохочення RB у LuckyTemplates
    • Дані з системи зберігання
  • Логіка IF і Switch
• 3. Використовуйте методи оцінки коду
  • 1-й метод: Сувора оцінка
  • 2-й метод: ретельна оцінка
    • Недоліки жадібної оцінки
  • 3-й метод: Оцінка IF.EAGER
  • Резюме методів оцінювання
• 4. Оптимізуйте міру в LuckyTemplates
  • Розширена оптимізація для вимірювання в LuckyTemplates
    • Видалити дані зворотного виклику
• 5. Оптимізуйте інші заходи в LuckyTemplates
• Висновок

1. Проаналізуйте ефективність коду

У цьому прикладі вам потрібно оптимізувати цей звіт:

Це модель даних, яку ви збираєтеся використовувати:

Таблиця «Робочі завдання» містить усю інформацію щодо будь-якої роботи, виконаної за певний період часу.

Ця таблиця є основою для всіх заходів, які ви збираєтеся оптимізувати:

По-перше, вам потрібно протестувати продуктивність звіту.

Перейдіть на вкладку «Перегляд» і виберіть. Потім натисніть «Почати запис» і «Оновити візуальні елементи» . Зачекайте, поки аналізатор відтворить візуальне зображення.

Коли це буде зроблено, розкрийте список Incentive Breakdown і натисніть Копіювати запит .

Далі виберіть Зовнішні інструменти , щоб перейти до DAX Studio та переглянути код, створений LuckyTemplates.

Потім вставте скопійований запит у робочу область.

Змінні в мірі

Перша змінна — DateClosed , яка є роздільником на інформаційній панелі. Він використовує стовпець із таблиці фактів, щоб отримати значення певних періодів у зрізі.

Наступна змінна — JobLost , яка перевіряє значення False або Blank у даних Job Lost.

Останньою змінною є MatrixVisual . Це суть коду. Він показує підсумковий стовпець, створений LuckyTemplates для заповнення візуальних елементів матриці. Він групує тип втрати роботи в цій матриці та вводить фільтри, що надходять із розділювачів. Потім він додає розширені стовпці.

Після того, як підсумковий стовпець завершить виконання, ви побачите результати на панелі під кодом.

LuckyTemplates використовує результат для заповнення візуальних елементів матриці.

Холодний кеш для DAX Studio

Далі вам потрібно перевірити час, витрачений на виконання всього коду. Для цього увімкніть параметри часу сервера, а потім виберіть Очистити кеш і запустіть .

Коли ви намагаєтеся оптимізувати показник у LuckyTemplates за допомогою, краще працювати за сценарієм холодного кешу, щоб час, який ви отримаєте, був правильним. Після цього натисніть F5 і дочекайтеся завершення операції на вкладці «Час сервера» .

Після завершення ви побачите, що загальний час виконання становить 3,6 секунди. Він проводив більшу частину часу в механізмі формул і витратив 57 мілісекунд в механізмі зберігання

Ви також можете побачити, що він знайшов 383 запити системи зберігання. З усіх цих запитів 327 зберігаються в пам’яті, щоб їх можна було використати повторно.

2. Проаналізуйте міру в LuckyTemplates

Далі вам потрібно оптимізувати ці 3 ідентичні заходи.

Ви повинні витягти ці заходи в інший файл і підключити його до моделі даних, яку ви використовуєте.

Після цього запустіть часові параметри сервера, щоб побачити час, витрачений 3 показниками на заповнення візуальних елементів.

Результати циклу показують, що вимірювання займають 1,85 секунди для отримання результату.

Результат показує таблицю, що складається з 10 рядків і 3 розширених стовпців, які належать до зведених стовпців.

Стовпець "Тип втрати" містить 10 унікальних значень, які обчислює код, щоб отримати відсоток заохочення.

Час, який потребує код, експоненціально великий. Саме тут і коли потрібно їх оптимізувати.

Вимірювання % заохочення RB у LuckyTemplates

Це показник RB Incentive% у LuckyTemplates. Це одна з 3 основних мір, які використовуються в цьому прикладі.

Ви бачите, що він намагається обчислити відсоток заохочення.

Він має змінну JobType, яка отримує значення Lost Type у поточному контексті фільтра. Він також перевіряє, чи є лише одне значення, видиме в контексті поточного фільтра. Вам потрібно використовувати a  функціонує так, що щоразу, коли виконується умова, вона дає відповідний результат.

Цей код вимірювання генерує багато мастила для двигуна зберігання, що збільшує час у загальній тривалості коду.

Тепер поверніться до DAX Studio, щоб перевірити кількість запитів механізму зберігання, які створює вимірювання.

Ви бачите, що на виконання знадобилося 600 мілісекунд і 43 запити системи зберігання, щоб просто отримати дані для 10 рядків.

Дані з системи зберігання

Тепер перевірте дані, які запитуються від механізму зберігання. У першому запиті є тип втрати роботи та DCOUNT  для типу втрати роботи.

Наступний запит містить дату закриття вакансій із роздільника у звіті.

У третьому коді ви побачите інший тип втрати роботи з ідентифікатором даних зворотного виклику.

В іншому рядку ви побачите найважливіші рядки коду.

Перше, що ви бачите, це отримана оплата за роботу, виставлені рахунки та фактичні витрати.

Далі йде функція WHERE  , яка визначає умову та її відповідний результат. Результат буде відрізнятися залежно від вибору зрізу та оператора перемикання в показнику RB Incentive%.

Ви також помітите, що код у рядках 12 і 14 однаковий.

Якщо прокрутити вправо, то можна побачити рядки з однаковими запитами. Запити в рядках спрямовуються оператором switch у показнику RB Incentive%.

Якщо ви повернетесь до показника RB Incentive% у LuckyTemplates, ви зможете побачити, скільки разів запит повторюється та як це відображається в запитах системи зберігання.

Логіка IF і Switch

Тепер, щоб зрозуміти, чому запити виконуються кілька разів, вам потрібно зрозуміти логіку і SWITCH функції.

Вам потрібно виконати їх окремо за планом запиту. Але перш ніж це зробити, переконайтеся, що підключилися до бази даних і ввімкніть план запитів.

Виконайте оператор SWITCH  у плані запиту. Потім виділіть  заяву та натисніть enter.

Це створить план логічного запиту з різними операціями.

Далі виконайте інструкцію IF , виділивши її та натиснувши клавішу enter.

Ви бачите, що він генерує той самий план логічного запиту.

Це тому, що щоразу, коли ви використовуєте , механізм внутрішньо перетворює цю функцію в оператор IF . Але оператор SWITCH рекомендується, оскільки він покращує читабельність вашого коду.

Після цього вам потрібно зрозуміти, як код виконується всередині функції IF або SWITCH .

Це приклад коду, який містить оператор SWITCH .

Він містить показники для валового прибутку, загальної оцінки та загальної суми рахунків-фактур, які є СУМОЮ різних стовпців. Він також має функцію над типом втрати роботи та операторами SWITCH і TRUE .

Виконуючи цей код, ви побачите логіку функцій.

Перший запит отримує окремий тип втрати роботи з таблиці «Вакансії».

Окрім типу втрати робочих місць, він також отримує суму оцінки робочих місць.

Всередині умови WHERE також можна побачити значення, які існують у стовпці Тип втрати роботи.

3. Використовуйте методи оцінки коду

У DAX є 3 методи оцінки кодів:

• Сувора оцінка
• Бажаюча оцінка
• Оцінка IF.Eager

Ці методи допоможуть вам оптимізувати код або показник у LuckyTemplates.

1-й метод: Сувора оцінка

У наведеному нижче прикладі використовується метод суворої оцінки.

Логіка полягає в тому, що якщо контекст типу втрати робочих місць дорівнює А, це забезпечить валовий прибуток. В іншому випадку він дає загальну оцінку. Код робить це для кожного рядка типу втрати роботи.

Це ще один приклад вимірювання в LuckyTemplates, який використовує суворе оцінювання.

Коли ви виконаєте цей код, він згенерує 5 запитів системи зберігання.

При строгому оцінюванні код надає загальну оцінку, якщо валовий прибуток, помножений на 1,4, перевищує середню оцінку. В іншому випадку це дасть валовий прибуток.

Використання суворої оцінки створює більше запитів до механізму зберігання, оскільки оператор IF  перевіряє конкуренцію валового прибутку кілька разів і, зрештою, перешкоджає продуктивності всієї операції.

2-й метод: ретельна оцінка

Це той самий код, що й у попередньому прикладі.

Але замість того, щоб обчислювати заходи в  операторі IF , він обчислював усе в попередньому RETURN .

Це означає, що перед перевіркою звітів він отримує всі значення валового прибутку та загальної оцінки для всіх типів втрати робочих місць.

Коли ви виконуєте цей код, кількість механізмів зберігання даних зменшується до 3.

Це покращує продуктивність всієї операції.

У першому запиті операції він отримує тип втрати робочих місць і суму оцінки робочих місць і валового прибутку.

Наступний запит отримує суму оцінки вакансій зі стабільної роботи. Це використовується для розрахунку середньої оцінки.

Останній запит дає окремий тип втрати роботи для значень, записаних у ADDCOLUMNS .

Використання Eager Evaluation містить усе в одному кеші даних. Дані також оцінюються та повторюються на механізмі формул. Оператор IF  поверне або загальну оцінку, або валовий прибуток залежно від оцінки True або False.

Завзята оцінка не завжди є найкращим методом оптимізації ваших кодів. Сувора оцінка призведе до кращої продуктивності, якщо у вас є складні коди. Все залежить від функцій, які ви використовуєте в коді DAX.

Недоліком Eager Evaluation є те, що якщо ви створюєте значення перед інструкцією IF  або  SWITCH  і використовуєте ті змінні всередині інструкції, які ніколи не повинні виконуватися, система все одно обчислить ці змінні.

Недоліки жадібної оцінки

Ось приклад недоліку:

В ідеалі, якщо тип втрати робочих місць дорівнює А, він має отримати валовий прибуток. В іншому випадку він отримує загальну оцінку.

Оскільки в стовпці "Тип втрати роботи" немає значення, яке дорівнює A, він завжди має отримувати загальну оцінку. Однак він все ще надає валовий прибуток у кеші даних.

Якщо ви подивіться на перший запит, він отримає тип втрати робочих місць і суму валового прибутку й оцінки робочих місць.

У наступному запиті він отримує окремий тип втрати робочих місць із таблиці Jobs.

3-й метод: Оцінка IF.EAGER

Наступним методом є  оцінка функції IF.EAGER  , яка повторює поведінку оцінки Eager.

Це дозволяє вам написати код, який представляє Strict Evaluation, і виконати його за допомогою Eager Evaluation.

Якщо ви подивитеся на цей зразок коду, то він точно такий же, як і код суворої перевірки. Єдина відмінність полягає в тому, що тут використовується функція IF.EAGER  замість IF .

Перш ніж виконувати код, переконайтеся, що підключилися до моделі LuckyTemplates і ввімкніть синхронізацію сервера. Після завершення натисніть F5.

Ви бачите, що він створив 3 запити механізму зберігання.

Перший запит отримує тип втрати робочих місць і суму оцінки робочих місць і валового прибутку.

Другий запит отримує суму оцінки робочих місць.

Останній запит отримує окремий тип втрати роботи з таблиці «Вакансії».

Ви помітите, що він виконував таку саму поведінку, як Eager Evaluation.

Резюме методів оцінювання

Намагаючись підвищити продуктивність ваших обчислень, ви повинні пам’ятати наступне:

• Суворе оцінювання використовується для складних кодів. Це також стосується випадків, коли ви не хочете оцінювати всі значення, надані таблицею.
• Eager Evaluation краще використовувати, якщо ваші коди прості.
• Використовуйте IF.EAGER, якщо ви хочете писати коди за допомогою Strict Evaluation і виконувати його за допомогою Eager Evaluation.

Але візьміть до уваги, що ви повинні перевірити ці три методи, щоб дізнатися, що справді найкраще використовувати у вашому звіті.

4. Оптимізуйте міру в LuckyTemplates

Основним уроком у цьому підручнику є оптимізація ваших кодів.

Поверніться назад і подивіться на міру заохочення RB , яка виконується за допомогою суворої оцінки. Далі спробуйте оцінити його за допомогою Eager Evaluation.

Почніть із створення змінних і введення функції  RETURN .

Змініть посилання на вимірювання за допомогою змінних.

Після цього підтвердьте вимірювання та перейдіть до DAX Studio, щоб перевірити, чи це покращило продуктивність.

Він показує, що загальний час становить 642 мілісекунди, а загальну кількість запитів до механізму зберігання було зменшено до 39.

Тепер створіть змінні для всіх даних і змініть усі посилання на вимірювання на відповідні їм змінні.

Далі підтвердіть вимірювання та виконайте код у студії DAX.

Загальний час виконання та загальну кількість запитів механізму зберігання було зменшено з 600 мілісекунд до 170 мілісекунд і 43 запитів до 15 запитів відповідно.

Ви також можете побачити, що дублікатів немає. Наявність змінних у вашому коді покращує їх читабельність і продуктивність.

Розширена оптимізація для вимірювання в LuckyTemplates

Далі вам потрібно додатково оптимізувати свої коди DAX.

Замість використання, використання функція.

HASONEVALUE  підраховує кількість значень, доступних у контексті фільтра, який є дуже інтенсивною операцією. Тим часом ISINSCOPE перевіряє, чи використовується стовпець, який надається, для групування чи ні.

Після зміни функцій підтвердіть вимірювання та виконайте його в DAX Studio.

Ви бачите, що кількість запитів до системи зберігання тепер становить 12. Загальний час виконання також став 105 мілісекунд.

У другому запиті ви помітите ідентифікатор даних зворотного виклику.

Іноді це трапляється, коли ви використовуєте SELECTEDVALUE з текстовим полем. Коли ви бачите дані зворотного виклику, механізм зберігання викликає механізм формул, щоб допомогти вирішити складність коду. Це сповільнює продуктивність вашого вимірювання.

Видалити дані зворотного виклику

Вам потрібно видалити дані зворотного виклику, щоб отримати кращу продуктивність у звіті. Для цього вам потрібно створити таблицю конфігурації в моделі даних.

Перейдіть до опції «Ввести дані» та вставте дані. Назвіть таблицю LossTypeConfigTable .

Потім натисніть «Редагувати», щоб змінити тип даних стовпця, який ви збираєтеся імпортувати.

Тип даних ідентифікатора типу втрати має бути значенням викладача, щоб його можна було використовувати у функції SELECTEDVALUE .

Після завантаження в модель створіть зв’язок між таблицею Jobs і таблицею LossTypeConfigTable на основі типу втрати.

Після створення зв’язку перейдіть до таблиці «Вакансії» та додайте новий стовпець. Назвіть це ідентифікатор втрати, а потім введіть формулу.

Використовувати для таблиці конфігурації, а потім витягніть ідентифікатор типу втрати.

Next, go back to the RB Incentive% measure and reference the numeric field instead of the text field. Inside SELECTEDVALUE, replace Loss Type with Loss ID.

Next, modify all the measures inside the code. Use an integer value instead of text values in checking for the Job Type.

Once you’ve changed the code, confirm the measure and execute it in the DAX Studio.

The Callback data ID is eliminated in the query and the code’s execution time is reduced to 93 milliseconds.

The RB Incentive% measure is now fully optimized.

5. Optimize Other Measures In LuckyTemplates

You also need to optimize the WR Incentive% and QB Incentive% measures.

Copy and paste the exact code used in the RB Incentive% measure. Then, run the 3 measures together.

The total execution time is optimized and reduced from 1855 milliseconds to 213 milliseconds. There are also only 12 storage engine queries.

The first two queries create the filter context and the rest represent the exact number of values inside the Jobs Loss Type column.

Since all measures have been optimized, run the original code and see how the performance has changed. The data shows that it’s now being computed in 1.9 seconds.

The performance of the whole code is now optimized, making your report faster and better.

Conclusion

In LuckyTemplates reports, measures should be optimized to ensure that your DAX codes run smoothly. This also improves the overall performance of your report.

You’ve learned the different methods to optimize your measure in LuckyTemplates and you’ve learned how to assess which one to use depending on the context of your report.