Problèmes de performance courants et solutions pour les applications canevas

Vous pouvez créer des applications canevas en utilisant diverses options de sources de données. Choisissez la bonne source de données et un connecteur en fonction des besoins de l’entreprise et des scénarios pour lesquels l’application est conçue. Pour les applications d’entreprise, Microsoft Dataverse est le source de données recommandée car il présente plusieurs avantages en termes de performances. Pour les applications avec peu de transactions, vous pouvez utiliser toutes les autres sources de données disponibles dans votre environnement.

Pour des considérations de performances d’une application, pensez au nombre d’utilisateurs qui utiliseront l’application une fois qu’elle aura été publiée ; le volume des transactions de création, de récupération, de mise à jour et de suppression (CRUD) ; le type d’interactions avec les données ; l’accès géographique ; et les types d’appareils dont disposent les utilisateurs.

Dans cet article, vous découvrirez certains des problèmes de performances les plus courants qui peuvent ralentir l’exécution des applications canevas et comment les résoudre. Ces informations vous aideront à améliorer les performances de l’application en gardant à l’esprit votre plan d’affaires et votre croissance.

Nous allons commencer par certains problèmes de performances courants qui se produisent quel que soit le connecteur utilisé. Dans les sections suivantes, vous découvrirez les problèmes de performances et les solutions plus spécifiques aux divers connecteurs.

Avant de commencer, assurez-vous que vous comprenez les phases d’exécution des applications canevas et le flux d’appels de données. De plus, lisez les sources communes des performances lentes d’une application caneva pour identifier les pièges courants que vous pouvez éviter lors de la conception ou de la mise à jour des applications canevas.

Le chargement de grands ensembles de données est plus ou moins lent selon les plates-formes

Les performances d’une application peuvent varier lors du chargement de grands ensembles de données selon les plateformes, comme iOS ou Android. Cette variation est due aux différentes limitations de demande réseau pour chaque plate-forme. Par exemple, le nombre de demandes réseau simultanées autorisées peut être différent par plateforme. Cette différence peut avoir un impact majeur sur le temps de chargement des données pour les grands ensembles de données.

Nous vous recommandons de ne charger que les données dont vous avez besoin pour afficher immédiatement à l’écran. Pour les autres données, paginez et mettez en cache vos données. Pour plus d’informations : Conseils et pratiques recommandées pour améliorer les performances des applications canevas

Trop de colonnes récupérées

Nous vous recommandons de sélectionner uniquement les colonnes nécessaires pour l’application. L’ajout de plus de colonnes (ou de toutes) les colonnes de la source de données télécharge toutes les données des colonnes. Cette action entraîne un nombre élevé d’appels et surcharge le réseau, et donc entraîne une utilisation élevée de la mémoire dans le périphérique client. Ce problème peut avoir un impact encore plus important sur les utilisateurs d’appareils mobiles si la bande passante du réseau est limitée, ou si un appareil a une mémoire limitée ou un processeur hérité.

Par exemple, si vous utilisez Dataverse en tant que source de données pour votre application, assurez-vous que vous avez activé la fonctionnalité Sélection de colonne explicite. Cette fonctionnalité permet à Power Apps de restreindre la récupération des données uniquement aux colonnes utilisées dans l’application.

Pour activer la fonction de sélection de colonne explicite sur l’application canevas, accédez à Paramètres > Fonctionnalités à venir > Aperçu, puis activez le bouton à bascule Sélection de colonne explicite.

Versions de navigateur non prises en charge ou héritées

Les utilisateurs qui utilisent des navigateurs non pris en charge ou hérités peuvent rencontrer des problèmes de performances. Assurez-vous que les utilisateurs utilisent uniquement les navigateurs pris en charge pour exécuter des applications canevas.

Performances lentes en raison de la distance géographique

L’emplacement géographique de l’environnement et la distance entre la source de données et les utilisateurs peuvent avoir un impact sur les performances.

Nous vous recommandons de placer votre environnement à proximité des utilisateurs. Bien que Power Apps utilise le réseau de diffusion de contenu Azure, les appels de données obtiennent toujours les données de la source de données. Une source de données située dans un autre emplacement géographique pourrait avoir un impact négatif sur les performances de l’application.

