Обичайни проблеми и решения при производителността на приложение за платно

Можете да създавате приложения за платно чрез с различни масиви от източници на данни. Изберете източник на данни и съединител въз основа на бизнес нуждите и сценариите, за които проектирате приложението. За корпоративни приложения Microsoft Dataverse е препоръчителната източник на данни, тъй като предоставя няколко предимства за производителността. За приложения с няколко транзакции можете да използвате всички други налични източници на данни във вашата среда.

от съображения за производителността на приложение, помислете за броя потребители, които ще използват приложението, когато бъде публикувано, обема на транзакциите (CRUD) за създаване, извличане, актуализиране и изтриване, типа взаимодействия с данни, географския достъп и устройствата на потребителя.

В тази статия ще научите за някои от най-често срещаните проблеми с производителността, които могат да накарат приложенията на платното да работят бавно и как да ги разрешите. Тази информация ще ви помогне да подобрите ефективността на приложението с оглед на вашия бизнес план и растеж.

Ще започнем с някои от често срещаните проблеми при производителността, които възникват, независимо от използвания конектор. В следващите раздели ще научите за проблеми с производителността и разрешения, специфични за различни съединители.

Преди да започнете, уверете се, че сте разбрали фазите на изпълнение на приложения за платното и потока на повикванията за данни. Също прочетете обичайни източници на бавна производителност за приложения за платно, за да научите повече за често срещаните клопки, които можете да избегнете, докато проектирате или актуализирате приложения за платно.

Големи набори от данни се зареждат бавно на различни платформи

Ефективността на дадено приложение може да варира при зареждане на големи набори от данни на различни платформи като iOS или Android. Тази промяна се случва поради различни ограничения на мрежовите заявки за всяка платформа. Например, броят на разрешените едновременни мрежови заявки може да е различен според платформите. Тази разлика може да окаже голямо влияние върху времето за зареждане на данни за големи набори от данни.

Препоръчваме ви да зареждате само данните, които са ви необходими, за да се покажат незабавно на екрана. За други данни странирайте и кеширайте данните си. Повече информация: Съвети и най-добри практики за подобряване на ефективността на приложението за платно

Извлечени са твърде много колони

Препоръчваме да избирате само необходимите за приложението колони. Добавянето на повече (или всички) колони от източник на данни изтегля всички данни в колоните. Това действие води до голям брой мрежови повиквания и следователно до голяма употреба на паметта в клиентското устройство. Този проблем може да повлияе още повече на потребителите с мобилни устройства, ако мрежовата честотна лента е ограничена или ако дадено устройство има ограничена памет или наследствен процесор.

Например, ако използвате Dataverse като източник на данни за вашето приложение, уверете се, че сте активирали функцията Изричен избор на колона. Тази функция позволява на Power Apps да ограничи извличането на данни само за колоните, използвани в приложението.

За да включите функцията за явен избор на колона в приложението за платно, отидете на Настройки > Предстоящи функции > Преглед и след това включете Изричен избор на колона превключвател.

Браузъри с неподдържана или наследена версия

Потребители, използващи неподдържани или стари браузъри може да имат проблеми с производителността. Уверете се, че потребителите използват само поддържани браузъри за стартиране на приложения за платно.

Бавна представяне работа поради географското разстояние

Географско местоположение на средата и разстоянието на източник на данни от потребителите може да влияе върху ефективността.

Препоръчваме вашата среда да бъде разположена близо до потребителите. Въпреки че Power Apps използва Azure Content Delivery Network за съдържание, обажданията за данни все още получават данните от източник на данни. Източник на данни, намиращ се на друго географско местоположение, може да повлияе неблагоприятно на работата на приложението.

Прекомерните разстоянията на географското местоположение влияят на ефективността по различни начини, като латентност, намалена производителност, по-ниска честотна лента или загуба на пакети.

Списъкът с разрешени не е конфигуриран

Уверете се, че необходимите URL адреси за услуги не са блокирани или че са добавени към списъка за разрешаване на вашата защитна стена. За пълен списък на всички URL адреси на услуги, които трябва да бъдат разрешени за Power Apps, отидете на Необходими услуги.

