FAQ sur les performances des applications pour Web Apps dans Azure

  • Article

Remarque

Certaines des recommandations ci-dessous peuvent fonctionner uniquement sur Windows ou Linux App Services. Par exemple, Les services d’application Linux s’exécutent en mode 64 bits par défaut.

Cet article contient des réponses aux questions fréquentes (FAQ) sur les problèmes de performances des applications pour la fonctionnalité Web Apps de Azure App Service.

Si votre problème Azure n’est pas traité dans cet article, consultez les forums Azure sur MSDN et Stack Overflow. Vous pouvez publier votre problème sur ces forums ou sur @AzureSupport sur Twitter. Vous pouvez également envoyer une demande de support Azure. Pour envoyer une demande de support, rendez-vous sur la page du support Azure, puis 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 tous les Web Apps sont arrêtés ?

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 App Service Plans même s’il n’y a pas de Web Apps en cours d’exécution ou si le plan App Service ne contient aucune Web Apps.

Les processus de plateforme consomment une quantité minimale de ressources (telles que le processeur, la mémoire et l’espace disque), et les mêmes éléments doivent être pris 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 de App Service.

Pourquoi mon application est-elle lente ?

Plusieurs facteurs peuvent contribuer à ralentir les performances de l’application. Pour connaître les étapes de dépannage détaillées, consultez Résoudre les problèmes de lenteur des performances des applications web.

Comment faire résoudre un scénario de consommation élevée du processeur ?

Dans certains scénarios de consommation élevée du processeur, votre application peut vraiment nécessiter davantage de ressources de calcul. Dans ce cas, envisagez d’effectuer une mise à l’échelle 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 élevée du processeur peut être due à une boucle incorrecte ou à une pratique de codage. L’obtention d’informations sur ce qui déclenche une consommation accrue du processeur est un processus en deux parties. Tout d’abord, créez un vidage de processus, puis analysez le vidage du processus. Pour plus d’informations, consultez Capturer et analyser un fichier de vidage pour une consommation élevée du processeur pour Web Apps.

Comment faire résoudre un scénario de consommation de mémoire élevée ?

Dans certains scénarios de consommation élevée de mémoire, votre application peut réellement nécessiter davantage de ressources de calcul. Dans ce cas, envisagez d’effectuer une mise à l’échelle vers un niveau de service supérieur afin que l’application obtienne toutes les ressources dont elle a besoin. Dans d’autres cas, 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. L’obtention d’informations sur ce qui déclenche une consommation élevée de mémoire est un processus en deux parties. Tout d’abord, créez un vidage de processus, puis analysez le vidage du processus. Crash Diagnoser de la galerie d’extensions de site Azure peut effectuer efficacement ces deux étapes. Pour plus d’informations, consultez Capture and analyze a dump file for intermittent high memory for Web Apps.

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

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

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

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

  1. Connectez-vous à votre site web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
  2. Dans le menu, sélectionnez Débogage console>CMD.
  3. Sélectionnez le dossier LogFiles .
  4. Pour afficher les journaux des événements, sélectionnez l’icône de crayon en regard deeventlog.xml.
  5. Pour télécharger les journaux, exécutez l’applet de commande Save-AzureWebSiteLog -Name webappnamePowerShell .

Comment faire 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 :

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

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

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

  • Dans le Portail Azure :
    1. Ouvrez l’Explorer 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 Traiter Explorer.
    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 la cause de l’erreur et résoudre le problème, suivez les étapes décrites dans Web Apps : « Erreur 403 – Cette application web est arrêtée ».

Où puis-je en savoir plus 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 faire réduire le temps de réponse de la première requête après le temps d’inactivité ?

Par défaut, les applications web sont déchargées si elles sont inactives pendant une période définie. De cette façon, le système peut économiser les ressources. L’inconvénient est que la réponse à la première requête après le déchargement de l’application web est plus longue, pour permettre à l’application web de charger et de commencer à fournir des réponses. Dans les plans de service De base et Standard, vous pouvez activer le paramètre Always On pour que l’application reste toujours chargée. Cela élimine les temps de chargement plus longs après l’inactivité de l’application. Pour modifier le paramètre Always On :

  1. Dans la Portail Azure, accédez à votre application web.
  2. Sélectionnez Configuration
  3. Sélectionnez Paramètres généraux.
  4. Pour Always On, sélectionnez Activé.

