FAQ sur les performances des applications web Azure dans Azure

Article
12/14/2024

Note

Certaines instructions ci-dessous fonctionnent uniquement sur les App Services Windows ou Linux. Par exemple, les App Services Linux s’exécutent en mode 64 bits par défaut.

Cet article fournit des réponses aux questions fréquemment posées (FAQ) sur les problèmes de performances des applications pour la fonctionnalité Web Apps d’Azure App Service.

Si le problème lié à Azure n’est pas traité dans cet article, parcourez les forums Azure sur MSDN et Stack Overflow. Vous pouvez publier votre problème sur ces forums ou @AzureSupport sur Twitter. Vous pouvez également envoyer une demande de support Azure. Pour envoyer une demande de support sur la page Prise en charge Azure, sélectionnez Obtenir de l’aide.

Pourquoi mon plan App Service affiche-t-il l’utilisation du processeur/de la mémoire même lorsque toutes les applications web sont arrêtées ?

Azure App Service nécessite des processus système continus qui gèrent plusieurs opérations et fonctionnalités de plateforme, telles que les mises à jour de sécurité, la disponibilité de la console SCM, la surveillance des applications, l’authentification et de nombreuses autres fonctionnalités vitales de votre application web.

Les processus système s’exécutent sur des plans App Service, même s’il n’existe aucune application web en cours d’exécution ou si le plan App Service ne contient aucune application web.

Les processus de plateforme consomment une quantité minimale de ressources (telles que l’UC, la mémoire et l’espace disque), et la même chose doit être prise en compte lors de la planification de la capacité, de la surveillance et de la configuration du déclencheur de mise à l’échelle automatique d’un plan App Service.

Pourquoi mon application est-elle lente ?

Plusieurs facteurs peuvent ralentir les performances d’une application. Pour obtenir des étapes de dépannage détaillées, consultez Résoudre les problèmes de lenteur d’une application web.

Comment puis-je résoudre un problème de consommation excessive du processeur ?

Dans certaines situations de consommation excessive du processeur, votre application peut vraiment nécessiter davantage de ressources informatiques. Dans ce cas, vous pouvez évoluer vers un niveau de service supérieur afin que l’application obtienne toutes les ressources dont elle a besoin. Dans d’autres cas, une consommation excessive du processeur peut être due à une boucle incorrecte ou à une méthode de codage. Obtenir un aperçu de ce qui déclenche une consommation excessive du processeur est un processus en deux parties. Créez d’abord un vidage du processus puis analysez ce vidage de processus. Pour plus d’informations, consultez Capturer et analyser un fichier de vidage en cas de consommation excessive du processeur pour Web Apps.

Comment résoudre les problèmes de consommation excessive de la mémoire ?

Dans certaines situations de consommation excessive de mémoire, votre application peut vraiment nécessiter davantage de ressources informatiques. Dans ce cas, vous pouvez évoluer vers un niveau de service supérieur afin que l’application obtienne toutes les ressources dont elle a besoin. À d’autres moments, un bogue dans le code peut entraîner une fuite de mémoire. Une pratique de codage peut également augmenter la consommation de mémoire. Obtenir un aperçu de ce qui déclenche une consommation excessive de mémoire est un processus en deux parties. Créez d’abord un vidage du processus puis analysez ce vidage de processus. L’outil Crash Diagnoser d’Azure Site Extension Gallery peut effectuer efficacement ces deux étapes. Pour plus d’informations, consultez Capturer et analyser un fichier de vidage en cas de consommation excessive intermittente de mémoire pour Web Apps.

Comment automatiser les applications web App Service à l’aide de PowerShell ?

Vous pouvez utiliser les applets de commande PowerShell pour gérer et mettre à jour des applications web App Service. Dans notre billet de blog Automatiser des applications web hébergées dans Azure App Service à l’aide de PowerShell, nous expliquons comment utiliser des applets de commande PowerShell basée sur Azure Resource Manager pour automatiser des tâches courantes. Ce billet de blog fournit également un exemple de code pour diverses tâches de gestion des applications web. Pour des descriptions et la syntaxe de toutes les applets de commande des applications web App Service, consultez Az.Websites.

Comment afficher les journaux des événements de mon application web ?

Pour afficher les journaux des événements de votre application web :