Използване на функции, които не могат да се детайлират, и неподходящо ограничение на ред данни за заявки, които не могат да бъдат делегирани

Делегируемите функции делегират обработката на данни на източник на данни, като минимизират режийните разходи от страна на клиента. Когато делегирането не е възможно, можете да ограничите ограничението на редовете данни за заявки, които не могат да бъдат делегирани, така че броят на редовете, върнати от сървърно базирана връзка, да остане оптимален.

За да използвате неподлежащи на делегиране функции и неподходящо ограничение на ред данни за заявки, които не могат да бъдат делегирани добавете допълнителни режийни разходи при трансфер на данни. Тези режийни резултати водят до манипулация на получените данни към JS купчина от страна на клиента. Уверете се, че използвате функции за делегиране за приложението, когато е налично, и оптималното ограничение на реда за данни за заявки, които не могат да бъдат делегирани.

Още информация: Използване на делегиране, Общ преглед на делегирането

Събитието OnStart се нуждае от настройка

Събитието OnStart се изпълнява, когато приложението се зарежда. Извикване на големи количества данни с помощта на функциите в свойство OnStart ще накара приложението да се зарежда бавно. Екран с голяма зависимост от контроли и стойности, определени на друг екран, ще бъде засегнат при бавна навигация на екрана.

Следващите раздели описват някои от най-често срещаните проблеми в тези ситуации.

Голям брой обаждания в събитие OnStart, което кара приложението да стартира бавно

В предприятието обемът на обажданията за данни към централен източник на данни може да доведе до затруднения на сървъра или до конфликт на ресурси.

Използвайте кеш механизъм, за да оптимизирате обажданията за данни. Едно приложение може да се използва от много потребители, което води до много обаждания за данни на потребител, които достигат до крайните точки на сървъра. Тези обаждания за данни могат да бъдат място, където може да се случи затруднение или ограничаване.

Латентност при събитие OnStart поради тежки скриптове

Тежките скриптове при събитие OnStart са една от най-често срещаните грешки при проектирането на приложения за платно. Трябва да получавате само необходимите данни, необходими за стартирането на приложението.

Оптимизирайте формула в събитие OnStart. Например преместете някои функции в свойството OnVisible вместо това. По този начин можете да оставите приложението да стартира бързо и други стъпки да продължат, докато приложението се стартира.

Повече информация: Оптимизирайте свойството OnStart

Съвет

Препоръчваме да използвате App.StartScreen свойство, тъй като опростява стартирането на приложението и повишава производителността на приложението.

Напрежение върху паметта от страна на клиента

Важно е да проверите консумацията на памет за приложения на платното, тъй като в повечето случаи приложението се изпълнява на мобилни устройства. Изключенията от паметта в купчината са най-вероятната причина за приложението на платното, което се срива или замръзва („виси“) на определени устройства.

JavaScript (JS) купчина може да достигне ограничението поради тежки скриптове, изпълнявани от страна на клиента за добавяне, присъединяване, филтриране, сортиране или групиране на колони. В повечето случаи изключението извън паметта в купчината в клиента може да задейства приложението да се срине или да увисне.

При използване на данни от източници като Dataverse или SQL Server, можете да използвате обект Изглед, за да се гарантира присъединяване, филтриране, групиране или сортиране от страна на сървъра вместо от страна на клиента. Този подход намалява режийните на клиента за скриптове за такива действия.

Ако тежките клиентски операции като JOIN или Group By се случат от страна на клиента с набор от данни, съдържащ 2000 записа или повече, обектите в купчината ще се увеличат, което ще доведе до надвишаване на ограниченията за памет.

Инструментите за програмисти за повечето браузъри ви позволяват да профилирате паметта. Това ви помага да визуализирате размера на купчината, документите, възлите и слушателите. Профилирайте ефективността на приложението, като използвате браузър, както е описано в Общ преглед на инструментите за програмисти на Microsoft Edge (Chromium). Проверете сценариите, които надвишават прага на паметта на JS купчината. Повече информация: Отстранете проблемите с паметта

