Optimisation des performances

8 minutes

Pour déterminer comment optimiser les performances de votre application, examinons d’abord ce qui se passe avec votre application lorsqu’elle démarre. Ensuite, nous pouvons discuter de certaines sources courantes de ralentissement des performances.

Phases d’exécution de l’application et flux d’appels de données

Avant même que votre utilisateur ne commence à interagir avec votre application, elle passe d’abord par certaines phases d’exécution. Ensuite, votre application effectue un flux d’appels de données qui varie en fonction de la source de données.

Phases d’exécution dans les applications canevas

Une application canevas passe par les phases d’exécution suivantes avant de présenter l’interface à un utilisateur :

Authentifier l’utilisateur : cette phase d’exécution invite les nouveaux utilisateurs à se connecter avec leurs informations d’identification pour la connexion de l’application. Selon les stratégies de sécurité de l’organisation, le même utilisateur peut y être invité à nouveau chaque fois qu’il rouvre l’application.
Obtenir les métadonnées : récupère les métadonnées telles que la version de la plateforme Power Apps sur laquelle l’application s’exécute, ainsi que les sources à partir desquelles les données doivent être récupérées.
Initialiser l’application : exécute les tâches spécifiées dans la propriété OnStart de l’application.
Afficher les écrans : affiche le premier écran de l’application, y compris les contrôles et les données présentées sur le premier écran. De même, l’application suit le même processus pour afficher tous les écrans suivants ouverts par l’utilisateur.

Flux d’appels de données dans les applications canevas

Les appels de données depuis les applications canevas envoient et reçoivent des données à l’aide du protocole OData. Dans de nombreux cas, l’appel de données va de l’application à Gestion des API Azure, de Gestion des API à la source de données, puis il doit revenir à l’application dans l’ordre inverse. En outre, s’il existe une source de données locale (telle qu’un SQL Server), l’appel doit également passer par une passerelle de données locale.

Toutes ces portes de flux d’appels peuvent entraîner des problèmes de performance et des opportunités potentielles d’optimisation. Cependant, il existe une différence significative dans l’appel de données si votre application utilise Microsoft Dataverse comme source de données. Lorsque votre appel de données accède à une source Dataverse, la requête OData accède directement à Dataverse, sans passer par Gestion des API Azure, des connecteurs ou des passerelles de données. Autrement dit, il y a moins de portes à franchir lorsque vous utilisez Dataverse.

Sources courantes de ralentissement des applications canevas

Maintenant que vous avez une compréhension de base des phases d’exécution et du flux d’appels de données, abordons certaines des sources les plus courantes de mauvaises performances dans les applications canevas.

Conception de l’application

La conception d’applications est un vaste domaine, car de nombreux moyens permettent de concevoir une application. Cependant, voici certains aspects qui peuvent certainement affecter les performances d’une application :

L’application est lourde pour le client. Autrement dit, elle obtient initialement de vastes jeux de données dans des collections de données, puis utilise les données dans plusieurs écrans sur des opérations lourdes pour le client telles que JSON, Sort, AddColumns et GroupBy.
L’application a une longue formule dans OnStart, où elle déclenche potentiellement de nombreux appels de données inutiles dans les écrans, et ceux-ci renvoient des enregistrements de données volumineux.

Pour examiner la conception de l’application en tant que source possible de ralentissement de ses performances, surveillez l’application à l’aide de Monitor. Identifiez les appels de données chronophages et le nombre d’appels de données déclenchant un tel comportement dans l’application.

Tentez également d’équilibrer la charge de travail entre le client et le serveur. La délégation de la charge de travail au serveur est recommandée dans la mesure du possible. Du point de vue de la consommation de mémoire client, il est important de rendre l’application client légère.

Goulot d’étranglement dans la source de données

Il existe de nombreuses causes possibles de goulots d’étranglement dans la source de données. Mais la plus courante est que les tables de la source de données sont au centre de l’activité lorsque de nombreuses requêtes transactionnelles ou non transactionnelles sont dirigées vers la même table ou le même enregistrement par différents utilisateurs.

Les appels OData peuvent ralentir si :

la machine principale hébergeant la source de données manque de ressources ;
l’instance SQL principale présente des blocages, des interblocages ou des conflits de ressources ;
la passerelle de données locale est non saine.

Lorsque ces problèmes surviennent, affinez la source de données principale pour éviter de ralentir les performances de l’application.

Navigateurs, appareils et emplacements client

Les applications canevas sont utilisables sur différents appareils, navigateurs et emplacements avec des conditions de réseau variables. Encouragez vos utilisateurs à utiliser des navigateurs modernes, mis à jour et pris en charge.

Emplacement géographique de la passerelle de données locale et de l’environnement

Les utilisateurs peuvent accéder aux applications canevas dans le monde entier. Cependant, nous vous recommandons de placer la source de données à proximité de votre principale base d’utilisateurs. Par exemple, lorsque votre application accède à votre source de données locale, l’emplacement de la passerelle de données locale doit être proche de la source de données afin de réduire toute surcharge supplémentaire entre la passerelle de données et la source de données.

Limitation temporaire des requêtes volumineuses dans le back-end

Selon la façon dont vous concevez une application canevas, elle peut générer de nombreux appels de données en peu de temps. Lorsque les appels de données dépassent les limitations d’un connecteur, l’application est soumise à une limitation temporaire. Le choix de la source de données et du connecteur appropriés est donc important à bien des égards et il est important de comprendre les limites propres au connecteur. Vous pouvez consulter la documentation sur les connecteurs pour en savoir plus sur leurs éventuelles limitations.

Activation du paramètre Déboguer l’application publiée

L’activation du paramètre Déboguer l’application publiée ralentit le fonctionnement de vos applications. Vous pouvez republier votre application avec ce paramètre désactivé lorsque vous déterminez que vous n’avez plus besoin d’afficher les expressions source lors du débogage de votre application publiée.

En résumé, nous avons maintenant discuté de ce qui se passe lorsqu’un utilisateur commence à utiliser l’application pour les phases d’exécution et le flux d’appels de données. Nous avons également abordé certaines des façons courantes dont les performances de votre application peuvent être dégradées. Bien que nous n’examinerons rien de plus dans cette unité, vous pouvez découvrir des conseils pratiques et bonnes pratiques permettant d’améliorer les performances des applications canevas et des considérations relatives à l’optimisation des performances dans Power Apps.