Planowanie pojemności raportów podzielonych na strony

  • Artykuł

DOTYCZY: Raporty podzielone na strony w usłudze Power BI usługa Power BI Power BI Desktop

Dowiedz się, jak zaplanować pojemność Premium, aby uzyskać najlepszą wydajność z raportów podzielonych na strony przy minimalnym koszcie. Jeśli przeprowadzasz migrację do usługi Power BI z innego narzędzia do analizy biznesowej, rozważ przeczytanie artykułów wymienionych poniżej przed podjęciem decyzji, której pojemności użyć.

Planowanie zdolności produkcyjnych

Obliczanie wymaganej pojemności zależy od kilku czynników, takich jak liczba wizualizacji w raportach, złożoność zapytań względem raportu i jakość źródła danych lub modelu danych. Należy również rozważyć bieżące wykorzystanie pojemności w godzinach szczytu przed dodaniem do niego raportów podzielonych na strony.

Przed rozpoczęciem planowania potrzebnej pojemności przejrzyj tabelę Pojemności i jednostki SKU, aby zobaczyć, które zasoby są oferowane przez każdą pojemność.

Podczas planowania pojemności należy wziąć pod uwagę następujące kwestie:

  • Złożoność projektu raportu. Zagnieżdżone elementy tablix, wiele podraportów i wiele grup wierszy i kolumn dodają do złożoności projektu i wymagają zasobów pojemności.

  • Ilość danych pobieranych przez raport. Tym więcej danych potrzebuje raport, tym więcej zasobów wymaga od pojemności.

  • Sposób pobierania danych przez raport. W przypadku używania łączników, sterowników lub bram pobieranie danych może trwać dłużej, wymagać większej ilości zasobów i w rezultacie stać się droższe.

  • Podczas eksportowania dużych raportów do formatów, takich jak program Excel i plik PDF, wymaga więcej zasobów niż odczytywanie każdej strony, używanie przełączania i wyszukiwanie w raportach.

Ilu użytkowników może obsłużyć jednostka SKU?

Aby przetestować raporty podzielone na strony w różnych pojemnościach, wykonaliśmy trzy różne typy obciążeń pod kątem różnych rozmiarów jednostek SKU. Każde obciążenie składało się z jednoczesnego renderowania pojedynczego raportu o różnych rozmiarach.

  • Mała — tabela agregacji danych utworzona ponad 100 wierszy ze źródła danych Usługi Azure SQL.

  • Średni — tabela agregacji danych zbudowana ponad 100 000 wierszy ze źródła danych usługi Azure SQL.

  • Duże — tabela agregacji danych utworzona ponad 250 000 wierszy ze źródła danych Usługi Azure SQL.

Nasza analiza usługi Power BI Premium pokazuje, że liczba równoczesnych użytkowników w danym momencie, w tym dziennych godzin szczytu, nie przekracza pięciu procent całkowitej bazy użytkowników.

Na podstawie współczynnika współbieżności pięciu procent w poniższej tabeli opisano przybliżoną maksymalną liczbę użytkowników, których jednostka SKU może obsłużyć, zanim zostanie przeciążona. Gdy pojemność jest przeciążona, ograniczanie przepustowości będzie występować w pojemności. Aby uzyskać więcej informacji, zobacz Co się dzieje z ruchem podczas przeciążenia, jeśli nie skaluję automatycznie?

Obciążenie Jednostki SKU F64 lub P1 Jednostki SKU F128 lub P2
Small 2500 użytkowników 5000 użytkowników
Medium 1900 użytkowników 3800 użytkowników
Large 1300 użytkowników 2600 użytkowników

Należy wziąć pod uwagę, że liczby w tabeli odnoszą się do wyznaczonych pojemności, które nie uruchamiają innych operacji. Pojemność może już używać zasobów procesora CPU na potrzeby operacji, takich jak:

  • Pobieranie i przetwarzanie danych

  • Inne operacje obciążenia i w tle

  • Złożone grupowanie i przekształcanie danych

  • Filtrowanie danych

Żądania współbieżne

Każde obciążenie pojemności, w tym obciążenie raportów podzielonych na strony, ma w danym momencie maksymalnie 500 współbieżnych renderowanych raportów. Jeśli pojemność renderuje 100 raportów i ma 200 żądań eksportowania raportów podzielonych na strony, pozostało 200 równoczesnych żądań renderowania raportu.

Aby uniknąć przeciążenia, zaplanuj obciążenie współbieżnych żądań z wyprzedzeniem. Jeśli przekroczysz limit żądań współbieżnych, wystąpi błąd Zbyt wiele żądań (429).

Korzystanie z aplikacji metryk

Korzystając z aplikacji Metryki pojemności usługi Microsoft Fabric, możesz oszacować wpływ raportu podzielonego na strony w ramach pojemności. Aplikacja mierzy użycie procesora CPU w czasie, co pozwala zrozumieć, jak działa pojemność.

