Condividi tramite

Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure

  • Articolo

Note

Alcune delle linee guida seguenti potrebbero funzionare solo in servizio app Windows o Linux. Ad esempio, i servizio app Linux vengono eseguiti in modalità a 64 bit per impostazione predefinita.

Questo articolo offre risposte alle domande frequenti sui problemi di prestazioni delle applicazioni per la funzionalità App Web del servizio app di Azure.

Se il problema riguardante Azure non viene risolto in questo articolo, visitare i forum di Azure su MSDN e Stack Overflow. È possibile pubblicare il problema in questi forum o in @AzureSupport su Twitter. È anche possibile inviare una richiesta di supporto tecnico di Azure. Per inviare una richiesta di supporto, selezionare Supporto tecnico nella pagina del supporto di Azure.

Perché il piano di servizio app visualizza l'utilizzo della CPU/memoria anche quando tutte le App Web vengono arrestate?

app Azure Servizio richiede processi di sistema continui che gestiscono diverse operazioni e funzionalità della piattaforma, ad esempio gli aggiornamenti della sicurezza, la disponibilità della console SCM, il monitoraggio delle applicazioni, l'autenticazione e molte altre funzionalità essenziali dell'app Web.

I processi di sistema verranno eseguiti in piani di servizio app anche se non sono in esecuzione App Web o se il piano di servizio app non contiene App Web.

I processi della piattaforma utilizzeranno una quantità minima di risorse ,ad esempio CPU, memoria e spazio su disco, e lo stesso deve essere tenuto in considerazione durante la pianificazione della capacità, il monitoraggio e la configurazione del trigger di ridimensionamento automatico di un piano di servizio app.

Perché l'app è lenta?

Più fattori possono contribuire a rallentare le prestazioni delle app. Per la procedura di risoluzione dei problemi dettagliata, vedere Risolvere i problemi di rallentamento delle prestazioni delle app Web.

Come si risolvono i problemi di uno scenario con utilizzo elevato di CPU?

In alcuni scenari di utilizzo elevato di CPU, l'app può richiedere realmente più risorse di calcolo. In tal caso, prendere in considerazione il passaggio a un livello di servizio superiore per fornire tutte le risorse necessarie all'applicazione. In altri casi, un utilizzo elevato di CPU può essere causato da un ciclo non valido o da una procedura di codifica. La procedura che consente di ottenere informazioni su cosa provochi un maggiore utilizzo di CPU prevede due parti. Creare prima un dump dei processi e analizzarlo. Per altre informazioni, vedere Acquisire e analizzare un file di dump per l'utilizzo elevato di CPU per le app Web.

Come si risolvono i problemi di uno scenario con utilizzo elevato di memoria?

In alcuni scenari di utilizzo elevato di memoria, l'app può richiedere realmente più risorse di calcolo. In tal caso, prendere in considerazione il passaggio a un livello di servizio superiore per fornire tutte le risorse necessarie all'applicazione. In altri casi, un bug nel codice può causare una perdita di memoria. Anche una procedura di codifica può provocare un maggiore utilizzo di memoria. La procedura che consente di ottenere informazioni su cosa provochi un utilizzo elevato di memoria prevede due parti. Creare prima un dump dei processi e analizzarlo. Crash Diagnoser della raccolta di estensioni sito di Azure può eseguire in modo efficiente entrambi questi passaggi. Per altre informazioni, vedere Acquisire e analizzare un file di dump per l'utilizzo elevato intermittente di memoria per le app Web.

Come si automatizzano le app Web del servizio app usando PowerShell?

È possibile usare i cmdlet di PowerShell per gestire le app Web del servizio app. Il post di blog Automatizzare le app Web ospitate nel servizio app di Azure usando PowerShell descrive come usare i cmdlet di PowerShell basati su Azure Resource Manager per automatizzare attività comuni. Il post di blog offre anche codice di esempio per diverse attività di gestione delle app Web. Per le descrizioni e la sintassi di tutti i cmdlet delle app Web del servizio app, vedere Az.Websites.

Come si possono visualizzare i log eventi dell'app Web?

Per visualizzare i log eventi dell'app Web:

  1. Accedere al sito Web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
  2. Nel menu selezionare Debug Console (Console di debug)>CMD.
  3. Selezionare la cartella LogFiles.
  4. Per visualizzare i log eventi, selezionare l'icona della matita accanto a eventlog.xml.
  5. Per scaricare i log, eseguire il cmdlet Save-AzureWebSiteLog -Name webappname di PowerShell.

