Share via

Typowe problemy z wydajnością aplikacji kanwy i sposoby ich rozwiązywania

  • Artykuł

Aplikacje kanwy można tworzyć z różnymi opcjami źródeł danych. Wybierz odpowiedni źródło danych i łącznik w zależności od potrzeb biznesowych i scenariuszy, dla których aplikacja jest przeznaczona. W przypadku aplikacji dla przedsiębiorstw zalecanym źródłem danych jest Microsoft Dataverse, ponieważ ma szereg zalet pod względem wydajności. W przypadku aplikacji z kilkoma transakcjami możesz używać innych dostępnych źródeł danych w środowisku.

Rozważając wydajność aplikacji, pomyśl o liczbie użytkowników, którzy będą korzystać z aplikacji po jej opublikowaniu; ilość transakcji tworzenia, pobierania, aktualizacji i usuwania (CRUD); rodzaj interakcji danych; dostęp geograficzny; oraz rodzaje urządzeń, którymi dysponują użytkownicy.

W tym artykule dowiesz się o niektórych najczęstszych problemach z wydajnością, które mogą sprawić, że aplikacje kanwy będą działać wolno, oraz o tym, jak je rozwiązać. Te informacje pomogą poprawić wydajność aplikacji z myślą o biznesplanie i rozwoju firmy.

Zaczniemy od kilku typowych problemów z wydajnością niezależnych od używanego łącznika oraz sposobów ich rozwiązania. W kolejnych sekcjach dowiesz się więcej o problemach z wydajnością bardziej specyficznych dla różnych łączników oraz o tym, jak je rozwiązywać.

Przed rozpoczęciem upewnij się, że rozumiesz fazy wykonywania aplikacji kanwy oraz przepływ wywołań danych w tych aplikacjach. Ponadto przeczytaj możliwe przyczyny niskiej wydajności aplikacji kanwy, aby dowiedzieć się o typowych pułapkach, których można uniknąć w trakcie projektowania i aktualizowania tych aplikacji.

Duże zestawy danych ładują się powoli na niektórych platformach

Wydajność aplikacji może się różnić podczas ładowania dużych zestawów danych na różnych platformach, takich jak iOS lub Android. Te wahania występują z powodu różnych ograniczeń dotyczących żądań sieciowych na poszczególnych platformach. Na przykład liczba równoczesnych żądań sieciowych może być inna zależnie od platformy. Ta różnica może mieć duży wpływ na czas ładowania danych z dużych zestawów.

Zaleca się załadowanie tylko tych danych, które muszą być natychmiast wyświetlane na ekranie. W przypadku innych danych sugerujemy stronicowanie i buforowanie. Więcej informacji: Porady i opis najlepszych rozwiązań w celu zwiększenia wydajności aplikacji kanw

Zbyt wiele pobieranych kolumn

Zalecamy wybieranie tylko niezbędnych kolumn dla aplikacji. Dodanie większej liczby lub wszystkich kolumn ze źródła danych spowoduje pobieranie wszystkich danych kolumn. Ta akcja powoduje dużą liczbę wywołań w sieci, a tym samym wysokie użycie pamięci w urządzeniu klienckim. Ten problem może mieć jeszcze większy wpływ na użytkowników korzystających z urządzeń mobilnych, jeśli przepustowość sieci jest ograniczona albo jeśli urządzenie ma ograniczoną ilość pamięci lub starszy procesor.

Jeśli na przykład używasz Dataverse jako źródła danych aplikacji, upewnij się, że włączono funkcję Jawny wybór kolumn. Ta funkcja umożliwia usłudze Power Apps ograniczenie pobierania danych tylko do danych w kolumnach używanych w aplikacji.

Aby włączyć funkcję jawnego wyboru kolumn w aplikacji kanwy, wybierz menu Ustawienia > Nadchodzące funkcje > Wersja zapoznawcza, a następnie włącz przełączenie Jawny wybór kolumny

Nieobsługiwane lub starsze przeglądarki

Użytkownicy nieobsługiwanych lub starszych przeglądarek mogą napotkać problemy z wydajnością. Upewnij się, że użytkownicy uruchamiają aplikacje kanwy tylko w obsługiwanych przeglądarkach.

Słaba wydajność ze względu na odległość geograficzną

Na wydajność ma wpływ położenie geograficzne środowiska oraz odległość źródła danych od użytkowników końcowych.