Connectez-vous à votre site web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
Dans le menu, sélectionnez Console de débogage>CMD.
Sélectionnez le dossier LogFiles.
Pour afficher les journaux des événements, sélectionnez l’icône en forme de crayon en regard de eventlog.xml.
Pour télécharger les journaux d’activité, exécutez l’applet de commande PowerShell Save-AzureWebSiteLog -Name webappname.

Comment capturer un vidage de mémoire en mode utilisateur de mon application web ?

Pour capturer un vidage de mémoire en mode utilisateur de votre application web :

Connectez-vous à votre site web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
Sélectionnez le menu Explorateur de processus.
Cliquez avec le bouton droit sur le menu w3wp.exe ou sur votre processus WebJob.
Sélectionnez Télécharger le vidage de mémoire>Vidage complet.

Comment afficher les informations au niveau processus pour mon application web ?

Vous avez deux options pour afficher les informations au niveau processus pour votre application web :

Dans le portail Azure :
1. Ouvrez l’Explorateur de processus pour l’application web.
2. Pour afficher les détails, sélectionnez le processus w3wp.exe.
Dans la console Kudu :
1. Connectez-vous à votre site web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
2. Sélectionnez le menu Explorateur de processus.
3. Pour le processus w3wp.exe, sélectionnez Propriétés.

Lorsque j’accède à mon application, je vois « Erreur 403 - Cette application web est arrêtée ». Comment faire résoudre ce problème ?

Trois conditions peuvent provoquer cette erreur :

L’application web a atteint une limite de facturation et votre site a été désactivé.
L’application web a été arrêtée dans le portail.
L’application web a atteint une limite de quota de ressources qui peut s’appliquer à un plan de service de mise à l’échelle gratuit ou partagé.

Pour voir ce qui provoque l’erreur et résoudre le problème, suivez les étapes de la rubrique Web Apps : « Erreur 403 - Cette application web est arrêtée ».

Où puis-je obtenir plus d’informations sur les quotas et les limites des différents plans App Service ?

Pour plus d’informations sur les quotas et les limites, consultez Limites App Service.

Comment réduire les temps de réponse de la première requête après une période d’inactivité ?

Par défaut, les applications web sont déchargées si elles sont inactives pendant une période définie. De cette manière, le système peut économiser les ressources. L’inconvénient est que la réponse à la première requête une fois que l’application web est déchargée est plus longue, pour permettre à l’application web de charger puis de démarrer le traitement des réponses. Dans les plans de service De base et Standard, vous pouvez activer le paramètre Always On afin que l’application reste toujours chargée. Cela raccourcit les délais de chargement une fois que l’application est inactive. Pour modifier le paramètre Always On :

Dans le portail Azure, accédez à votre application web.
Sélectionnez Configuration.
Sélectionnez Paramètres généraux.
Pour Always On, sélectionnez On.

Comment activer le suivi des demandes ayant échoué ?

Pour activer le suivi des demandes ayant échoué, procédez comme suit :

Dans le portail Azure, accédez à votre application web.
Sélectionnez Tous les paramètres>Journaux de diagnostic.
Pour Suivi des demandes ayant échoué, sélectionnez On.
Cliquez sur Enregistrer.
Dans le panneau des applications web, sélectionnez Outils.
Sélectionnez Visual Studio Online.
Si le paramètre n’est pas activé, sélectionnez Activé.
Sélectionnez Go.
Sélectionnez Web.config.

Dans system.webServer, ajoutez la configuration suivante (pour capturer une URL spécifique) :

<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*api*" />
<add path="*api*">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>

Pour résoudre les problèmes de baisse des performances, ajoutez cette configuration (si la demande de capture prend plus de 30 secondes) :

<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*" />
<add path="*">
<traceAreas> <add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions timeTaken="00:00:30" statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>

Pour télécharger les traces de demandes ayant échoué, dans le portail, accédez à votre site web.
Sélectionnez Outils>Kudu>Go.
Dans le menu, sélectionnez Console de débogage>CMD.
Sélectionnez le dossier LogFiles puis le dossier dont le nom commence par W3SVC.
Pour afficher le fichier XML, sélectionnez l’icône en forme de crayon.

Le message « Processus de travail a demandé le recyclage en raison de la limite de pourcentage de mémoire ». Comment faire résoudre ce problème ?

La quantité maximale de mémoire disponible pour un processus 32 bits (même sur un système d’exploitation 64 bits) est de 2 Go. Par défaut, le processus de travail est défini sur 32 bits dans App Service (à des fins de compatibilité avec les applications web héritées).