Une distance géographique excessive affecte les performances de différentes manières, telles que la latence, un débit réduit, une bande passante plus faible ou une perte de paquets.

Liste d’autorisation non configurée

Assurez-vous que les URL de service requises n’ont pas été bloquées ou qu’elles ont été ajoutées à la liste d’autorisation de votre pare-feu. Pour obtenir la liste complète de toutes les URL de service qu’il faut autoriser pour Power Apps, allez à Services requis.

Utilisation de fonctions non supprimables et limite de ligne de données inappropriée pour les requêtes non délégables

Les fonctions délégables délèguent le traitement des données au niveau de la source de données, minimisant la surcharge côté client. Lorsque la délégation n’est pas possible, vous pouvez limiter les lignes de données pour les requêtes non délégables afin que le nombre de lignes renvoyées par une connexion serveur reste optimal.

L’utilisation de fonctions non délégables et une limite de ligne de données pour les requêtes non délégables inappropriée augmentent le coût du transfert de données. Cette surcharge entraîne une manipulation des données reçues par la mémoire Heap JS côté client. Assurez-vous d’utiliser des fonctions délégables pour l’application chaque fois qu’elles sont disponibles, et la limite optimale de lignes de données pour les requêtes non délégables.

Pour plus d’informations : Utilisation d’une délégation, Vue d’ensemble de la délégation

L’événement OnStart doit être activé

L’événement OnStart s’exécute lors du chargement de l’application. L’appel de grandes quantités de données à l’aide des fonctions dans la propriété OnStart de l’application entraînera le chargement lent de l’application. Un écran fortement dépendant des commandes et des valeurs définies sur un autre écran sera affecté par une navigation lente.

Les sections suivantes décrivent certains des problèmes les plus courants rencontrés dans ces situations.

Nombre élevé d’appels dans l’événement OnStart entraînant un démarrage lent de l’application

Dans une entreprise, le volume d’appels de données vers un source de données centrale peut entraîner un goulot d’étranglement du serveur ou un conflit de ressources.

Utilisez un mécanisme de mise en cache pour optimiser les appels de données. Une seule application peut être utilisée par de nombreux utilisateurs, par conséquent, plusieurs appels de données par utilisateur atteignent les points de terminaison du serveur. Ces appels de données peuvent créer un goulot d’étranglement entraînant des limitations.

Latence sur l’événement OnStart en raison de scripts lourds

Les scripts lourds lors de l’événement OnStart sont l’une des erreurs les plus courantes lors de la conception d’applications canevas. Vous ne devez obtenir que les données au démarrage de l’application.

Optimisez la formule dans un événement OnStart. Par exemple, vous pouvez déplacer certaines fonctions vers la propriété OnVisible. De cette façon, vous pouvez laisser l’application démarrer rapidement et d’autres étapes peuvent se poursuivre pendant son ouverture.

Pour plus d’informations : Optimiser la propriété OnStart

Pression sur la mémoire côté client

Il est important de contrôler la consommation de la mémoire d’une application canevas, car la plupart du temps, l’application s’exécute sur des appareils mobiles. Les exceptions de mémoire dans la mémoire Heap sont la cause la plus probable d’une application canevas qui plante ou se bloque sur certains appareils.

La mémoire Heap JavaScript (JS) peut être saturée en raison de scripts lourds exécutés côté client suite à l’ajout de colonnes, d’une jonction, d’un filtrage, d’un tri ou d’un regroupement. Dans la plupart des cas, une exception de mémoire insuffisante au niveau de la mémoire Heap côté client peut déclencher le blocage ou le plantage de l’application.

Lors de l’utilisation de données provenant de sources telles que Dataverse ou SQL Server, vous pouvez utiliser un objet Vue pour garantir que la jonction, le filtrage, le regroupement ou le tri se produit côté serveur au lieu de côté client. Cette approche réduit la surcharge de script côté client pour de telles actions.

Si des opérations lourdes côté client telles que JOIN ou Regrouper par se sont produites côté client avec un jeu de données de 2000 enregistrements ou plus, les objets dans la mémoire Heap augmenteront, ce qui dépassera les limites de la mémoire.