Съображения за производителност при използване на съединителя на SQL Server

Можете да използвате Конектор на SQL Server за Power Apps за свързване към SQL Server локален или Azure SQL база данни. Този раздел описва често срещани проблеми и резолюции, свързани с производителността, за използване на този конектор за приложение на платното. Повече информация: Свържете се с SQL Server от Power Apps, Създайте приложение за платно от база данни на Azure SQL

Бележка

Въпреки че този раздел се позовава на съединителя на SQL Server за проблеми с производителността и разрешения, повечето препоръки се прилагат и при използване на всеки тип база данни като източник на данни, като MySQL или PostgreSQL.

Нека да разгледаме често срещаните проблеми с производителността и резолюции при използване на конектора на SQL Server за приложения на платното.

Заявка N+1

Галериите, генериращи твърде много заявки към сървъри, предизвикват проблеми с заявка N+1. Проблемът със заявката N+1 е един от най-често срещаните проблеми при използване на контролата Gallery.

За да избегнете проблема, използвайте преглед на обекти в SQL back end или променете сценариите на потребителския интерфейс.

Сканиране на таблица вместо търсене на индекс

Приложението може да се забави, ако функциите, използвани от приложението, изпълняват заявки в базата данни, което води до сканиране на таблици вместо търсене на индекс. Повече информация: Съвети, SCAN за таблица и SEEK за индекс

За да разрешите подобни проблеми, използвайте StartsWith вместо IN във формула. Когато използвате SQL източник на данни, StartsWith операторът води до търсене на индекс; но IN операторът води до сканиране на индекс или таблица.

Бавни заявки

Можете да профилирате и настройте бавни заявки и индекси в SQL базата данни. Например, ако формула получава определени данни с низходящ (DESC) ред в определена колона, тази колона за сортиране трябва да има индекс с низходящ ред. Индексният ключ създава възходящ (ASC) ред по подразбиране.

Можете също да проверите URL адреса на заявките за данни. Например, следващата заявка за данни фрагмент (частично извикване на OData) иска от SQL да върне 500 записа, съответстващи на колона Стойност и да подреди по ИД в низходящ ред.

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

Това помага да се разберат изискванията на индекса за покриване на такива условия на заявка. В този пример, ако колоната ИД има индекс с низходящ ред, заявката ще бъде изпълнена по-бързо.

Проверете плана за изпълнение на бавни заявки, за да видите дали съществува сканиране на таблица или индекс. Следете всички прекомерни разходи за търсене на ключове в плана за изпълнение.

Допълнителна информация:

• Наблюдаване и настройване за производителност
• Наблюдение на ефективността чрез използване на Query Store
• Разширен преглед на събитията

Съперничество за ресурси на база данни

Уверете се, че източникът на данниБазата данни на SQL няма оспорвания на ресурси, като гърло на процесора, I/O спор, натиск на паметта или съперничество за tempDB. Също така проверете за заключения, изчаквания, мъртва точка и изтичания на времето на заявка.

Съвет

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

Дебел клиент или прекомерни заявки

Приложение, изпълняващо операции по групиране по, филтриране по или ПРИСЪЕДИНЯВАНЕ от страна на клиента, използва процесор и ресурси от паметта от клиентските устройства. В зависимост от размера на данните, тези операции може да отнемат повече време за скриптове от страна на клиента, увеличавайки размера на JS купчина на клиента. Този проблем се утежнява, когато използвате локален източник на данни, тъй като всяко извикване на данни за търсене преминава към източник на данни през шлюза за данни.

В такива ситуации използвайте обекта Преглед в SQL база данни за операциите Групиране по, Филтриране по или СЪЕДИНЕНИЕ . Изгледите могат да използват селективни колони и да премахват ненужните колони с големи типове данни, като NVARCHAR(MAX), VARCHAR(MAX) и VARBINARY(MAX).

Съвет