Zaleca się, aby środowisko znajdowało się blisko użytkowników. Usługa Power Apps wykorzystuje dla treści sieć dostarczania zawartości Azure (CDN), ale wywołania danych nadal otrzymują swoje dane ze źródeł danych. Źródło danych znajdujące się w innej lokalizacji geograficznej może negatywnie wpływać na wydajność aplikacji.

Potężne odległości lokalizacji geograficznych wpływają na wydajność w różny sposób, na przykład poprzez zwiększenie opóźnienia, zmniejszenie przepływności, obniżenie przepustowości i utratę pakietów.

Lista dozwolonych nie została skonfigurowana

Upewnij się, że wymagane adresy URL usług nie zostały zablokowane lub zostały dodane do listy dozwolonych zapory. Aby uzyskać pełną listę wszystkich adresów URL usług, które muszą być dozwolone dla usługi Power Apps, przejdź do tematu Wymagane usługi.

Używanie niedelegowalnych funkcji oraz nieodpowiednich limitów wierszy danych dla niedelegowalnych zapytań

Delegowalne funkcje delegują przetwarzanie danych do źródła danych, minimalizując obciążenie po stronie klienta. Gdy delegowanie nie jest możliwe, można ustawić limit wierszy danych dla zapytań niedelegowalnych, tak aby liczba wierszy zwracanych z połączenia z serwerem pozostawała optymalna.

Korzystanie z funkcji niedelegowalnych oraz nieodpowiedni limit wierszy danych dla zapytań niedelegowalnych powoduje dodatkowe obciążenie w przesyłaniu danych. To obciążenie skutkuje umieszczeniem odebranych danych w stercie JS po stronie klienta. Tam, gdzie to możliwe, używaj dla aplikacji funkcji delegowalnych, a dla zapytań niedelegowalnych ustawiaj optymalny limit wierszy danych.

Więcej informacji: Używane delegowania, Omówienie delegowania

Zdarzenie OnStart wymaga dostrojenia

Zdarzenie OnStart jest uruchamiane podczas ładowania aplikacji. Wywołanie dużych ilości danych przy użyciu funkcji we właściwości OnStart aplikacji spowoduje powolne ładowanie aplikacji. Ekran mocno uzależniony od kontrolek i wartości zdefiniowanych na innym ekranie ucierpi w formie spowolnionej nawigacji na ekranie.

W poniższych sekcjach opisano niektóre najbardziej typowe problemy występujące w tych sytuacjach.

Duża liczba wywołań w zdarzeniu OnStart powodująca powolne uruchamianie aplikacji

W przedsiębiorstwie duża liczba wywołań danych do centralnego źródła danych może doprowadzić do wąskiego gardła na serwerze lub do rywalizacji o zasoby.

Używaj mechanizmu buforowania i optymalizuj wywołania danych. Wielu użytkowników może używać jednej aplikacji, co powoduje docieranie wielu wywołań danych od każdego użytkownika do punktów końcowych serwera. Te wywołania danych mogą tworzyć miejsce, gdzie występuje wąskie gardło lub dławienie.

Opóźnienie w zdarzeniu OnStart spowodowane ciężkimi skryptami

Ciężkie (wolno działające) skrypty w zdarzeniu OnStart to jeden z najczęstszych błędów popełnianych w trakcie projektowania aplikacji kanwy. Twórcy powinni pozyskiwać tylko dane niezbędne do uruchomienia aplikacji.

Zoptymalizuj formułę w zdarzeniu OnStart. Na przykład przenieś niektóre funkcje do właściwości OnVisible. W ten sposób umożliwisz szybkie uruchomienie aplikacji, a pozostałe kroki będą kontynuowane w trakcie uruchamiania.

Więcej informacji: Optymalizowanie właściwości OnStart

Napiwek

Zalecamy korzystanie z właściwości App.StartScreen, ponieważ upraszcza ona uruchamianie aplikacji i zwiększa jej wydajność.

Wykorzystanie pamięci po stronie klienta

Sprawdzanie zużycia pamięci przez aplikacje kanwy jest ważne, ponieważ w większości przypadków aplikacje są uruchamiane na urządzeniach mobilnych. Najbardziej prawdopodobną przyczyną tego, że na niektórych urządzeniach aplikacja kanwy ulega awarii lub się zawiesza, są wyjątki pamięci w stercie.

