Распространенные проблемы с производительностью приложений на основе холста и способы их решения

Вы можете создавать приложения на основе холста, используя различные массивы источников данных. Выберите источник данных и соединитель на основе бизнес-потребностей и сценариев, для которых создается приложение. Для корпоративных приложений рекомендуется использовать источник данных Microsoft Dataverse, поскольку это дает несколько преимуществ в производительности. Для приложений с несколькими транзакциями вы можете использовать любые другие доступные источники данных в вашей среде.

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

В этой статье вы узнаете о некоторых из наиболее распространенных проблем с производительностью, из-за которых приложения на основе холста могут работать медленно, и о том, как их решить. Эта информация поможет вам улучшить производительность приложения с учетом вашего бизнес-плана и роста.

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

Прежде чем начать, убедитесь, что вы понимаете фазы выполнения приложения на основе холста и поток вызовов данных. Также обзнакомьтесь с разделом Распространенные источники низкой производительности приложения на основе холста, чтобы узнать общие ошибки, которых можно избежать при разработке или обновлении приложений на основе холста.

Медленная загрузка больших наборов данных на разных платформах

Производительность приложения может отличаться при загрузке больших наборов данных на разных платформах, таких как iOS или Android. Это изменение происходит из-за различных ограничений сетевых запросов на каждой платформе. Например, количество разрешенных одновременных сетевых запросов может отличаться в зависимости от платформы. Эта разница может существенно повлиять на время загрузки данных для больших наборов данных.

Мы рекомендуем загружать только те данные, которые необходимы для немедленного отображения на экране. Для других данных разбейте их на страницы и кэшируйте ваши данные. Дополнительная информация: Советы и рекомендации по повышению производительности приложений на основе холста

Получено слишком много столбцов

Рекомендуется выбирать только столбцы, необходимые для приложения. При добавлении дополнительных (или всех) столбцов из источника данных загружаются все данные в этих столбцах. Это действие приводит к большому количеству сетевых служебных вызовов и, следовательно, к высокому использованию памяти на клиентском устройстве. Эта проблема может еще больше повлиять на пользователей мобильных устройств, если пропускная способность сети ограничена, или если у устройства ограниченная память, или устаревший процессор.

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

Чтобы включить функцию явного выбора столбца в приложении на основе холста, перейдите в Настройки>Предстоящие функции>Предварительная версия, а затем включите Явный выбор столбца.

Неподдерживаемые или устаревшие браузеры

Пользователи, использующие неподдерживаемые или устаревшие браузеры, могут столкнуться с проблемами производительности. Убедитесь, что пользователи используют только поддерживаемые браузеры для запуска приложений на основе холста.

Низкая производительность из-за географического расстояния

Географическое положение среды и расстояние от источника данных до пользователей может влиять на производительность.

Мы рекомендуем располагать вашу среду поблизости от пользователей. Хотя Power Apps использует сеть доставки содержимого Azure для содержимого, вызовы данных по-прежнему получают данные из источника данных. Источник данных, расположенный в другом географическом месте, может негативно повлиять на производительность приложения.

Слишком большое расстояние от географического местоположения влияет на производительность различными способами, такими как задержка, снижение пропускной способности, более узкая полоса пропускания или потеря пакетов.

Список разрешений не настроен

Убедитесь, что требуемые 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 (локальная версия) или базе данных SQL Azure. В этом разделе описаны распространенные проблемы, связанные с производительностью, и способы их решения при использовании этого соединителя для приложения на основе холста.

Заметка

Хотя в этом разделе упоминается соединитель SQL Server для проблем с производительностью и их решения, большинство рекомендаций также применимы при использовании любого типа базы данных — например, MySQL или PostgreSQL — в качестве источника данных.

Давайте посмотрим на распространенные проблемы с производительностью и их решения при использовании соединителя SQL Server для приложений на основе холста.

Запрос "многие к одному" (N+1)

Коллекции, создающие слишком много запросов к серверам, вызывают проблемы с запросами N+1. Проблема запроса N+1 — одна из наиболее часто встречающихся проблем при использовании элемента управления Галерея.