Les outils de développement de la plupart des navigateurs vous permettent de profiler la mémoire. Ils permettent de visualiser la taille de la mémoire Heap, les documents, les nœuds et les écouteurs. Profil des performances de l’application à l’aide d’un navigateur, comme décrit dans Présentation des outils de développement Microsoft Edge (Chromium). Vérifiez les scénarios qui dépassent le seuil de mémoire du tas JS. Pour plus d’informations : Résoudre les problèmes de mémoire

Considérations relatives aux performances pour le connecteur SQL Server

Vous pouvez utiliser le Connecteur SQL Server pour Power Apps pour vous connecter à SQL Server localement ou à Azure SQL Database. Cette section décrit les problèmes courants liés aux performances et les résolutions pour l’utilisation de ce connecteur pour une application canevas. Pour plus d’informations : Se connecter à SQL Server à partir de Power Apps, Créer une application canevas à partir d’Azure SQL Database

Jetons un coup d’œil aux problèmes de performances courants et aux solutions possibles pour l’utilisation du connecteur SQL Server pour les applications canevas.

Requête N+1

Les galeries qui générent trop de requêtes aux serveurs provoquent des problèmes de requêtes N+1. Le problème de requête N+1 est l’un des problèmes les plus fréquemment rencontrés lors de l’utilisation du contrôle Galerie.

Pour éviter le problème, utilisez voir les objets dans le backend SQL ou modifiez les scénarios d’interface utilisateur.

Balayage de table au lieu de recherche d’index

Une application pourrait être ralentie si les fonctions qu’elle utilise exécutent des requêtes dans la base de données, entraînant des analyses de table au lieu d’une recherche d’index. Pour plus d’informations : Conseils, analyse de table (SCAN) et recherche d’index (SEEK)

Pour résoudre ces problèmes, utilisez StartsWith au lieu de IN dans la formule. Lorsque vous utilisez une source de données SQL, l’opérateur StartsWith entraîne une recherche d’index, tandis que l’opérateur IN entraîne une analyse d’index ou de table.

Requêtes lentes

Vous pouvez profiler et ajuster les requêtes et index lents sur la base de données SQL. Par exemple, s’il existe une formule obtenant des données dans un ordre décroissant (DESC) sur une certaine colonne, cette colonne de tri doit avoir un index avec un ordre décroissant. La clé d’index crée un ordre croissant (ASC) par défaut.

Vous pouvez également vérifier l’adresse URL des requêtes de données. Par exemple, l’extrait de demande de données suivant (appel OData partiel) demande à SQL de renvoyer 500 enregistrements mettant en correspondance les colonnes Valeur et ID par ordre décroissant.

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

Cela permet de comprendre les exigences d’index pour répondre aux conditions de la demande. Dans cet exemple, la colonne ID a un index avec un ordre décroissant pour exécuter la requête plus rapidement.

Vérifiez le plan d’exécution des requêtes lentes pour voir s’il existe une analyse de table ou d’index. Surveillez les coûts excessifs de la recherche de clé dans le plan d’exécution.

Pour plus d’informations :

• Surveiller et ajuster les performances
• Surveillance des performances à l’aide du magasin des requêtes
• Aperçu des événements étendus

Conflit de ressources de base de données

Assurez-vous que la source de donnéesla base de données—SQL database—n’a pas de conflits de ressources de type goulot d’étranglement du processeur, de conflits d’E/S, de pression au niveau de la mémoire ou de conflit tempDB. Vérifiez également les délais d’expiration, de verrouillage, d’attente et de blocage des requêtes.

Client lourd ou demandes excessives

Une application exécutant des opérations Regrouper par, Filtrer par ou JOIN côté client utilise le processeur et les ressources de mémoire des machines clientes. Selon la taille des données, ces opérations pourraient prendre plus de temps de script côté client, ce qui augmente la taille de la mémoire Heap JS côté client. Ce problème s’amplifie pour une source de données locale, puisque chaque appel de recherche de données bascule sur la source de données via la passerelle de données.

Dans de telles situations, utilisez l’objet Vue dans la base de données SQL pour les opérations Regrouper par, Filtrer par ou JOIN. Les vues peuvent utiliser des colonnes sélectives et supprimer les colonnes inutiles avec des types de Big Data tels que NVARCHAR(MAX), VARCHAR(MAX) et VARBINARY(MAX).