Sterta Javascript (JS) może dojść do kresu swoich możliwości działania, ponieważ po stronie klienta są uruchomione ciężkie skrypty dodawania kolumn, łączenia, filtrowania, sortowania lub grupowania. W większości przypadków wyjątek braku pamięci w stercie na kliencie może spowodować awarię lub zawieszenie się aplikacji.

Używając danych ze źródeł takich jak Dataverse lub SQL Server, można skorzystać z obiektu Widok, aby się upewnić, że łączenie, filtrowanie, grupowanie i sortowanie odbywa się po stronie serwera, a nie klienta. Takie podejście zmniejsza obciążenie klienta skryptami wykonywania takich operacji.

Jeśli operacje mocno obciążające klienta, takie jak JOIN lub Group By, mają miejsce po stronie klienta, a zestaw danych zawiera 2000 lub więcej rekordów, rośnie liczba obiektów w stercie, wskutek czego osiąga ona granicę swoich możliwości.

Narzędzia deweloperskie dla większości przeglądarek umożliwiają sprofilowanie pamięci. Profil wizualizuje rozmiar sterty, dokumenty, węzły i odbiorniki. Sprawdź profil wydajności aplikacji za pomocą przeglądarki, zgodnie z opisem w Przegląd narzędzi dewelopera Microsoft Edge (Chromium). Sprawdź scenariusze, które przekroczą wartość progową dla pamięci dla sterty JS. Więcej informacji: Rozwiązywanie problemów z pamięcią

Przykład wykorzystania pamięci przez aplikację widziany w narzędziach deweloperskich przeglądarki.

Zagadnienia dotyczące wydajności podczas korzystania z łącznika programu SQL Server

Za pomocą łącznika programu SQL Server dla usługi Power Apps można nawiązać połączenie z lokalnym wystąpieniem programu SQL lub z usługą Azure SQL Database. W tej sekcji opisano typowe problemy związane z wydajnością i rozwiązania dotyczące korzystania z tego łącznika dla aplikacji kanw. Więcej informacji: Łączenie się z serwerem SQL Server z rozwiązania Power AppsTworzenie aplikacji kanwy z Bazy danych SQL Azure

Uwaga

Chociaż ta sekcja odnosi się do łącznika programu SQL Server w kontekście problemów z wydajnością i ich rozwiązywania, większość zaleceń ma również zastosowanie podczas używania dowolnego typu bazy danych — np. MySQL lub PostgreSQL — jako źródła danych.

Przyjrzyjmy się typowym problemom z wydajnością występującym podczas używania łącznika programu SQL Server dla aplikacji kanwy oraz ich rozwiązywaniu.

Zapytanie N+1

Galerie generujące zbyt wiele żądań do serwerów powodowały problem z zapytaniami N+1. Problem z zapytaniami N+1 jest jednym z najczęściej występujących problemów podczas korzystania z kontrolki galerii.

Aby uniknąć tego problemu, należy użyć wyświetlania obiektów w widoku SQL back end lub zmienić scenariusze interfejsu użytkownika.

Skanowanie tabeli zamiast indeksu

Aplikacja może działać wolniej, jeśli używane przez nią funkcje wykonują zapytania w bazie danych, co powoduje skanowanie tabel zamiast wyszukiwania w indeksie. Więcej informacji: Wskazówki, skanowanie tabeli i wyszukiwanie w indeksie

Aby rozwiązać takie problemy, użyj w formułach operatora StartsWith zamiast IN. Podczas używania źródła danych SQL operator StartsWith powoduje wyszukiwania w indeksie, natomiast IN powoduje skanowanie indeksu lub tabeli.

Powolne wykonywanie zapytań

Wykonaj profilowanie i dostrajanie wolno działających zapytań i indeksów w bazie danych SQL. Na przykład jeśli istnieje formuła pobierająca pewne dane z jednej kolumny w porządku malejącym (DESC), ta kolumna sortowania powinna mieć indeks o kolejności malejącej. Klucz indeksu domyślnie tworzy porządek rosnący (ASC).