Чтобы избежать этой проблемы, используйте объекты представления в серверной части SQL или измените сценарии пользовательского интерфейса.

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

Приложение может замедлиться, если функции, используемые приложением, выполняют запросы в базе данных, которые приводят к сканированию таблицы вместо поиска по индексу. Больше информации: Подсказки, сканирование таблицы и поиск по индексу

Для решения таких проблем используйте StartsWith вместо IN в формуле. При использовании источника данных SQL оператор StartsWith приводит к поиску по индексу,а оператор IN приводит к сканированию индекса или таблицы.

Медленные запросы

Вы можете профилировать и настраивать медленные запросы и индексы в базе данных SQL. Например, если формула получает определенные данные в порядке убывания (DESC) в определенном столбце, у этого столбца сортировки должен быть индекс с порядком убывания. Ключ индекса по умолчанию создает порядок возрастания (ASC).

Вы также можете проверить URL-адрес запросов данных. Например, следующий запрос данных фрагмент кода (частичный вызов OData) просит SQL вернуть 500 записей соответствующего столбца для Значение и упорядочить по ID в порядке убывания.

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

Это помогает понять требования к индексу для покрытия аналогичных условий запроса. В этом примере если у столбца ID есть индекс в порядке убывания, запрос будет выполнен быстрее.

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

Дополнительные сведения:

• Контроль и настройка производительности
• Мониторинг производительности с использованием хранилища запросов
• Обзор расширенных событий

Конфликт за ресурсы базы данных

Убедитесь, что у источника данных — базы данных SQL — нет конфликтов ресурсов, таких как узкие места процессора, конкуренция ввода-вывода, нехватка памяти или конфликт tempDB. Также проверьте блокировки, ожидания, взаимоблокировки и таймауты запросов.

Совет

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

Большой клиент или чрезмерные запросы

Приложение, выполняющее операции Группировать по, Фильтровать по или JOIN на стороне клиента, использует ресурсы процессора и памяти клиентских устройств. В зависимости от размера данных эти операции могут занять больше времени на выполнение сценариев на стороне клиента, увеличивая размер кучи JS в клиенте. Эта проблема возрастает для локального источника данных, поскольку каждый вызов данных поиска направляется в источник данных через шлюз данных.

В таких ситуациях используйте объект Представление в базе данных SQL для операций Группировка по, Фильтровать по или JOIN. Представления могут использовать выборочные столбцы и удалять ненужные столбцы с большими типами данных, такими как NVARCHAR(MAX), VARCHAR(MAX) и VARBINARY(MAX).

Совет

Этот подход также помогает решить проблему с запросом N+1.

Размер данных, переданных клиенту

По умолчанию приложение на основе холста показывает данные с помощью таблиц или представлений из доступных объектов базы данных. Получение всех столбцов из таблицы может привести к медленному отклику, особенно при использовании больших типов данных, таких как NVARCHAR(MAX).

Передача больших объемов данных клиентам требует времени. Эта передача также приводит к увеличению времени выполнения сценариев, когда в куче JS на стороне клиента есть большие объемы данных, как описано ранее в этой статье.

Чтобы уменьшить размер данных, передаваемых клиенту, используйте представления с определенными столбцами, необходимыми для приложения, и убедитесь, что включен явный выбор столбцов, как описано ранее в этой статье.

Особенности SQL Server (локальная версия)

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

Неработоспособный локальный шлюз данных

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

Убедитесь, что все узлы локального шлюза данных исправны и настроены с минимальной сетевой задержкой между узлами и экземпляром SQL.

Расположение локального шлюза данных

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

В корпоративной среде рекомендуется использовать масштабируемый кластер шлюза данных, когда ожидаются большие запросы данных. Проверьте, сколько соединений установлено между узлами шлюза данных и экземпляром SQL.

Проверяя одновременные соединения на локальном шлюзе данных или в экземпляре SQL, ваша организация может определить, в какой момент необходимо масштабировать шлюз данных и с каким количеством узлов.

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

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

