Neuf conseils de performances pour les services Azure App

Cet article examine neuf astuces pour améliorer les performances de vos applications hébergées Azure App Service. Certains de ces conseils sont de simples modifications de configuration que vous pouvez apporter aujourd'hui, alors que d'autres peuvent nécessiter une refonte et un refactoring de votre application.

Nous voulons toujours obtenir les meilleures performances des logiciels que nous déployons sur Azure App Services. Non seulement de meilleures performances satisfont nos clients, mais de meilleures performances peuvent également nous faire économiser de l'argent si nous "faisons plus avec moins" dans Azure. Dans cet article, nous examinerons les paramètres et les stratégies permettant d'améliorer les performances des applications Web et des API Web s'exécutant dans Azure App Service. Nous allons commencer par quelques modifications de configuration faciles à apporter pour une amélioration immédiate.

Activer HTTP / 2

Microsoft a annoncé la prise en charge de HTTP / 2 dans App Services au début de 2018. Toutefois, lorsque vous créez un nouveau service d'application. Aujourd'hui, Azure vous lancera avec HTTP 1.1 configuré comme protocole par défaut. HTTP / 2 apporte des modifications majeures à notre protocole Web favori, et de nombreuses modifications visent à améliorer les performances et à réduire la latence sur le Web. Par exemple, la compression d'en-tête et le formatage binaire dans HTTP / 2 réduiront la taille de la charge utile. Un exemple encore meilleur est l’utilisation du multiplexage et du pipeline de demandes. Ces fonctionnalités permettent de multiplier le nombre de requêtes simultanées utilisant moins de sockets réseau et d'éviter qu'une seule requête lente ne bloque toutes les requêtes suivantes, ce qui est un problème fréquent dans HTTP 1.1, que nous appelons le problème de blocage «en-tête de ligne».

configurez votre service d’application pour utiliser HTTP / 2 avec le portail, accédez à Paramètres de la plate-forme dans le panneau Configuration. Ici vous trouverez un menu déroulant pour spécifier la version HTTP. Lorsque la version 2.0 est sélectionnée, tous les clients prenant en charge HTTP / 2 mettront leur connexion à niveau automatiquement.

HTTP / 2 ne bénéficiera peut-être pas à toutes les applications. tests de performance et tests de résistance pour documenter vos améliorations. Voici un test simple dans lequel j'ai utilisé les outils réseau de Firefox sur une page hébergée dans un service d'application. La page fait référence à une poignée de ressources de script et CSS, et comprend également 16 images. Chaque image mesure plus de 200 Ko. Tout d'abord, j'ai utilisé les outils de développement pour enregistrer ce qui se passe sur un service d'application à l'aide de HTTP 1.1. Remarquez comment les demandes ultérieures démarrent dans un état bloqué (la section rouge des barres). Il s’agit du problème redouté de «blocage en tête de ligne», où les limitations relatives au nombre de connexions et aux demandes simultanées limitent le débit entre le client et le serveur. Le client ne reçoit pas les derniers octets de la page avant 800 ms après le début de la première demande.

Ensuite, j'ai activé le support HTTP / 2 dans App Service. Je n'ai pas eu besoin de faire d'autres changements de configuration sur le client ou le serveur. Le dernier octet arrive en moins de 500 ms. Nous évitons les blocages grâce à l'utilisation optimisée de HTTP / 2 sur le réseau.

Désactivation du cookie de routage des demandes d'application

Devant chaque service Azure App se trouve un équilibreur de charge, même si vous n'exécutez qu'une seule instance de votre plan de service d'application. L'équilibreur de charge intercepte chaque en-tête de demande pour votre service d'application. Ainsi, lorsque vous passez à plusieurs instances d'un plan de service d'application, il peut commencer à équilibrer la charge de demande par rapport aux instances disponibles. Par défaut, Azure veillera à ce que les clients continuent d'atteindre la même instance de service d'application au cours d'une session, car Azure ne peut pas garantir que votre application ne stocke pas l'état de la session dans la mémoire du serveur. Pour fournir ce comportement, l'équilibreur de charge injectera un cookie dans la première réponse à un client. Ce cookie est ce que Azure appelle le cookie de routage des requêtes d'application.

Si vous disposez d'une application sans état et pouvez permettre à l'équilibreur de charge de distribuer des requêtes sur plusieurs instances sans tenir compte des requêtes précédentes, désactivez le cookie de routage dans le panneau Configuration pour s'améliorer. performance et résilience. Les demandes n'attendront pas le redémarrage du serveur et, en cas d'échec, l'équilibreur de charge peut déplacer rapidement les clients vers une instance active.