Taille des données transférées au client

Par défaut, une application canevas affiche les données à l’aide des tables ou des vues des objets de base de données disponibles. La récupération de toutes les colonnes d’une table peut entraîner une réponse lente, en particulier lors de l’utilisation de types de données volumineuses tels que NVARCHAR(MAX).

Le transfert de grandes quantités de données aux clients prend du temps. Ce transfert entraîne également plus de temps de script lorsqu’il y a de grandes quantités de données dans le tas JS côté client, car décrit plus haut dans cet article.

Pour réduire la taille des données transférées vers le client, utilisez des vues avec les colonnes spécifiques requises pour l’application et assurez-vous que la sélection de colonne explicite est activée, comme décrit plus haut dans cet article.

Considérations spécifiques à SQL Server local

Les performances d’une application canevas utilisant le connecteur SQL Server avec une passerelle de données locale pourraient être affectées de différentes manières. Cette section répertorie les problèmes de performances courants et les solutions spécifiques à l’utilisation d’une source de base de données locale.

Passerelle de données locale non saine

Les organisations peuvent définir plusieurs nœuds pour les passerelles de données locales. Même si un seul des nœuds est inaccessible, les demandes de données sur le nœud défectueux ne renverront pas le résultat dans un délai d’exécution décent, ou généreraient des messages d’erreur "inaccessibles" après un certain temps.

Assurez-vous que tous les nœuds de la passerelle de données locale sont sains et configurés avec une latence réseau minimale entre les nœuds et l’instance SQL.

Emplacement de la passerelle de données locale

Une passerelle de données nécessite des appels réseau aux sources de données locales pour interpréter les requêtes OData. Par exemple, la passerelle de données doit comprendre le schéma de la table de données pour traduire les requêtes OData en instructions de langage de manipulation de données (DML) SQL. Une surcharge supplémentaire est ajoutée lorsque la passerelle de données est configurée dans un emplacement distinct avec une latence réseau élevée entre la passerelle de données et l’instance SQL.

Dans un environnement d’entreprise, il est recommandé de disposer d’un cluster de passerelle de données évolutif lorsque des demandes de données importantes sont attendues. Vérifiez le nombre de connexions établies entre les nœuds de passerelle de données et l’instance SQL.

En vérifiant les connexions simultanées dans une passerelle de données locale ou dans un serveur SQL, votre organisation peut identifier le moment où la passerelle de données doit évoluer et avec combien de nœuds.

Évolutivité de la passerelle de données locale

Si vous prévoyez d’accéder à un grand volume de données depuis la passerelle de données locale, un seul nœud peut créer un goulot d’étranglement dans la tentative de couvrir un tel volume de requêtes.

Un seul nœud de la passerelle de données locale pourrait être suffisant pour gérer 200 connexions simultanées ou moins. En revanche, si toutes ces connexions simultanées exécutent des requêtes de manière active, d’autres requêtes devront attendre une connexion disponible.

Pour plus d’informations sur la manière de vous assurer que votre passerelle de données locale évolue en fonction du volume de données et de demandes, accédez à Surveiller et optimiser les performances de la passerelle de données locale.

Considérations spécifiques à Azure SQL Database

Les applications canevas peuvent se connecter à Azure SQL Database à l’aide du connecteur SQL Server. Une cause fréquente de problèmes de performances lors de l’utilisation d’Azure SQL Database est la sélection du mauvais niveau pour les besoins de votre entreprise.

Azure SQL Database est disponible dans différents niveaux de service, avec des fonctionnalités variées pour répondre aux différentes exigences de l’entreprise. Pour plus d’informations sur les niveaux, consultez Documentation de Azure SQL Database.

En cas de requêtes de données lourdes, les ressources du niveau que vous sélectionnez pourraient être limitées une fois que la valeur de seuil est atteinte. Une telle limitation de requêtes compromet les performances du prochain ensemble de requêtes.

Vérifiez le niveau de service d’Azure SQL Database. Le niveau inférieur comportera certaines limites et contraintes. Du point de vue des performances, le processeur, le débit d’E/S et la latence sont importants. Par conséquent, nous vous recommandons de vérifier régulièrement les performances de la base de données SQL et si l’utilisation des ressources dépasse le seuil. Par exemple, SQL Server local définit normalement le seuil d’utilisation du processeur à environ 75 .