Одного узла локального шлюза данных может быть достаточно для работы с 200 или менее одновременными подключениями. Однако, если все эти одновременные подключения активно выполняют запросы, другие запросы в конечном итоге ожидают доступного подключения.

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

Особенности базы данных SQL Azure

Приложения на основе холста могут подключаться к базе данных SQL Azure с помощью соединителя SQL Server. Распространенной причиной проблем с производительностью при использовании базы данных SQL Azure является выбор неправильного уровня для ваших бизнес-требований.

База данных SQL Azure доступна на разных уровнях обслуживания с различными возможностями для соответствия различным бизнес-требованиям. Для получения дополнительной информации об уровнях перейдите к Документация по базе данных SQL Azure.

При тяжелых запросах данных ресурсы на выбранном уровне могут быть ограничены сразу после достижения порогового значения. Такое регулирование количества запросов снижает производительность следующего набора запросов.

Проверьте уровень служб базы данных SQL Azure. У более низкого уровня будут некоторые ограничения. С точки зрения производительности важны ЦП, производительность ввода-вывода и задержка. Следовательно, рекомендуется периодически проверять производительность базы данных SQL и проверять, не превышает ли использование ресурсов пороговое значение. Например, локальный SQL Server обычно устанавливает порог использования ЦП примерно на 75процентов.

Вопросы производительности для соединителя SharePoint

Вы можете использовать соединитель SharePoint для создания приложений с использованием данных из Microsoft Списки. Вы также можете создавать приложения на основе холста прямо из представления списка. Давайте посмотрим на распространенные проблемы с производительностью и их решения для использования источника данных SharePoint с приложениями на основе холста.

Слишком много столбцов динамического поиска

SharePoint поддерживает различные типы данных, включая динамический поиск, такой как Человек, Группа и Вычислено. Если список определяет слишком много динамических столбцов, требуется больше времени, чтобы управлять этими динамическими столбцами в SharePoint перед возвратом данных клиенту, запускающему приложение на основе холста.

Не злоупотребляйте столбцами динамического поиска в SharePoint. Это чрезмерное использование может привести к дополнительным накладным расходам на стороне SharePoint для манипулирования данными, которых можно избежать. Вместо этого вы можете использовать статические столбцы для хранения псевдонимов электронной почты или имен людей, например.

Столбец с изображениями и вложение

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

Просмотрите свой список и убедитесь, что определены только необходимые столбцы. Количество столбцов в списке влияет на производительность запросов данных. Это возникает из-за сопоставленных записей или из-за того, что записи до определенных ограничений строки данных извлекаются и передаются обратно клиенту со всеми столбцами, определенными в списке — даже если приложение не использует все из них.

Чтобы запрашивать только столбцы, используемые приложением, включите функцию явного выбора столбцов, как описано ранее в этой статье.

Большие списки

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

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

В контролируемой среде тест производительности показал, что производительность запросов OData к Microsoft Списки или SharePoint сильно зависит от количества столбцов в списке и количества извлекаемых строк (ограничено лимитом строк данных для неделегируемых запросов). Меньшее количество столбцов и более низкая настройка ограничения строк данных могут улучшить работу приложения на основе холста.

Однако в реальном мире приложения предназначены для удовлетворения определенных бизнес-требований. Может оказаться непросто и небыстро снизить ограничение строк данных или количество столбцов в списке. Однако рекомендуется отслеживать запросы OData на стороне клиента и настраивать ограничение строк данных для неделегируемых запросов и количество столбцов в списке.

Вопросы производительности для использования соединителя Dataverse как источника данных

При использовании Microsoft Dataverse в качестве источника данных запросы данных передаются в экземпляр среды напрямую, без прохождения через управление API Azure. Дополнительная информация: Поток вызова данных при подключении к Microsoft Dataverse

Совет

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

Приложение на основе холста, подключенное к Dataverse, может работать медленно, если оно запускает тяжелые клиентские сценарии, такие как Фильтровать по или JOIN, на стороне клиента, а не на стороне сервера.