La configuration de l'acheminement est un autre élément que vous trouverez dans les paramètres de plate-forme de l'application. Lame de configuration du service.

Conserver le service d'application toujours activé

Si vous avez déjà déployé des applications dans IIS, vous saurez que celui-ci déchargera les sites Web inactifs après une période d'inactivité. Azure App Services déchargera également les sites Web inactifs. Bien que le déchargement puisse libérer des ressources pour d'autres applications susceptibles de s'exécuter sur le même plan de service d'application, cette stratégie nuit aux performances de l'application car la prochaine demande entrante attendra que l'application Web démarre à partir de rien. Le temps de démarrage d'une application Web peut être notoirement lent, quelles que soient les technologies impliquées. Les caches sont vides, les pools de connexions sont vides et toutes les demandes sont plus lentes que d'habitude car le site doit être réchauffé.

Pour éviter l'arrêt inactif, vous pouvez définir l'indicateur Toujours actif dans le panneau Configuration du service d'application. 19659002]

Utiliser un cache local

Par défaut, le système de fichiers de votre service d'application est monté à partir de Azure Storage. La bonne nouvelle est que votre système de fichiers est durable, hautement disponible et accessible à partir de plusieurs instances App Service. La triste nouvelle est que votre application passe un appel réseau chaque fois qu'elle touche le système de fichiers.

Certaines applications nécessitent la solution Azure Storage. Ce sont les applications qui écrivent dans le système de fichiers, par exemple lorsqu'un utilisateur télécharge un fichier, et s'attendent à ce que les modifications apportées au système de fichiers soient durables, permanentes et immédiatement visibles sur toutes les instances en cours d'exécution de l'application. D'autres applications pourraient bénéficier d'une copie plus rapide, locale et en lecture seule du contenu du site Web. Si cela ressemble à votre application ou si vous souhaitez exécuter un test, créez un nouveau paramètre d'application pour l'application avec une clé de type WEBSITE_LOCAL_CACHE_OPTION et une valeur de toujours. Vous aurez ensuite ad: home folder pointant vers un cache local sur la machine et contenant une copie du contenu de votre site.

Bien que je dise que le cache est En lecture seule, vous pouvez écrire dans le dossier de cache local. Cependant, vous perdrez toutes les modifications apportées après le redémarrage d'une application. Pour plus d'informations sur les compromis impliqués et le fonctionnement du cache local avec les fichiers journaux, voir Présentation du cache local Azure App Service .

Gardez vos clients proches et vos ressources encore plus proches

Tous les Les améliorations de performances que nous avons examinées jusqu'à présent ne nécessitent que des modifications de configuration. Les prochaines améliorations nécessitent une planification ou une restructuration supplémentaire de l’infrastructure et, dans certains cas, des modifications de l’application elle-même. Le thème commun des conseils suivants est de réduire la distance que les bits doivent parcourir sur le réseau. La vitesse de la lumière est limitée, de sorte que plus un bit doit se déplacer, plus il est long pour atteindre une destination.

Co-localisez votre service d'application et votre base de données

Dans Azure, vous affectez la plupart des ressources que vous créez. une région spécifique. Par exemple, lorsque je crée un service d'application, je peux le placer près de moi dans la région Est des États-Unis ou, si je suis en visite étendue en Europe, je peux sélectionner la région Europe du Nord. Si vous créez plusieurs ressources qui fonctionnent ensemble étroitement, vous voudrez placer les ressources ensemble dans la même région. Dans le passé, les performances ont été affectées par les performances d'un membre de la société qui a accidentellement placé un service d'application dans une région et une instance Azure SQL associée dans une autre région. Chaque requête de base de données à partir du service d'application devient un voyage à travers le continent ou le monde entier.

Comment vérifiez-vous vos abonnements existants pour vous assurer que vos ressources sont co-localisées correctement? En supposant que vous ne souhaitiez pas cliquer manuellement sur le portail pour vérifier manuellement, vous pouvez écrire un script ou un programme personnalisé ou utiliser la stratégie Azure . Azure Policy comporte une règle intégrée permettant de vérifier chaque ressource pour s'assurer que l'emplacement de la ressource correspond à l'emplacement du groupe de ressources parent de la ressource. Avec cette règle en place, il vous suffit de vous assurer que vos ressources associées font toutes partie du même groupe de ressources. La définition de politique pour cette règle d'audit a l'aspect suivant:

 {
  "si": {
    "field": "location",
    "notIn": [
      "[resourcegroup().location] ",
      "global"
    ]
  },
  "puis": {
    "effect": "audit"
  }
} 

Conservez le service de votre application à proximité de votre client