Този подход също помага за справяне с Проблем със заявка N+1.

Размер на данните, прехвърлени на клиента

По подразбиране приложение за платно показва данни с помощта на таблиците или изгледи от наличните обекти на базата данни. Извличането на всички колони от таблица може да доведе до бавен отговор, особено когато се използват големи типове данни като NVARCHAR(MAX).

Прехвърлянето на големи количества данни на клиенти отнема време. Този трансфер води и до повече време за скриптове, когато има големи количества данни в JS купчината от страна на клиента, както е описано по-рано в тази статия.

За да намалите размера на данните, които се прехвърлят към клиента, използвайте изгледи със специфичните колони, необходими за приложението, и се уверете, че е разрешен изричен избор на колона, както е описано по-рано в тази статия.

Съображения, специфични за локален SQL Server

Ефективността на приложения на платното, използващи съединител на SQL Server с локален шлюз за данни, може да бъде засегната по различни начини. Този раздел изброява често срещаните проблеми и резолюции, специфични за използването на локален източник на база данни.

Неизправен локален шлюз за данни

Организациите могат да дефинират множество възли за локални шлюзове за данни. Дори ако един от възлите е недостъпен, заявките за данни към неизправния възел няма да върнат резултата в рамките на приемлив период от време или да причинят „unreachable“ съобщения за грешка, след като изчакате известно време.

Уверете се, че всички локални възли на шлюза за данни са здрави и конфигурирани с минимална латентност на мрежата между възлите и екземпляра на SQL.

Местоположение на локален шлюз за данни

Шлюзът за данни изисква мрежови повиквания към локален източници на данни, за да интерпретира заявките OData. Например шлюзът за данни трябва да разбере схемата на таблицата с данни, за да преведе заявките OData в изрази за манипулиране на SQL данни (DML). Допълнителни режийни разходи се добавят, когато шлюзът за данни е конфигуриран на отделно място с висока латентност на мрежата между шлюза за данни и SQL екземпляра.

В корпоративна среда се препоръчва наличието на мащабируем клъстер за шлюз за данни, когато се очакват тежки заявки за данни. Проверете колко връзки са установени между възлите на шлюза за данни и екземпляра на SQL.

Чрез проверка на едновременните връзки в локален шлюз за данни или в SQL екземпляр, вашата организация може да идентифицира момента, когато шлюзът за данни трябва да се мащабира и с колко възли.

Мащабируемост на шлюз за данни

Ако очаквате да получите достъп до голям обем данни от шлюза за данни локален, само един възел на шлюза за данни локален може да се превърне в пречка за покриване на толкова голям обем заявки.

Един възел на шлюза за данни локален може да е достатъчен, за да се справи с 200 или по-малко едновременни връзки. Ако обаче всички тези едновременни връзки изпълняват заявки активно, други заявки в крайна сметка чакат налична връзка.

За информация как да гарантирате, че вашият локален шлюз за данни се мащабира в съответствие с обема на данните и заявките, отидете на Наблюдавайте и оптимизирайте ефективността на локален шлюз за данни.

Съображения, специфични за Azure SQL база данни

Приложенията на платното могат да се свързват с базата данни на Azure SQL с помощта на съединителя на SQL Server. Честа причина за проблеми с производителността при използване на Azure SQL база данни е изборът на грешен слой за вашите бизнес изисквания.

Базата данни на Azure SQL се предлага в различни нива на услуги, с различни възможности за съвпадение на различни бизнес изисквания. За повече информация относно нивата отидете на Документация за базата данни на Azure SQL.

При тежки заявки за данни, ресурсите на нивото, което сте избрали, могат да бъдат ограничени, след като се достигне праговата стойност. Такова регулиране компрометира производителността на следващия набор от заявки.

Проверете нивото на услугата на Azure SQL база данни. По-ниско ниво ще има някои ограничения. От гледна точка на производителността CPU, I/O пропускателната способност и латентността са важни. По тази причина, препоръчваме да проверявате периодично производителността на SQL базата данни и проверявайте дали използването на ресурси надвишава прага. Например локален SQL Server обикновено задава прага на използване на процесора на около 75 процента.