Aby przetestować raport podzielony na strony, zalecamy użycie dedykowanej pojemności czystego. Czysta pojemność pomaga odizolować wyniki od wpływu innych użytkowników i obciążeń.

W zależności od scenariusza testu docelowego, na przykład średniej lub maksymalnej weryfikacji użycia, wybierz lub utwórz raport reprezentatywny dla przewidywanego użycia zasobów i przekaż go do obszaru roboczego Premium/Fabric w pojemności utworzonej na potrzeby testu.

Uruchom raport kilka razy i użyj aplikacji metryk, aby uzyskać średnie sekundy procesora CPU wydane na uruchomienie raportu. Podczas obliczania czasu, jaki zajęło uruchomienie raportu, należy wziąć pod uwagę następujące kwestie:

  • Aplikacja wyświetla wartości zagregowane. Może być konieczne podzielenie wyników przez liczbę uruchomień raportu.

  • Istnieje wiele elementów i operacji usługi Power BI, które mogą być zaangażowane w renderowanie raportów. Może być konieczne zsumowania użycia procesora CPU.

  • Istnieje wiele elementów i operacji usługi Power BI, które mogą być zaangażowane w renderowanie raportów, ponieważ renderowanie może zająć dużo czasu. Długotrwała operacja na stronie Punkt czasu może być wyświetlana jako lista operacji, z których żaden nie przekracza 30 sekund. Może być konieczne zsumowania użycia procesora CPU operacji renderowania. Sortowanie według czasu rozpoczęcia może pomóc wyświetlić pełną historię renderowania.

Obliczanie maksymalnego renderowania raportu

Użyj tej formuły, aby obliczyć maksymalny współbieżny raport renderujący, że pojemność może obsłużyć przed przeciążeniem.

$ \text {max concurrent report renders} = {\text {liczba rdzeni jednostki SKU pojemności} \times {30} \over \text {czas przetwarzania procesora CPU raportu (w sekundach)}} $

Obliczanie maksymalnej liczby użytkowników

Korzystając z szacowanej pięciu procent współbieżności dla korelacji między liczbą całkowitej liczby użytkowników a maksymalnymi współbieżnościami współbieżności, można uzyskać łączną liczbę użytkowników, które może obsłużyć jednostka SKU.

$ \text {max SKU users} = {\text {max concurrent report renders} \over 0,05} $

Obliczanie zasobów pojemności dla wielu raportów

Możesz użyć rozszerzonej formuły, aby oszacować pojemność potrzebną dla różnych użycia raportów.

Przekaż kilka raportów podzielonych na strony z różną liczbą renderowania dziennego i użyj aplikacji metryk, aby uzyskać średni czas przetwarzania procesora CPU dla każdego z nich. Suma wszystkich renderowanych raportów dziennie powinna być równa 100%. Jeśli masz wszystkie informacje, użyj tej formuły.

$ \text {max concurrent report renders} = {\text {number of capacity SKU cores} \times \over {\text {A renders} \times {30} \text {A processing time}} + \text {B renders} \times \text {B processing time} + \text {...} + \text{N renders} \times \text{N processing time}}$

Przykłady

Ta sekcja zawiera dwa przykłady, jeden dla regularnego obliczania, a drugi na potrzeby obliczeń zaawansowanych.

Regularne obliczanie

Załóżmy, że korzystasz z raportu podzielonego na strony w jednostce SKU F64 lub P1 , która ma osiem rdzeni. Łączne użycie procesora CPU przez 10 przebiegów wynosi 40 sekund, więc średni czas procesora CPU na raporty wynosi cztery sekundy.

$ 60 = {8 \times {30} \over 4} $

W przypadku korzystania z drugiej formuły uzyskasz maksymalnie 1200 użytkowników.

$ 1,200 = {60 \over 0,05} $

W przypadku jednostek SKU F128 lub P2 można pomnożyć te liczby przez dwa, ponieważ pojemność ma dwa razy więcej rdzeni procesora CPU.

Zaawansowane obliczenia

Załóżmy, że masz trzy raporty podzielone na strony z dziennym procentem renderowania wymienionym w poniższej tabeli.

Report Liczba renderowanych raportów dziennie Czas przetwarzania procesora CPU (w sekundach)
A 60% 100
B 30% 10
C 10% 20

Formuły dla jednostki SKU F64 lub P1 będą następujące:

Wartość Wzór
Maksymalna liczba renderowanych współbieżnych raportów $ ~32.4 = {8 \times {30} \over 0,6 \times + 0,3 \times{4}{10} + 0,1 \times{20}} $
Łączna liczba użytkowników jednostek SKU $ ~650 = {32,4 \over 0,05} $

Powiązana zawartość