Delen via


Veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure

Notitie

Sommige van de onderstaande richtlijnen werken mogelijk alleen in Windows of Linux App Services. Linux App Services wordt bijvoorbeeld standaard uitgevoerd in de 64-bits modus.

In dit artikel vindt u antwoorden op veelgestelde vragen over prestatieproblemen met toepassingen voor de functie Web Apps van Azure-app Service.

Als uw Azure-probleem niet in dit artikel wordt behandeld, gaat u naar de Azure-forums op MSDN en Stack Overflow. U kunt uw probleem posten in deze forums of posten op @AzureSupport op Twitter. U kunt ook een Azure-ondersteuningsaanvraag indienen. Als u een ondersteuningsaanvraag wilt indienen, selecteert u op de pagina Azure-ondersteuning Ondersteuning krijgen.

Waarom geeft mijn App Service-plan cpu-/geheugengebruik weer, zelfs wanneer alle web-apps worden gestopt?

Azure-app Service vereist continue systeemprocessen die verschillende platformbewerkingen en -functies verwerken, zoals beveiligingsupdates, beschikbaarheid van de SCM-console, toepassingscontrole, verificatie en vele andere essentiële functies van uw web-app.

Systeemprocessen worden uitgevoerd op App Service-plannen, zelfs als er geen web-apps worden uitgevoerd of als het App Service-plan geen web-apps bevat.

De platformprocessen verbruiken een minimale hoeveelheid resources (zoals CPU, geheugen en schijfruimte) en hetzelfde moet worden verwerkt tijdens de configuratie van capaciteitsplanning, bewaking en automatisch schalen van een App Service-plan.

Waarom is mijn app traag?

Meerdere factoren kunnen bijdragen aan trage app-prestaties. Zie Problemen met trage prestaties van web-apps oplossen voor gedetailleerde stappen voor probleemoplossing.

Hoe kan ik problemen met een scenario met hoog CPU-verbruik oplossen?

In sommige scenario's met een hoog CPU-verbruik vereist uw app mogelijk echt meer rekenresources. In dat geval kunt u overwegen om naar een hogere servicelaag te schalen, zodat de toepassing alle benodigde resources krijgt. In andere gevallen kan een hoog CPU-verbruik worden veroorzaakt door een slechte lus of door een coderingspraktijk. Inzicht krijgen in wat een verhoogd CPU-verbruik activeert, is een tweedelige procedure. Maak eerst een procesdump en analyseer vervolgens de procesdump. Zie Een dumpbestand vastleggen en analyseren voor een hoog CPU-verbruik voor Web Apps voor meer informatie.

Hoe kan ik problemen met een scenario met hoog geheugenverbruik oplossen?

In sommige scenario's met een hoog geheugenverbruik vereist uw app mogelijk echt meer rekenresources. In dat geval kunt u overwegen om naar een hogere servicelaag te schalen, zodat de toepassing alle benodigde resources krijgt. In andere gevallen kan een fout in de code een geheugenlek veroorzaken. Een coderingspraktijk kan ook het geheugenverbruik verhogen. Inzicht krijgen in wat een hoog geheugenverbruik activeert, is een tweedelige procedure. Maak eerst een procesdump en analyseer vervolgens de procesdump. Crash Diagnoser vanuit de Galerie met Azure-site-extensies kan beide stappen efficiënt uitvoeren. Zie Een dumpbestand vastleggen en analyseren voor onregelmatig hoog geheugen voor Web Apps voor meer informatie.

Hoe kan ik App Service-web-apps automatiseren met behulp van PowerShell?

U kunt PowerShell-cmdlets gebruiken om App Service-web-apps te beheren en te onderhouden. In onze blogpost Automate-web-apps die worden gehost in Azure-app Service met behulp van PowerShell, beschrijven we hoe u PowerShell-cmdlets op basis van Azure Resource Manager gebruikt om algemene taken te automatiseren. De blogpost bevat ook voorbeeldcode voor verschillende beheertaken voor web-apps. Zie Az.Websites voor beschrijvingen en syntaxis voor alle App Service-web-apps-cmdlets.

Hoe kan ik de gebeurtenislogboeken van mijn web-app weergeven?