Możesz również sprawdzić adres URL żądań o dane. Na przykład następująca wstawka żądania danych (częściowe wywołanie OData) wnioskuje do programu SQL o zwrócenie 500 rekordów pasujących do kolumny Value z uporządkowaniem według ID w kolejności malejącej.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Pomaga to zrozumieć wymagania wobec indeksu pozwalające uwzględnić te warunków żądania. W tym przykładzie kolumna ID powinna zawierać indeks w kolejności malejącej, aby zapytanie zostało wykonane szybciej.

Sprawdź plan wykonywania wolno działających zapytań i zobacz, czy istnieją jakieś skanowania tabel lub indeksów. Monitoruj wszelkie nadmierne koszty wyszukiwania kluczy w planie wykonywania.

Więcej informacji:

Rywalizacja o zasoby bazy danych

Upewnij się, że w źródle danych — bazie danych SQL — nie występuje rywalizacja o zasoby, taka jak wąskie gardło w procesorze, rywalizacja o we/wy, wykorzystanie pamięci czy rywalizacja o tymczasową bazę danych tempDB. Sprawdź również, czy nie występują blokady, oczekiwania, zakleszczenia ani limity czasu wykonywania zapytań.

Napiwek

Użyj automatycznego dostrajania, aby poznać potencjalne problemy z wydajnością zapytań i zalecane rozwiązania oraz spowodować automatyczne rozwiązanie zidentyfikowanych problemów.

Pełny klient lub nadmiar żądań

Aplikacja wykonująca operacje Group By, Filter By lub JOIN po stronie klienta używa procesora i zasobów pamięci z urządzeń klienckich. W zależności od rozmiaru danych te operacje mogą spowodować dłuższe wykonywanie skryptów po stronie klienta, zwiększając rozmiar sterty JS na kliencie. Podczas korzystania z lokalnego źródła danych ten problem rośnie, ponieważ każde wywołanie wyszukiwania danych trafia do źródła danych za pośrednictwem bramy danych.

W takich sytuacjach należy dla operacji Group By, Filter By i JOIN w bazie danych SQL użyć obiektu Widok. Widoki mogą selektywnie używać kolumn i usuwać niepotrzebne kolumny zawierające duże dane, takie jak NVARCHAR(MAX), VARCHAR(MAX) i VARBINARY(MAX).

Napiwek

Takie podejście pomaga również rozwiązać problem z zapytaniami N +1.

Rozmiar danych przesyłanych do klienta

Domyślnie aplikacja kanwy wyświetla dane z dostępnych obiektów bazy danych przy użyciu tabel lub widoków. Pobieranie wszystkich kolumn z tabeli może spowalniać operację, szczególnie przy pobieraniu dużych danych, takich jak NVARCHAR(MAX).

Przesyłanie dużych ilości danych do klientów wymaga czasu. Ten transfer powoduje również więcej czasu przetwarzania skryptów, gdy po stronie klienta znajduje się duża ilość danych w stercie JS zgodnie z opisem w tym artykule.

Aby zmniejszyć rozmiar danych przesyłanych do klienta, należy użyć widoków z określonymi kolumnami wymaganymi przez aplikację i upewnić się, że włączono jawne zaznaczenie kolumn, zgodnie z opisem w tym artykule.

Zagadnienia specyficzne dla lokalnego wystąpienia programu SQL Server

Wydajność aplikacji kanwy wykorzystujących łącznik programu SQL Server z lokalną bramą danych może być uzależniona od różnych czynników. W tej sekcji wymieniono typowe problemy z wydajnością specyficzne dla korzystania z lokalnego źródła bazodanowego oraz ich rozwiązania.

Lokalna brama danych w złej kondycji

Organizacje mogą definiować wiele węzłów lokalny bram danych. Nawet jeśli jeden z węzłów jest nieosiągalny, żądania danych do węzła w złej kondycji nie zwrócą wyniku w rozsądnym horyzoncie czasowym albo po dłuższym oczekiwaniu spowodują komunikaty o błędach „braku dostępności”.

Upewnij się, że wszystkie lokalne węzły bramy danych są w dobrej kondycji oraz skonfigurowane z minimalnym opóźnieniem sieci między węzłami a wystąpieniem programu SQL.

Lokalizacja lokalnej bramy danych

Brama danych wymaga wywołań sieciowych do lokalnych źródeł danych w celu interpretowania żądań OData. Na przykład brama danych musi zrozumieć schemat tabeli danych w celu przetłumaczenia żądań OData na polecenia języka SQL (DML). Gdy brama danych jest skonfigurowana w oddzielnej lokalizacji z dużym opóźnieniem sieci między bramą danych a wystąpieniem programu SQL, powstają dodatkowe obciążenia przetwarzaniem.