Используйте представления Dataverse, когда возможно. Представление с требуемыми критериями объединения или фильтрации помогает снизить накладные расходы на использование всей таблицы. Например, если необходимо соединить таблицы и отфильтровать их данные, можно определить представление, присоединив их и определив только нужные столбцы. Затем можно использовать это представление в своем приложении, которое создает эти нагрузки на стороне сервера для операции объединения или фильтрации, а не на стороне клиента. Этот метод сокращает не только лишние операции, но и передачу данных. Для получения информации о редактировании критериев фильтрации и сортировки см. Изменение условий фильтра.

Вопросы производительности для соединителя Excel

Соединитель Excel обеспечивает связь приложения на основе холста с данными в таблице в файле Excel. У этого соединителя есть ограничения по сравнению с другими источниками данных — например, ограниченные делегируемые функции — что накладывает на приложение на основе холста ограничение, позволяющее загружать данные из таблицы только до 2000 записей. Чтобы загрузить более 2000 записей, разделите данные в разных таблицах данных как другие источники данных.

Давайте посмотрим на распространенные проблемы с производительностью и их решения при использовании Excel как источника данных для приложений на основе холста.

Слишком много таблиц данных и большой размер данных

Приложение может работать медленно, когда оно использует файл Excel со слишком большим количеством таблиц данных или таблицы данных, содержащих огромное количество данных в нескольких столбцах. Файл Excel не является реляционной базой данных или источником данных, который предоставляет делегируемые функции. Power Apps должно сначала загрузить данные из определенных таблиц данных, а затем использовать такие функции, как Filter, Sort, JOIN, Group By и Search.

Слишком много таблиц данных с большим количеством строк и столбцов влияет на производительность приложения и накладную нагрузку на стороне клиента, потому что каждой таблицей данных необходимо управлять в пределах кучи JS. Этот также приводит к тому, что приложение потребляет больше памяти на стороне клиента.

Чтобы убедиться, что на ваше приложение не влияет эта проблема, определите только необходимые столбцы в таблице данных в файле Excel.

Тяжелые транзакции

Excel — это не система реляционных баз данных. Excel управляет любыми изменениями в приложении так же, как если бы пользователь изменял данные в файле Excel. Если для приложения есть большое количество чтений, но меньше операций CRUD, оно может работать хорошо. Однако, если приложение выполняет тяжелые транзакции, это может отрицательно сказаться на его производительности.

Не существует определенного порогового значения для количества транзакций, поскольку это также зависит от данных, которыми управляют. Несколько других аспектов также влияют на производительность приложения, например накладные нагрузки сети или устройство пользователя.

Если у вас есть данные только для чтения, вы можете импортировать такие данные в приложение локально, а не загружать их из источника данных. Вместо этого для корпоративных приложений используйте такие источники данных, как Dataverse, SQL Server или SharePoint.

Размер файла

Вы можете выбирать из широкого спектра вариантов облачного хранилища с изменяющимся — или настраиваемым — объемом памяти для файла Excel. Однако один большой файл Excel со всеми таблицами, определенными в этом файле, добавляет дополнительные накладные нагрузки для приложения при загрузке файла и чтении данных для загрузки на стороне клиента.

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

Расположение файла

Географическое положение источника данных и расстояние от расположений клиентов может привести к возникновению проблем с производительностью приложения и вызвать задержку в сети. Этот эффект может быть усилен мобильным клиентом, имеющим ограниченную полосу пропускания для подключения.

Лучше хранить файл рядом с вашими пользователями (или большинством пользователей, если у вас глобальная аудитория), чтобы файл можно было быстро загрузить.

Дальнейшие шаги

Советы и рекомендации по повышению производительности приложений на основе холста

См. также

Общие сведения о потоке вызовов данных и этапах выполнения приложения на основе холста
Распространенные причины низкой производительности приложения на основе холста
Распространенные проблемы и способы их решения для Power Apps
Устранение неполадок при запуске для Power Apps