Si la majeure partie de votre trafic client provient d'une région spécifique du monde, il est logique de placer vos ressources dans la région Azure la plus proche de vos clients. Bien sûr, beaucoup d’entre nous ont des clients répartis de manière équitable dans le monde entier. Dans ce cas, vous pouvez envisager de répliquer géographiquement vos ressources sur plusieurs régions Azure afin de rester proches de tous. Pour App Services, cela signifie créer plusieurs plans App Service au sein de plusieurs centres de données Azure à travers le monde. Ensuite, vous utiliserez généralement une technologie telle qu'Azure Traffic Manager pour diriger le trafic client vers l'instance App Service la plus proche.

Traffic Manager est un équilibreur de charge basé sur DNS. Ainsi, lorsque le navigateur Web d'un client demande l'adresse IP associée au domaine de votre application, Traffic Manager peut utiliser les règles que vous fournissez et d'autres méthodes heuristiques pour sélectionner l'adresse IP d'un service d'application spécifique. Traffic Manager peut sélectionner le service d'application avec la latence la plus faible pour une demande client donnée, ou vous pouvez également configurer Traffic Manager pour appliquer la géo-séparation au moyen de laquelle l'équilibreur de charge envoie tous les clients résidant dans une province ou un pays spécifique au service d'application sélectionné. Vous pouvez voir les méthodes de routage intégrées à Traffic Manager dans la lame Créer un profil de gestionnaire de trafic ci-dessous.

Le gestionnaire de trafic introduit des compromis et des complications. Il est facile de répliquer des applications Web et des services Web sans état dans des centres de données du monde entier, mais vous devrez passer un certain temps à planifier une stratégie d'accès aux données. Garder une base de données comme seule source de vérité est la méthode d'accès aux données la plus simple. Toutefois, si votre App Service en Australie lit des données d’une base de données située au Royaume-Uni, vous risquez de perdre les avantages en termes de performances de la réplication géographique du Service d’application. Une autre option consiste également à répliquer vos données, mais cela dépend en grande partie de vos exigences commerciales en matière de cohérence. La réplication des données est généralement asynchrone et différée, et votre entreprise pourrait ne pas être en mesure de supporter les conséquences d'une éventuelle cohérence.

Gardez votre contenu proche du client

Le réseau de diffusion de contenu Azure vous permet de récupérer du contenu statique dans Azure Storage. , ou depuis votre App Service, et distribuez le contenu sur des serveurs périphériques du monde entier. Encore une fois, l’idée est de réduire la distance nécessaire pour parcourir les informations, et donc la latence dans les requêtes réseau. Les fichiers statiques tels que les fichiers de script, les images, les fichiers CSS et les vidéos sont de bons candidats pour la mise en cache sur les serveurs de périphérie CDN. Un CDN peut aussi avoir d'autres avantages. Étant donné que votre App Service n'a pas besoin de passer du temps ou de la bande passante à servir des fichiers mis en cache sur un CDN, il dispose de davantage de ressources pour produire votre contenu dynamique.

Lors de la configuration d'un profil CDN dans Azure, vous pouvez sélectionner un plan tarifaire avec les fonctionnalités dont vous avez besoin parmi un ensemble de fournisseurs comprenant Microsoft, Verizon et Akamai.

Associez vos applications

L'architecture actuelle consiste à décomposer les systèmes en un ensemble de microservices. Ces microservices doivent communiquer entre eux pour traiter les demandes des clients. Tout comme maintenir la proximité de votre application et de votre base de données peut améliorer les performances, mais maintenir vos microservices proches de vos avantages peut également améliorer les performances.

Avec App Services, n'oubliez pas que plusieurs services peuvent vivre sur le même plan de service d'application. Imaginez le plan comme une machine virtuelle dédiée au rôle de serveur Web. Vous pouvez placer autant d'applications que vous le souhaitez sur le serveur Web. Conserver les services ensemble permet de réduire la latence du réseau. Cependant, gardez à l'esprit que le fait de disposer de trop de services sur le même ordinateur peut réduire considérablement les ressources. Des essais et des tests sont nécessaires pour déterminer la meilleure répartition des services, la taille idéale des plans de services pour applications et le nombre d'instances nécessaires pour traiter toutes les demandes de vos clients.

Résumé

Nous avons consulté Plusieurs stratégies peuvent être utilisées pour améliorer les performances des applications Web et des API Web que nous avons déployées sur Azure App Services. Rappelez-vous simplement que la première étape avant d’essayer l’une de ces stratégies consiste à mesurer les performances de votre application et à obtenir un bon numéro de référence. Toutes les stratégies décrites dans cet article ne profiteront pas à toutes les applications. En commençant par les chiffres de performance de base, vous pourrez comparer les stratégies et déterminer celles qui sont les plus efficaces pour votre application.