Gdy oczekuje się dużych ilości żądań danych w środowisku przedsiębiorstwa, zalecamy posiadanie skalowalnego klastra bramy danych. Sprawdź, ile połączeń jest nawiązywanych między węzłami bramy danych a wystąpieniem programu SQL.

Sprawdzając równoczesne połączenia w lokalnej bramie danych lub na serwerze SQL, organizacja może zdecydować o tym, kiedy brama danych musi zostać rozbudowana w poziomie i o ile węzłów.

Skalowalność bramy danych

Jeśli organizacja oczekuje uzyskiwania dostępu do dużych ilości danych przez lokalną bramę danych, istnienie tylko jednego węzła lokalnej bramy danych może stanowić wąskie gardło przy tak dużej liczbie żądań.

Pojedynczy węzeł lokalnej bramy danych może być wystarczający na nie więcej niż 200 równoczesnych połączeń. Ponadto jeśli te wszystkie równoczesne połączenia aktywnie wykonują zapytania, inne żądania muszą czekać na dostępne połączenie.

Aby uzyskać informacje, że lokalny serwera danych skaluje się zgodnie z wielkością danych i żądań, przejdź do tematu Monitoruj i zoptymalizuj wydajność lokalnej bramy danych.

Zagadnienia specyficzne dla usługi Azure SQL Database

Aplikacje kanwy mogą się łączyć z usługą Azure SQL Database przy użyciu łącznika programu SQL Server. Często występującymi przyczynami problemów z wydajnością podczas korzystania z Usługi Azure SQL Database jest wybranie niewłaściwej warstwy dla wymagań biznesowych.

Usługa Azure SQL Database jest dostępna w różnych warstwach usług, z różnymi możliwościami pasującymi do różnych wymagań biznesowych. Aby uzyskać więcej informacji na temat warstw, przejdź do dokumentacji usługi Azure SQL Database.

Przy dużej ilości żądań o dane zasoby w wybranej warstwie mogą być dławione po osiągnięciu wartości progowej. Takie dławienie ogranicza wydajność wykonywania następnego zestawu zapytań.

Sprawdź warstwę usługi Azure SQL Database. Niższa warstwa będzie miała pewne ograniczenia. Z punktu widzenia wydajności ważne są procesor CPU, przepływność operacji we/wy i opóźnienie. W związku z tym należy okresowo sprawdzać wydajność bazy danych SQL i czy użycie zasobów przekracza próg. Na przykład lokalne wystąpienie programu SQL Server zwykle ustawia próg użycia procesora CPU na około 75%.

Zagadnienia dotyczące wydajności podczas korzystania z łącznika programu SharePoint

Możesz użyć łącznika SharePoint do tworzenia aplikacji przy użyciu danych z list Microsoft. Aplikacje kanwy można również tworzyć bezpośrednio z widoku listy. Przyjrzyjmy się typowym problemom z wydajnością występującym podczas używania źródła danych programu SharePoint z aplikacjami kanwy oraz ich rozwiązywaniu.

Zbyt wiele dynamicznych kolumn odnośników

Program SharePoint obsługuje różne typy danych, w tym dynamiczne odnośniki, takie jak Osoba, Grupa i Obliczone. Jeśli lista definiuje zbyt wiele kolumn dynamicznych, potrzeba więcej czasu na wykonanie operacji w tych dynamicznych kolumnach w programie SharePoint, zanim dane zostaną zwrócone do klienta z uruchomioną aplikacją kanwy.

Nie należy nadużywać dynamicznych kolumn odnośników w programie SharePoint. To nadużywanie może spowodować dodatkowe obciążenie po stronie SharePoint związane z wykonywaniem operacji na danych. Na przykład można użyć kolumny statycznej na aliasy adresów e-mail lub imiona i nazwiska osób.

Kolumny z obrazami i załączniki

Rozmiar obrazu i dołączonego pliku może powodować spowolnioną odpowiedź w trakcie pobierania do klienta.