Considérations relatives aux performances pour le connecteur SharePoint

Vous pouvez utiliser le connecteur SharePoint pour créer des applications en utilisant les données des listes Microsoft. Vous pouvez également créer des applications canevas directement à partir de la vue de liste. Jetons un coup d’œil aux problèmes de performances courants et aux solutions possibles lors de l’utilisation d’une source de données SharePoint avec les applications canevas.

Trop de colonnes de recherche dynamique

SharePoint prend en charge divers types de donnéesy compris les recherches dynamiques telles que Personne, Groupe et Calculé. Si une liste définit trop de colonnes dynamiques, il faut plus de temps pour manipuler ces colonnes dynamiques dans SharePoint avant de renvoyer les données au client exécutant l’application canevas.

N’abusez pas des colonnes de recherche dynamique dans SharePoint. Cette surutilisation peut entraîner des frais généraux évitables et supplémentaires côté SharePoint pour la manipulation des données. Autrement, vous pouvez utiliser des colonnes statiques pour conserver les alias de messagerie ou les noms des personnes, par exemple.

Colonne d’image et de pièce jointe

La taille d’une image et le fichier joint peuvent être la cause d’une réponse lente lors de la récupération côté client.

Passez en revue votre liste et assurez-vous que seules les colonnes nécessaires ont été définies. Le nombre de colonnes de la liste affecte les performances des requêtes de données. Cela est dû aux enregistrements mis en correspondance : les enregistrements jusqu’aux limites de lignes de données définies sont récupérés et renvoyés au client avec toutes les colonnes définies dans la liste—même si l’application ne les utilise pas tous.

Pour interroger uniquement les colonnes utilisées par l’application, activez la fonctionnalité Sélection de colonne explicite comme décrit précédemment dans cet article pour interroger uniquement les colonnes utilisées par l’application.

Listes volumineuses

Si vous avez une longue liste avec des centaines de milliers d’enregistrements, envisagez de partitionner la liste ou divisez-la en plusieurs listes en fonction de paramètres tels que les catégories ou la date et l’heure.

Par exemple, vos données peuvent être stockées sur différentes listes sur une base annuelle ou mensuelle. Dans ce cas, vous pouvez concevoir l’application pour permettre à un utilisateur de sélectionner une fenêtre de temps pour récupérer les données dans cette plage.

Dans un environnement contrôlé, le benchmark des performances a prouvé que les performances des requêtes OData par rapport aux listes Microsoft ou SharePoint est fortement lié au nombre de colonnes dans la liste et au nombre de lignes récupérées (limité par la limite de lignes de données pour les requêtes non délégables). Un nombre inférieur de colonnes et un paramètre de limite de ligne de données inférieur peuvent améliorer les performances d’une application canevas.

Dans le monde réel cependant, les applications sont conçues pour répondre à des exigences professionnelles. Réduire la limite de lignes de données ou le nombre de colonnes dans une liste n’est pas toujours rapide ni simple. Cependant, nous vous recommandons de surveiller les requêtes OData côté client et d’ajuster la limite de ligne de données pour les requêtes non délégables et le nombre de colonnes dans la liste.

Considérations relatives aux performances pour l’utilisation de Dataverse en tant que source de données

Lorsque vous utilisez Microsoft Dataverse comme source de données, les demandes de données vont directement à l’instance d’environnement, sans passer par la Gestion des API Azure. Pour plus d’informations : Flux d’appels de données lors de la connexion à Microsoft Dataverse

Une application canevas connectée à Dataverse pourrait s’exécuter lentement si elle exécute des scripts lourds tels que Filtrer par ou Joindre côté client au lieu de côté serveur.

Utilisez les vues Dataverse quand c’est possible. Une vue avec les critères de jointure ou de filtre requis permet de réduire la surcharge liée à l’utilisation d’une table entière. Par exemple, si vous devez joindre des tables et filtrer leurs données, vous pouvez définir une vue en les joignant et en définissant uniquement les colonnes dont vous avez besoin. Ensuite vous pouvez utiliser cette vue dans votre application afin qu’elle soit traitée côté serveur pour la jointure/le filtrage et non côté client. Cette méthode réduit non seulement les opérations supplémentaires, mais également la transmission de données. Pour plus d’informations sur la modification des critères de filtre et de tri, accédez à Modifier les critères de filtre.