Съображения за производителност при използване на съединителя на SharePoint

Можете да използвате съединител SharePoint за създаване на приложения чрез използване на данни от Microsoft Lists. Можете също така да създавате приложения за платно директно от изглед на списък. Нека да разгледаме често срещаните проблеми с производителността и резолюции при използване на източник на данни SharePoint за приложения за платно.

Твърде много колони за динамично търсене

SharePoint поддържа различни типове данни, включително динамични справки като Личност, Група и Изчислено. Ако списък дефинира твърде много динамични колони, отнема повече време за манипулиране на тези динамични колони вътре SharePoint преди да върнете данни на клиента, изпълняващ приложението на платното.

Не прекалявайте с динамичните справочни колони в SharePoint. Това прекомерно използване може да доведе до неизбежни и допълнителни режийни разходи от страната на SharePoint за манипулиране на данни. Вместо това можете да използвате статични колони, за да запазите псевдоними на имейли или имена на хората например.

Графична колона и прикачен файл

Размерът на изображението и прикаченият файл могат да се отдадат на бавен отговор при извличане на клиента.

Прегледайте своя списък и се уверете, че са определени само необходимите колони. Броят на колоните в списъка влияе върху изпълнението на заявките за данни. Този ефект се дължи на съвпадащите записи или записите до дефинираните ограничения на реда с данни се извличат и предават обратно на клиента с всички колони, дефинирани в списъка—дори ако приложението не използва всички тях.

За да търсите само в колони, използвани от приложението, активирайте функцията за Изричен избор на колона, както е описано по-рано в тази статия.

Големи списъци

Ако имате голям списък със стотици хиляди записи, помислете за разделяне на списъка или разделете списъка на няколко списъка въз основа на параметри като категории или дата и час.

Например вашите данни могат да се съхраняват в различни списъци на годишна или месечна база. В такъв случай можете да проектирате приложението, за да позволите на потребителя да избере времеви прозорец за извличане на данните в този диапазон.

В рамките на контролирана среда бенчмаркът за ефективност доказа, че ефективността на заявката на OData срещу Microsoft Lists или SharePoint е силно свързана с броя на колоните в списъка и броя на извличаните редове (ограничен от ограничение на ред данни за заявки, които не могат да бъдат делегирани). По-малкият брой колони и по-ниската настройка за ограничение на редове с данни могат да направят приложението за платно по-добро.

В реалния свят обаче приложенията са създадени да отговарят на определени бизнес изисквания. Може да не е бързо или просто да се намали ограничението за редове данни или броят на колоните в списък. Препоръчваме обаче да наблюдавате заявките на OData от страна на клиента и да настроите ограничението за редове с данни за заявки, които не могат да се делегират и броя на колоните в списъка.

Съображения за производителност при използване на Dataverse като източник на данни

Когато използвате Microsoft Dataverse като източник на данни, заявките за данни отиват директно към екземпляра на околната среда, без да преминават през Azure API Management. Повече информация: Поток на извикване на данни при свързване към Microsoft Dataverse

Съвет

Когато потребителски таблици се използват в Dataverse, може да се наложи допълнителна конфигурация на защитата, за да могат потребителите да преглеждат записите с приложения на платното. Повече информация: Концепции за защита в Dataverse, Конфигурирайте защитата на потребителя за ресурси в среда, Роли на защита и привилегии

Приложението за платно, свързано с Dataverse, може да се изпълнява бавно, ако изпълнява тежки клиентски скриптове, като например филтриране по или присъединяване от страна на клиента вместо от страна на сървъра.

Използвайте изгледи на Dataverse, когато е възможно. Изглед с необходимите критерии за присъединяване или филтриране помага за намаляване на режийните разходи при използване на цяла таблица. Например, ако трябва да се присъедините към таблици и да филтрирате данните им, можете да дефинирате изглед като се присъедините към тях и дефинирате само колоните, които ви трябват. След това използвайте този изглед във вашето приложение, който създава тези режийни от страната на сървъра за операцията за присъединяване/филтър вместо от страна на клиента.Този метод намалява не само допълнителните операции, но и предаването на данни. За информация относно редактирането на филтъра и критериите за сортиране отидете наРедактиране на критериите за филтриране.