Comment faire activer le suivi des demandes ayant échoué ?

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

  1. Dans la Portail Azure, accédez à votre application web.

  2. Sélectionnez Tous les paramètres>Journaux de diagnostic.

  3. Pour Suivi des demandes ayant échoué, sélectionnez Activé.

  4. Sélectionnez Enregistrer.

  5. Dans le panneau de l’application web, sélectionnez Outils.

  6. Sélectionnez Visual Studio Online.

  7. Si le paramètre n’est pas Activé, sélectionnez Activé.

  8. Sélectionner Aller.

  9. Sélectionnez Web.config.

  10. 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>

  11. Pour résoudre les problèmes de ralentissement 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>

  12. Pour télécharger les traces de demande ayant échoué, dans le portail, accédez à votre site web.

  13. Sélectionnez Outils>Kudu>Go.

  14. Dans le menu, sélectionnez Débogage console>CMD.

  15. Sélectionnez le dossier LogFiles , puis sélectionnez le dossier dont le nom commence par W3SVC.

  16. Pour afficher le fichier XML, sélectionnez l’icône en forme de crayon.

Je vois le message « Processus de travail demandé un recyclage en raison de la limite « 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 (pour la compatibilité avec les applications web héritées).

Envisagez de passer aux processus 64 bits afin de tirer parti de la mémoire supplémentaire disponible dans votre rôle De travail web. Cette action déclenche le redémarrage d’une application web. Planifiez donc en conséquence.

Notez également qu’un environnement 64 bits nécessite un plan de service De base ou Standard. Les plans gratuits et partagés 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 après 230 secondes ?

Azure Load Balancer a un paramètre de délai d’inactivité par défaut de quatre minutes. Ce paramètre est généralement une limite de temps de réponse 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 nécessite un traitement en arrière-plan, nous vous recommandons d’utiliser Azure WebJobs. L’application web Azure peut appeler WebJobs et être avertie lorsque le traitement en arrière-plan est terminé. Vous pouvez choisir parmi plusieurs méthodes pour utiliser webJobs, y compris les files d’attente et les déclencheurs.

WebJobs est conçu 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 web. Pour plus d’informations sur webJobs, consultez Exécuter des tâches en arrière-plan avec WebJobs.

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

Un problème connu avec une version antérieure de Kestrel peut entraîner l’arrêt intermittent d’une application ASP.NET Core 1.0 hébergée dans App Service. Ce message peut également s’afficher : « 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 pour utiliser Kestrel 1.0.2. Vous pouvez également utiliser l’une des deux solutions de contournement décrites dans le billet de blog ASP.NET Core problèmes de performances lentes 1.0 dans App Service applications web.

Je ne trouve pas mes fichiers journaux dans la structure de fichiers de mon application web. Comment puis-je les trouver ?

Si vous utilisez la fonctionnalité Cache local de App Service, la structure des dossiers LogFiles et Data de votre App Service instance est affectée. Lorsque le cache local est utilisé, des sous-dossiers sont créés dans les dossiers LogFiles et Data de stockage. Les sous-dossiers utilisent le modèle de nommage « identificateur unique » + horodatage. Chaque sous-dossier correspond à une machine virtuelle instance dans laquelle l’application web est en cours d’exécution ou a été exécutée.

Pour déterminer si vous utilisez le cache local, case activée votre App Service onglet Paramètres de l’application. 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 d’accès à un socket a été 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 la machine virtuelle instance sont épuisées. Dans App Service, des limites sont appliquées pour le nombre maximal de connexions sortantes pouvant être établies pour chaque machine virtuelle instance. Pour plus d’informations, consultez Limites numériques entre 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’adresse locale.

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

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

Pour obtenir une procédure pas à pas détaillée qui vous montre comment déboguer votre application web à l’aide de Visual Studio, consultez Débogage à distance de 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.