Come si acquisisce un dump della memoria in modalità utente per l'app Web?

Per acquisire un dump della memoria in modalità utente per l'app Web:

  1. Accedere al sito Web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
  2. Selezionare il menu Process Explorer (Esplora processi).
  3. Fare clic con il pulsante destro del mouse sul processo w3wp.exe o sul proprio processo Web.
  4. Selezionare Download Memory Dump (Scarica dump di memoria)>Full Dump (Dump completo).

Come si visualizzano le informazioni a livello di processo per l'app Web?

Sono disponibili due opzioni per la visualizzazione di informazioni a livello di processo per l'app Web:

  • Nel portale di Azure:
    1. Aprire Process Explorer (Esplora processi) per l'app Web.
    2. Per visualizzare i dettagli, selezionare il processo w3wp.exe.
  • Nella console Kudu:
    1. Accedere al sito Web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
    2. Selezionare il menu Process Explorer (Esplora processi).
    3. Per il processo w3wp.exe selezionare Properties (Proprietà).

Quando si passa all'app, viene visualizzato l'errore "Errore 403 - Questa app Web è stata arrestata". Ricerca per categorie risolvere questo problema?

Questo errore può essere causato da tre condizioni:

  • È stato raggiunto un limite di fatturazione per l'app Web e il sito è stato disabilitato.
  • L'app Web è stata arrestata nel portale.
  • L'app Web ha raggiunto un limite di quota per le risorse che può essere applicabile a un piano di servizio Gratuito o Condiviso.

Per visualizzare la causa dell'errore e risolvere il problema, seguire i passaggi in App Web: "Errore 403. L'app Web è arrestata".

Dove si trovano altre informazioni su quote e limiti per i vari piani del servizio app?

Per informazioni su quote e limiti, vedere Limiti relativi al servizio app.

Come si riduce il tempo di risposta per la prima richiesta dopo il tempo di inattività?

Per impostazione predefinita, le app Web vengono scaricate se sono inattive per un periodo di tempo impostato. Ciò consente al sistema di conservare le risorse. Lo svantaggio è che la risposta alla prima richiesta dopo aver scaricato l'app Web richiede più tempo per consentire all'app Web di caricarsi e iniziare a gestire le risposte. Nei piani di servizio Basic e Standard, è possibile attivare l'impostazione Sempre online per mantenere l'app sempre caricata. In questo modo si evitano tempi di caricamento lunghi dopo l'inattività dell'app. Per modificare l'impostazione Sempre online:

  1. Nel portale di Azure passare all'app Web.
  2. Selezionare Configurazione
  3. Selezionare Impostazioni generali.
  4. Per Sempre online selezionare Sì.

Come si abilita la traccia delle richieste non riuscite?

Per attivare la traccia delle richieste non riuscite, seguire questa procedura:

  1. Nel portale di Azure passare all'app Web.

  2. Selezionare Tutte le impostazioni>Log di diagnostica.

  3. Per Traccia delle richieste non riuscite selezionare Sì.

  4. Selezionare Salva.

  5. Nel pannello dell'app Web selezionare Strumenti.

  6. Selezionare Visual Studio Online.

  7. Se l'impostazione non è Attivata, selezionare Sì.

  8. Selezionare Vai.

  9. Selezionare Web.config.

  10. In system.webServer aggiungere la configurazione seguente (per acquisire un URL specifico):

    <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. Per risolvere i problemi di prestazioni lente, aggiungere questa configurazione se la richiesta di acquisizione richiede più di 30 secondi:

    <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. Per scaricare le tracce di richieste non riuscite, nel portale passare al sito Web.

  13. Select Strumenti>Kudu>Vai.

  14. Nel menu selezionare Debug Console (Console di debug)>CMD.

  15. Selezionare la cartella LogFiles e quindi la cartella con un nome che inizia con W3SVC.

  16. Per visualizzare il file XML, selezionare l'icona della matita.

Viene visualizzato il messaggio "Processo di lavoro richiesto riciclo a causa del limite di memoria percentuale". Ricerca per categorie risolvere questo problema?

La quantità massima di memoria per un processo a 32 bit è 2 GB, anche in un sistema operativo a 64 bit. Per impostazione predefinita, il processo di lavoro è impostato su 32 bit nel servizio app, per compatibilità con le applicazioni Web legacy.