Съображения за производителност при използване на съединителя на Excel

Конекторът на Excel осигурява свързаност от приложение за платно с данни в таблица във файл на Excel. Този конектор има ограничения в сравнение с други източници на данни, например ограничени делегируеми функции, които ограничават приложението на платното да зарежда данни от таблицата само до 2000 записа. За да заредите повече от 2000 записа, разпределете данните си в различни таблици с данни като други източници на данни.

Нека да разгледаме често срещаните проблеми с производителността, когато се използва Excel за източник на данни за приложения за платно, и как да ги разрешите.

Твърде много таблици с данни и голям размер на данните

Дадено приложение може да работи твърде бавно, когато използва файл на Excel с твърде много таблици с данни или таблици с огромни размери на данни в няколко колони. Файл на Excel не е релационна база данни или източник на данни, която предоставя делегируеми функции. Power Apps трябва първо да зареди данни от дефинираните таблици с данни и след това да използва функции като Филтър, Сортиране, ПРИСЪЕДИНЯВАНЕ, Групиране по и Търсене.

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

За да сте сигурни, че приложението ви няма да бъде засегнато от този проблем, дефинирайте само необходимите колони в таблицата с данни във файл на Excel.

Тежки трансакции

Excel не е релационна система от бази данни. Всички промени от приложение се управляват от Excel по същия начин, както потребителят променя данните във файл на Excel. Ако приложението има голям брой четения, но по-малко CRUD операции, може да се представи добре. Ако обаче приложението извършва тежки транзакции, това може да повлияе неблагоприятно на производителността на приложението.

Няма конкретна прагова стойност за броя транзакции, тъй като тя също зависи от данните, които се манипулират. Няколко други аспекта също оказват влияние върху производителността на приложението, като например мрежовите разходи или устройството на потребителя.

Ако имате данни само за четене, можете да импортирате такива данни в приложението локално, вместо да ги зареждате от източник на данни. За корпоративни приложения използвайте източници на данни като Dataverse, SQL Server или SharePoint вместо това.

Размер на файл

Можете да избирате от широка гама от опции за съхранение в облака с различен или конфигурируем капацитет за съхранение на файла на Excel. Въпреки това, един голям файл на Excel с всички таблици, дефинирани в един файл, добавя допълнителни режийни разходи за приложението, докато изтегля файла и чете данните за зареждане от страна на клиента.

Вместо да използвате един голям файл, разделете данните на множество файлове на Excel с минимални таблици с данни. След това се свържете с всеки файл само когато имате нужда от него. По този начин зареждането на данните от таблицата с данни става на фрагменти, намалявайки режийните разходи на много таблици или голям набор от данни.

Местонахождение на файла

Географско местоположение на източник на данни и разстоянието от клиентски местоположения може да доведе до общо ограничение на производителността на приложението и да предизвика латентност на мрежата. Този ефект може да се усили при мобилен клиент с ограничена честотна лента за свързаност.

По-добре е да държите файла близо до крайните потребители (или повечето от потребители, ако имате глобална аудитория), така че файлът да може да бъде изтеглен бързо.

Следващи стъпки

Съвети и най-добри практики за подобряване на производителността на приложението за платно

Вижте също

Разбиране на фазите на изпълнение на приложения за платно и поток от обаждания за данни
Често срещани източници на бавна производителност за приложение за платно
Общи проблеми и решения за Power Apps
Отстраняване на проблеми при стартиране за Power Apps

Бележка

Можете ли да ни споделите повече за езиковите си предпочитания за документацията? Попълнете кратко проучване. (имайте предвид, че това проучване е на английски език)

Проучването ще отнеме около седем минути. Не се събират лични данни (декларация за поверителност).