Przejrzyj listę i upewnij się, że zdefiniowano tylko niezbędne kolumny. Liczba kolumn na liście wpływa na wydajność wykonywania żądań o dane. Wynika to z faktu, że pasujące rekordy lub rekordy aż do zdefiniowanych limitów wierszy danych są pobierane, a następnie przesyłane z powrotem do klienta ze wszystkimi kolumnami zdefiniowanymi na liście — bez względu na to, czy aplikacja używa ich wszystkich, czy nie.

Włącz funkcję Jawny wybór kolumn, aby wysyłać zapytania tylko do kolumn używanych przez aplikację.

Duże listy

Jeśli masz dużą listę z setkami tysięcy rekordów, weź pod uwagę jej partycjonowanie lub podzielenie na kilka mniejszych list na podstawie parametrów takich jak kategorie lub data i godzina.

Na przykład dane mogą być przechowywane na różnych listach tworzonych co rok lub co miesiąc. Następnie można zaimplementować aplikację, która umożliwi użytkownikowi wybranie przedziału czasu i pobieranie danych z tego zakresu.

W kontrolowanym środowisku test porównawczy wydajności dowiódł, że wydajność żądań OData względem list Microsoft lub programu SharePoint jest silnie związana z liczbą kolumn na liście i liczbą pobieranych wierszy (ograniczona przez limit wierszy danych dla nie- zapytania delegowalne). Mniejsza liczba kolumn i niższy limit wierszy danych mogą sprawić, że aplikacja kanwy będzie działać lepiej.

Jednak w rzeczywistości aplikacje są projektowane tak, aby spełniały określone wymagania biznesowe. Zmniejszenie limitu wierszy danych lub liczby kolumn na liście może nie być szybkie ani proste. Tym niemniej zalecamy monitorowanie żądań OData po stronie klienta oraz dostrajanie limitu wierszy danych dla kwerend niedelegowalnych i liczby kolumn na liście programu .

Zagadnienia dotyczące wydajności podczas korzystania z Dataverse jako źródła danych

Gdy używasz Microsoft Dataverse jako źródła danych, żądania danych przechodzą bezpośrednio do wystąpienia środowiska, bez przechodzenia przez Azure API Management. Więcej informacji: Przepływ danych podczas łączenia się z Microsoft Dataverse

Napiwek

Gdy w Dataverse używane są tabele niestandardowe, może być wymagana dodatkowa konfiguracja zabezpieczeń, aby użytkownicy mogli wyświetlać rekordy za pomocą aplikacji kanwy. Więcej informacji: Koncepcje dotyczące zabezpieczeń w usłudze Dataverse, Konfigurowanie zabezpieczeń użytkowników do zasobów w środowisku, Role zabezpieczeń i uprawnienia

Aplikacja kanwy łącząca się z usługą Dataverse może działać wolno, jeśli wykonuje skrypty mocno obciążające klienta, takie jak Filter By lub JOIN, po stronie klienta, a nie na serwerze.

W miarę możliwości używaj widoków usługi Dataverse. Widok z wymaganymi kryteriami sprzęgania lub filtrowania pomaga zmniejszyć obciążenie przetwarzaniem spowodowane używaniem całej tabeli. Na przykład jeśli jest konieczne sprzężenia tabel i filtrowanie ich danych, można zdefiniować widok, łącząc je i definiując tylko wymagane kolumny. Następnie użyj tego widoku w aplikacji wykonującej te operacje sprzęgania/filtrowania po stronie serwera, a nie klienta. Ta metoda nie tylko zmniejsza liczbę operacji, ale także przesyłanie danych. Aby uzyskać informacje dotyczące edytowania kryteriów filtrowania i sortowania, przejdź do tematu Edytowanie kryteriów filtrowania.

Zagadnienia dotyczące wydajności podczas korzystania z łącznika programu Excel

Łącznik programu Excel zapewnia łączność z aplikacji kanwy do danych w tabeli wewnątrz pliku programu Excel. Ten łącznik ma ograniczenia w porównaniu do innych źródeł danych — na przykład ograniczone funkcje delegowalne — umożliwiające aplikacji kanwy ładowanie danych z tabeli obejmujące maksymalnie 2000 rekordów. Aby załadować ponad 2000 rekordów, podziel dane w różnych tabelach danych jako inne źródła danych.

Przyjrzyjmy się typowym problemom z wydajnością występującym podczas używania programu Excel jako źródła danych dla aplikacji kanwy oraz rozwiązywaniu tych problemów.