Considérations relatives aux performances pour le connecteur Excel

Le Connecteur Excel fournit la connectivité d’une application canevas aux données d’une table dans un fichier Excel. Ce connecteur présente des limites par rapport aux autres sources de donnéess—par exemple, les fonctions délégables—sont limitées ce qui permet à l’application canevas de charger les données depuis la table uniquement pour 2 000 enregistrements au maximum. Pour charger plus de 2 000 enregistrements, partitionnez vos données dans différentes tables de données sous la forme d’autres sources de données.

Jetons un coup d’œil aux problèmes de performances courants lors de l’utilisation d’une source de données Excel avec les applications canevas ainsi qu’aux solutions possibles.

Trop de tables de données et grands volumes de données

La lenteur de l’application peut être ressentie lorsqu’elle utilise un fichier Excel avec trop de tables de données, ou avec des tables de données contenant énormément de données sur plusieurs colonnes. Un fichier Excel n’est pas une base de données relationnelle ou une source de données qui fournit des fonctions délégables. Power Apps doit d’abord charger les données des tables de données définies, puis utiliser des fonctions telles que Filter, Sort, JOIN, Group By et Search.

Utiliser un trop grand nombre de tables de données, avec un nombre élevé de lignes et de colonnes, affecte les performances de l’application et la surcharge côté client car chaque table de données doit être manipulée dans la mémoire Heap JS. Cela conduit également l’application à consommer plus de mémoire côté client.

Pour vous assurer que votre application n’est pas affectée par de tels comportements, définissez uniquement les colonnes nécessaires sur la table de données dans un fichier Excel.

Transactions lourdes

Excel n’est pas un système de base de données relationnelle. Toutes les modifications d’une application sont gérées par Excel de la même manière qu’un utilisateur modifie les données dans un fichier Excel. Si l’application a un nombre élevé de lectures, mais moins d’opérations CRUD, elle peut fonctionner correctement. Cependant, si l’application effectue des transactions lourdes, cela peut nuire à ses performances.

Il n’y a pas de valeur de seuil spécifique pour le nombre de transactions, car cela concerne également les données manipulées. Plusieurs autres aspects ont également un impact sur les performances de l’application, tels que la surcharge du réseau ou l’appareil de l’utilisateur.

Si vous avez des données en lecture seule, vous pouvez importer ces données localement dans l’application au lieu de les charger à partir de la source de données. Pour les applications d’entreprise, utilisez plutôt des sources de données telles que Dataverse, SQL Server ou SharePoint.

Taille de fichier

Vous pouvez choisir parmi une large gamme d’options de stockage cloud avec une capacité variable—ou configurable—pour le fichier Excel. Cependant, s’il y a un seul grand fichier Excel avec toutes les tables définies, une surcharge supplémentaire sera ajoutée pour l’application lors du téléchargement du fichier et de la lecture des données à traiter côté client.

Au lieu d’utiliser un seul gros fichier, divisez les données en plusieurs fichiers Excel en réduisant au minimum les tables de données. Ensuite, connectez-vous à chaque fichier uniquement lorsque vous en avez besoin. De cette façon, le chargement des données à partir de la table se produit par fragments, ce qui réduit la surcharge due au traitement de nombreuses tables, ou de gros jeu de données.

Emplacement du fichier

L’emplacement géographique de la source de données et la proximité des emplacements des clients peuvent entraîner un goulot d’étranglement commun pour l’application et induire une latence du réseau. Cela risque d’être amplifié avec un client mobile avec une bande passante limitée au niveau de la connectivité.

Il est préférable que le fichier se trouve près de vos utilisateurs finaux (ou, de la plupart des utilisateurs finauxen cas de couverture mondiale) afin que le fichier puisse être téléchargé rapidement.

Étapes suivantes

Conseils et bonnes pratiques pour améliorer les performances des applications canevas

Voir aussi

Comprendre les phases d’exécution des applications canevas et le flux d’appel de données
Sources communes de performances lentes pour une application canevas
Problèmes courants et solutions pour Power Apps
Résolution des problèmes de démarrage de Power Apps