Valutare se passare a processi a 64 bit per poter sfruttare la memoria aggiuntiva disponibile nel ruolo di lavoro Web. Questa azione attiva un riavvio dell'app Web, quindi pianificarla opportunamente.

Si noti anche che un ambiente a 64 bit richiede il piano di servizio Basic o Standard. I piani Gratuito e Condiviso vengono eseguiti sempre in un ambiente a 32 bit.

Per altre informazioni, vedere Configurare le app Web nel servizio app.

Perché la richiesta raggiunge il timeout dopo 230 secondi?

Azure Load Balancer ha un'impostazione predefinita di quattro minuti per il timeout di inattività. Questa impostazione corrisponde in genere di un limite di tempo di risposta ragionevole per una richiesta web. pertanto, servizio app restituisce un timeout al client se l'applicazione non restituisce una risposta entro circa 240 secondi (230 secondi nell'app Windows, 240 secondi nell'app Linux).　Se l'app Web richiede l'elaborazione in background, è consigliabile usare Processi Web di Azure. L'app Web di Azure può chiamare Processi Web e ricevere una notifica al termine dell'elaborazione in background. È possibile scegliere tra più metodi per l'uso di Processi Web, tra cui le code e i trigger.

Processi Web è progettato per l'elaborazione in background. In un processo Web non vengono applicati limiti all'elaborazione in background. Per altre informazioni su Processi Web, vedere Eseguire attività in background con Processi Web.

A volte le applicazioni ASP.NET Core ospitate nel servizio app si bloccano. Come si risolve il problema?

Un problema noto con una versione di Kestrel precedente potrebbe provocare il blocco intermittente di un'app ASP.NET Core 1.0 ospitata nel servizio app. Potrebbe essere visualizzato il messaggio: "L'applicazione CGI specificata ha rilevato un errore e il server ha interrotto il processo".

Il problema è stato risolto in Kestrel versione 1.0.2. Questa versione è inclusa nell'aggiornamento di ASP.NET Core 1.0.3. Per risolvere questo problema, aggiornare le dipendenze app per l'uso di Kestrel 1.0.2. In alternativa è possibile usare una delle due soluzioni descritte nel post di blog Problemi di prestazioni lente di ASP.NET Core 1.0 nelle app Web del servizio app.

Non è possibile trovare i file di log nella struttura di file dell'app Web. Come si possono trovare?

Se si usa la funzionalità di cache locale del servizio app, la struttura delle cartelle LogFiles e Data per l'istanza di servizio App sono interessate. Quando si usa la cache locale, vengono create sottocartelle nelle cartelle LogFiles e Data dell'archivio. Le sottocartelle usano il modello di denominazione "identificatore univoco" + timestamp. Ogni sottocartella corrisponde a un'istanza di VM in cui l'app Web è o era in esecuzione.

Per determinare se si usa la cache locale, controllare la scheda impostazioni dell'applicazione servizio app. Se viene usata la cache locale, l'impostazione WEBSITE_LOCAL_CACHE_OPTION dell'app è impostata su Always.

Se non si usa la cache locale e si verifica questo problema, inviare una richiesta di supporto.

Viene visualizzato il messaggio "È stato effettuato un tentativo di accesso a un socket in modo non consentito dalle autorizzazioni di accesso". Ricerca per categorie risolvere l'errore?

Questo errore si verifica in genere quando si esauriscono le connessioni TCP in uscita nell'istanza della VM. Nel servizio app, i limiti vengono applicati per il numero massimo di connessioni in uscita che possono essere eseguite per ogni istanza della VM. Per altre informazioni, vedere Cross-VM numerical limits (Limiti numerici tra VM).

Questo errore può verificarsi anche se si prova ad accedere a un indirizzo locale dall'applicazione. Per altre informazioni, vedere Local address requests (Richieste di indirizzi locali).

Per altre informazioni sulle connessioni in uscita nell'app Web, vedere il post di blog sulle connessioni in uscita a siti Web di Azure.

Come si usa Visual Studio per eseguire il debug remoto dell'app Web del servizio app?

Per una procedura dettagliata che illustra come eseguire il debug dell'app Web usando Visual Studio, vedere Remote debug your App Service web app (Eseguire il debug remoto dell'app Web del servizio app).

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.