Zbyt wiele tabel danych i duży rozmiar danych

Powolność działania aplikacji może wystąpić, gdy używa ona pliku programu Excel ze zbyt wieloma tabelami danych lub tabelami danych z ogromnymi ilościami danych rozmieszczonymi w kilku kolumnach. Plik programu Excel nie jest relacyjną bazą danych ani źródłem danych oferującym funkcje delegowalne. Najpierw Power Apps musi załadować dane ze zdefiniowanych tabel danych, a następnie są w nich używane funkcje, takie jak Filtr, Sortowanie, DOŁĄCZANIE, Grupowanie według i Wyszukiwanie.

Zbyt wiele tabel danych z dużą liczbą wierszy i kolumn wpływa na wydajność aplikacji i obciążenie po stronie klienta, ponieważ na każdej tabeli danych muszą być wykonywane operacje w stercie JS. Ten efekt powoduje również, że aplikacja zużywa więcej pamięci po stronie klienta.

Aby takie zachowania nie miały wpływu na aplikację, zdefiniuj tylko niezbędne kolumny w tabeli danych w pliku programu Excel.

Zasobochłonne transakcje

Excel nie jest relacyjną bazą danych. Wszelkimi zmianami w aplikacji program Excel zarządza tak samo, jak wtedy, użytkownik zmienia dane w pliku programu Excel. Jeśli aplikacja ma dużą liczbę operacji odczytu, ale mniej operacji CRUD (tworzenie/aktualizowanie/usuwanie), może działać dobrze. Jeśli jednak aplikacja dokonuje zasobochłonnych transakcji, może niekorzystnie wpłynąć na wydajność aplikacji.

Nie ma określonej wartości progowej dla liczby transakcji, ponieważ zależy ona również od rodzaju danych, na których są wykonywane operacje. Na wydajność aplikacji wpływa również kilka innych aspektów, takich jak obciążenie sieci czy parametry urządzeń użytkowników.

Jeśli masz dane tylko do odczytu, możesz je zaimportować do aplikacji lokalnie zamiast ładować ze źródło danych. W przypadku aplikacji dla przedsiębiorstw należy zamiast tego używać źródeł danych takich jak Dataverse, SQL Server czy SharePoint.

Rozmiar pliku

Dla pliku programu Excel można wybierać spośród szerokiej gamy opcji magazynu w chmurze o różnej — lub konfigurowalnej — pojemności. Jednak jeden duży plik programu Excel ze wszystkimi tabelami zdefiniowanymi w jednym pliku tworzy dodatkowe obciążenie dla aplikacji podczas pobierania pliku oraz odczytywania danych do załadowania po stronie klienta.

Zamiast używać jednego dużego pliku, podziel dane na wiele plików programu Excel z minimalną ilością tabel danych. Następnie połącz się z każdym plikiem tylko wtedy, gdy będzie on potrzebny. W ten sposób ładowanie danych z tabeli danych odbywa się we fragmentach, zmniejszając obciążenie powodowane przetwarzaniem wielu tabel lub dużego zestawu danych.

Lokalizacja pliku

Lokalizacja geograficzna źródła danych oraz odległość od lokalizacji klientów może powodować typowe wąskie gardło wydajności dla aplikacji oraz wywoływać opóźnienie sieci. Efekt ten może zostać wzmocniony w sytuacji, gdy klient mobilny ma ograniczoną przepustowość dla łączności.

Lepiej jest trzymać plik blisko użytkowników końcowych (lub większości użytkowników końcowych przy globalnych odbiorcach), tak aby można go było szybko pobrać.

Następne kroki

Porady i najlepsze praktyki dotyczące poprawy wydajności aplikacji kanwy

Zobacz także

Opis faz wykonywania aplikacji kanwy i przepływu wywołań danych
Typowe przyczyny niskiej wydajności aplikacji kanwy
Typowe problemy i rozwiązania dla Power Apps
Rozwiązywanie problemów z uruchamianiem w usłudze Power Apps

Uwaga

Czy możesz poinformować nas o preferencjach dotyczących języka dokumentacji? Wypełnij krótką ankietę. (zauważ, że ta ankieta jest po angielsku)

Ankieta zajmie około siedmiu minut. Nie są zbierane żadne dane osobowe (oświadczenie o ochronie prywatności).