Ga als volgt te werk om de gebeurtenislogboeken van uw web-app weer te geven:

  1. Meld u aan bij uw Kudu-website (https://*yourwebsitename*.scm.azurewebsites.net).
  2. Selecteer CMD voor foutopsporingsconsole>in het menu.
  3. Selecteer de map LogFiles .
  4. Als u gebeurtenislogboeken wilt weergeven, selecteert u het potloodpictogram naast eventlog.xml.
  5. Voer de PowerShell-cmdlet Save-AzureWebSiteLog -Name webappnameuit om de logboeken te downloaden.

Hoe kan ik een geheugendump voor de gebruikersmodus van mijn web-app vastleggen?

Een geheugendump in de gebruikersmodus van uw web-app vastleggen:

  1. Meld u aan bij uw Kudu-website (https://*yourwebsitename*.scm.azurewebsites.net).
  2. Selecteer het menu Process Explorer .
  3. Klik met de rechtermuisknop op het w3wp.exe proces of uw webtaakproces.
  4. Selecteer Volledige dump voor geheugendump>downloaden.

Hoe kan ik informatie op procesniveau voor mijn web-app weergeven?

U hebt twee opties voor het weergeven van informatie op procesniveau voor uw web-app:

  • In Azure Portal:
    1. Open de Process Explorer voor de web-app.
    2. Als u de details wilt bekijken, selecteert u het w3wp.exe proces.
  • In de Kudu-console:
    1. Meld u aan bij uw Kudu-website (https://*yourwebsitename*.scm.azurewebsites.net).
    2. Selecteer het menu Process Explorer .
    3. Selecteer Eigenschappen voor het w3wp.exe-proces.

Wanneer ik naar mijn app blader, zie ik 'Fout 403 - Deze web-app is gestopt'. Hoe kan ik dit oplossen?

Drie voorwaarden kunnen deze fout veroorzaken:

  • De web-app heeft een factureringslimiet bereikt en uw site is uitgeschakeld.
  • De web-app is gestopt in de portal.
  • De web-app heeft een quotumlimiet voor resources bereikt die mogelijk van toepassing is op een serviceplan voor gratis of gedeelde schaal.

Als u wilt zien wat de fout veroorzaakt en het probleem wilt oplossen, volgt u de stappen in Web Apps: 'Fout 403 – Deze web-app is gestopt'.

Waar vind ik meer informatie over quota en limieten voor verschillende App Service-abonnementen?

Zie App Service-limieten voor informatie over quota en limieten.

Hoe kan ik de reactietijd voor de eerste aanvraag na niet-actieve tijd verlagen?

Standaard worden web-apps uitgepakt als ze gedurende een bepaalde periode niet actief zijn. Op deze manier kan het systeem resources besparen. Het nadeel is dat het antwoord op de eerste aanvraag nadat de web-app is geladen langer is, zodat de web-app antwoorden kan laden en starten. In de Basic- en Standard-serviceplannen kunt u de instelling AlwaysOn inschakelen om de app altijd geladen te houden. Dit elimineert langere laadtijden nadat de app inactief is. De instelling AlwaysOn wijzigen:

  1. Ga in Azure Portal naar uw web-app.
  2. Configuratie selecteren
  3. Selecteer Algemene instellingen.
  4. Voor AlwaysOn selecteert u Aan.

Hoe kan ik tracering van mislukte aanvragen inschakelen?

Voer de volgende stappen uit om tracering van mislukte aanvragen in te schakelen:

  1. Ga in Azure Portal naar uw web-app.

  2. Selecteer alle diagnostische logboeken voor instellingen>.

  3. Voor tracering van mislukte aanvragen selecteert u Aan.

  4. Selecteer Opslaan.

  5. Selecteer Extra op de blade van de web-app.

  6. Selecteer Visual Studio Online.

  7. Als de instelling niet is ingeschakeld, selecteert u Aan.

  8. Selecteer Zoeken.

  9. Selecteer Web.config.

  10. Voeg in system.webServer de volgende configuratie toe (om een specifieke URL vast te leggen):

    <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. Als u problemen met trage prestaties wilt oplossen, voegt u deze configuratie toe (als het vastleggen van de aanvraag langer duurt dan 30 seconden):

    <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. Als u de mislukte aanvraagtraceringen wilt downloaden, gaat u in de portal naar uw website.

  13. Selecteer Extra>Kudu>Go.

  14. Selecteer CMD voor foutopsporingsconsole>in het menu.

  15. Selecteer de map LogFiles en selecteer vervolgens de map met een naam die begint met W3SVC.

  16. Als u het XML-bestand wilt zien, selecteert u het potloodpictogram.

Ik zie het bericht 'Worker Process requested recycle due to 'Percent Memory'. Hoe kan ik dit probleem oplossen?

De maximale beschikbare hoeveelheid geheugen voor een 32-bits proces (zelfs op een 64-bits besturingssysteem) is 2 GB. Het werkproces is standaard ingesteld op 32-bits in App Service (voor compatibiliteit met verouderde webtoepassingen).

Overweeg over te schakelen naar 64-bits processen, zodat u kunt profiteren van het extra geheugen dat beschikbaar is in uw webwerkrol. Deze actie activeert het opnieuw opstarten van een web-app, dus plan dienovereenkomstig.

Houd er ook rekening mee dat voor een 64-bits omgeving een Basic- of Standard-serviceplan is vereist. Gratis en gedeelde abonnementen worden altijd uitgevoerd in een 32-bits omgeving.

Zie Web-apps configureren in App Service voor meer informatie.

Waarom treedt er na 230 seconden een time-out op voor mijn aanvraag?

Azure Load Balancer heeft een standaardinstelling voor time-outs bij inactiviteit langer dan vier minuten. Deze instelling is over het algemeen een redelijke reactietijdlimiet voor een webaanvraag. App Service retourneert dus een time-out naar de client als uw toepassing niet binnen ongeveer 240 seconden een antwoord retourneert (230 seconden op Windows-app, 240 seconden op linux-app). Als er voor uw web-app achtergrondverwerking is vereist, wordt u aangeraden Azure WebJobs te gebruiken. De Azure-web-app kan WebJobs oproepen en een melding ontvangen wanneer de achtergrondverwerking is voltooid. U kunt kiezen uit meerdere methoden voor het gebruik van WebJobs, inclusief wachtrijen en triggers.

WebJobs is ontworpen voor achtergrondverwerking. U kunt zoveel achtergrondverwerking uitvoeren als u wilt in een webtaak. Zie Achtergrondtaken uitvoeren met WebJobs voor meer informatie over WebJobs.

ASP.NET Core-toepassingen die worden gehost in App Service, reageren soms niet meer. Hoe kan ik dit probleem oplossen?

Een bekend probleem met een eerdere Kestrel-versie kan ertoe leiden dat een ASP.NET Core 1.0-app die wordt gehost in App Service, af en toe niet meer reageert. Mogelijk ziet u dit bericht: 'Er is een fout opgetreden bij de opgegeven CGI-toepassing en de server heeft het proces beëindigd.'

Dit probleem is opgelost in Kestrel versie 1.0.2. Deze versie is opgenomen in de update van ASP.NET Core 1.0.3. U kunt dit probleem oplossen door ervoor te zorgen dat u de app-afhankelijkheden bijwerkt voor het gebruik van Kestrel 1.0.2. U kunt ook een van de twee tijdelijke oplossingen gebruiken die worden beschreven in het blogbericht ASP.NET Core 1.0 trage prestatieproblemen in App Service-web-apps.

Ik kan mijn logboekbestanden niet vinden in de bestandsstructuur van mijn web-app. Hoe kan ik ze vinden?

Als u de functie Lokale cache van App Service gebruikt, is dit van invloed op de mapstructuur van de logbestanden en gegevensmappen voor uw App Service-exemplaar. Wanneer lokale cache wordt gebruikt, worden submappen gemaakt in de opslaglogboekbestanden en gegevensmappen. De submappen gebruiken het naamgevingspatroon 'unieke id' + tijdstempel. Elke submap komt overeen met een VM-exemplaar waarin de web-app wordt uitgevoerd of uitgevoerd.

Als u wilt bepalen of u lokale cache gebruikt, controleert u het tabblad Instellingen van de App Service-toepassing. Als lokale cache wordt gebruikt, wordt de app-instelling WEBSITE_LOCAL_CACHE_OPTION ingesteld op Always.

Als u geen lokale cache gebruikt en dit probleem ondervindt, dient u een ondersteuningsaanvraag in.

Ik zie het bericht 'Er is geprobeerd toegang te krijgen tot een socket op een manier die verboden is door de toegangsmachtigingen'. Hoe kan ik deze fout oplossen?

Deze fout treedt meestal op als de uitgaande TCP-verbindingen op het VM-exemplaar zijn uitgeput. In App Service worden limieten afgedwongen voor het maximum aantal uitgaande verbindingen dat kan worden gemaakt voor elk VM-exemplaar. Zie Numerieke limieten voor meerdere VM's voor meer informatie.

Deze fout kan ook optreden als u probeert toegang te krijgen tot een lokaal adres vanuit uw toepassing. Zie Aanvragen voor lokale adressen voor meer informatie.

Zie het blogbericht over uitgaande verbindingen met Azure-websites voor meer informatie over uitgaande verbindingen in uw web-app.

Hoe kan ik Visual Studio gebruiken om externe fouten in mijn App Service-web-app op te sporen?

Zie Remote-foutopsporing in uw App Service-web-app voor een gedetailleerd overzicht waarin wordt uitgelegd hoe u fouten in uw web-app kunt opsporen met Visual Studio.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.