Vous pouvez basculer vers des processus 64 bits pour tirer parti de la mémoire supplémentaire disponible de votre rôle de travail web. Comme cette action déclenche un redémarrage de l’application web, vous devez la planifier en conséquence.

Notez également qu’un environnement 64 bits nécessite un plan de service De base ou Standard. Les plans Gratuit et Partagé s’exécutent toujours dans un environnement 32 bits.

Pour plus d’informations, consultez Configurer des applications web dans App Service.

Pourquoi ma demande expire-t-elle au bout de 230 secondes ?

L’équilibrage de charge Azure comporte un paramètre de délai d’inactivité par défaut de quatre minutes. Cette limite de temps de réponse est généralement raisonnable pour une demande web. Par conséquent, App Service retourne un délai d’expiration au client si votre application ne retourne pas de réponse dans un délai d’environ 240 secondes (230 secondes sur l’application Windows, 240 secondes sur l’application Linux).　Si votre application web requiert un traitement en arrière-plan, nous vous recommandons d’utiliser des tâches Azure WebJob. L’application web Azure peut appeler des tâches WebJob et être avertie lorsque le traitement en arrière-plan est terminé. Vous pouvez choisir parmi plusieurs méthodes pour utiliser des tâches WebJob, y compris des files d’attente et des déclencheurs.

Les tâches WebJob sont conçues pour le traitement en arrière-plan. Vous pouvez effectuer autant de traitement en arrière-plan que vous le souhaitez dans une tâche WebJob. Pour plus d’informations sur les tâches WebJob, consultez Exécuter des tâches en arrière-plan avec des tâches WebJob.

Les applications ASP.NET Core hébergées dans App Service cessent parfais de répondre. Comment résoudre ce problème ?

Un problème connu avec une version de Kestrel antérieure peut amener une application ASP.NET Core 1.0 hébergée dans App Service à cesser de répondre par intermittence. Le message suivant peut également apparaître : « L'application CGI spécifiée a rencontré une erreur et le serveur a mis fin au processus. »

Ce problème est résolu dans Kestrel version 1.0.2. Cette version est incluse dans la mise à jour ASP.NET Core 1.0.3. Pour résoudre ce problème, veillez à mettre à jour les dépendances de votre application afin d’utiliser Kestrel 1.0.2. Vous pouvez également utiliser une des deux solutions de contournement décrites dans le billet de blog ASP.NET Core 1.0 slow perf issues in App Service web apps.

Impossible de trouver mes fichiers journaux dans la structure de fichiers de mon application web. Comment puis-je les trouver ?

La fonctionnalité Cache local d’App Service affecte la structure des dossiers LogFiles et Data de votre instance App Service. Lorsque la fonctionnalité Cache local est utilisée, des sous-dossiers sont créés dans les dossiers de données LogFiles et Data. Ces sous-dossiers utilisent le même modèle d’affectation de noms « identificateur unique » + horodatage. Chaque sous-dossier correspond à une instance de machine virtuelle dans laquelle l’application web est ou a été exécutée.

Pour déterminer si vous utilisez le cache local, consultez l’onglet Paramètres de votre application App Service. Si le cache local est utilisé, le paramètre WEBSITE_LOCAL_CACHE_OPTION d’application est défini sur Always.

Si vous n’utilisez pas le cache local et que vous rencontrez ce problème, envoyez une demande de support.

Je vois le message « Une tentative a été faite pour accéder à un socket d’une manière interdite par ses autorisations d’accès ». Comment faire résoudre cette erreur ?

Cette erreur se produit généralement si les connexions TCP sortantes sur l’instance de la machine virtuelle sont épuisées. Dans App Service, des limites sont appliquées au le nombre maximal de connexions sortantes possibles pour chaque instance de machine virtuelle. Pour plus d’informations, consultez Limites numériques entre les machines virtuelles.

Cette erreur peut également se produire si vous essayez d’accéder à une adresse locale à partir de votre application. Pour plus d’informations, consultez Demandes d’adresses locales.

Pour plus d’informations sur les connexions sortantes dans votre application web, consultez le billet de blog consacré aux connexions sortantes vers des sites web Azure.

Comment utiliser Visual Studio pour déboguer à distance mon application web App Service ?

Pour obtenir une procédure détaillée montrant comment déboguer votre application web à l’aide de Visual Studio, consultez Déboguer à distance votre application web App Service.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Partager via