Domande frequenti sulle prestazioni delle applicazioni per App Web in Azure

Articolo
07/17/2023

Nota

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

Questo articolo contiene le risposte alle domande frequenti sui problemi di prestazioni delle applicazioni per la funzionalità App Web di Servizio app di Azure.

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

Perché il piano di servizio app visualizza l'utilizzo di CPU/memoria anche quando tutti i App Web vengono arrestati?

Servizio app di Azure 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à fondamentali dell'app Web.

I processi di sistema verranno eseguiti in piani di servizio app anche se non sono presenti App Web in esecuzione 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 i passaggi dettagliati per la risoluzione dei problemi, vedere Risolvere i problemi relativi alle prestazioni lente delle app Web.

Ricerca per categorie risolvere i problemi relativi a uno scenario a consumo elevato di CPU?

In alcuni scenari a consumo elevato di CPU, l'app potrebbe effettivamente richiedere più risorse di calcolo. In tal caso, prendere in considerazione il ridimensionamento a un livello di servizio superiore in modo che l'applicazione ottenga tutte le risorse necessarie. Altre volte, l'utilizzo elevato della CPU potrebbe essere causato da un ciclo non valido o da una procedura di codifica. Ottenere informazioni dettagliate su ciò che comporta un aumento del consumo di CPU è un processo in due parti. Prima di tutto, creare un dump del processo e quindi analizzare il dump del processo. Per altre informazioni, vedere Acquisire e analizzare un file di dump per un utilizzo elevato della CPU per App Web.

Ricerca per categorie risolvere uno scenario a consumo elevato di memoria?

In alcuni scenari a consumo elevato di memoria, l'app potrebbe effettivamente richiedere più risorse di calcolo. In tal caso, prendere in considerazione il ridimensionamento a un livello di servizio superiore in modo che l'applicazione ottenga tutte le risorse necessarie. Altre volte, un bug nel codice potrebbe causare una perdita di memoria. Una procedura di codifica potrebbe anche aumentare il consumo di memoria. Ottenere informazioni dettagliate su ciò che attiva un consumo elevato di memoria è un processo in due parti. Prima di tutto, creare un dump del processo e quindi analizzare il dump del processo. Diagnosticare l'arresto anomalo della raccolta di estensioni del sito di Azure può eseguire in modo efficiente entrambi questi passaggi. Per altre informazioni, vedere Acquisire e analizzare un file di dump per individuare memoria elevata intermittente per App Web.

Ricerca per categorie automatizzare servizio app app Web usando PowerShell?

È possibile usare i cmdlet di PowerShell per gestire e gestire servizio app app Web. Nel post di blog Automatizzare le app Web ospitate in Servizio app di Azure tramite PowerShell viene descritto come usare i cmdlet di PowerShell basati su Azure Resource Manager per automatizzare le attività comuni. Il post di blog contiene anche codice di esempio per varie attività di gestione delle app Web. Per descrizioni e sintassi per tutti i cmdlet di app Web servizio app, vedere Az.Websites.

Ricerca per categorie visualizzare i log eventi dell'app Web?

Per visualizzare i log eventi dell'app Web:

Accedere al sito Web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
Nel menu selezionareCmd console >di debug.
Selezionare la cartella LogFiles .
Per visualizzare i log eventi, selezionare l'icona a matita accanto a eventlog.xml.
Per scaricare i log, eseguire il cmdlet Save-AzureWebSiteLog -Name webappnamedi PowerShell .

Ricerca per categorie acquisire un dump di memoria in modalità utente dell'app Web?

Per acquisire un dump di memoria in modalità utente dell'app Web:

Accedere al sito Web Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
Selezionare il menu Esplora processi .
Fare clic con il pulsante destro del mouse sul processo w3wp.exe o sul processo del processo Web.
Selezionare Scarica dump>di memoria completo.

Ricerca per categorie visualizzare le informazioni a livello di processo per l'app Web?

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

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

Quando si passa all'app, viene visualizzato "Errore 403 - Questa app Web viene arrestata". Ricerca per categorie risolvere il caso?

Questo errore può essere causato da tre condizioni:

L'app Web ha raggiunto un limite di fatturazione e il sito è stato disabilitato.
L'app Web è stata arrestata nel portale.
L'app Web ha raggiunto un limite di quota di risorse che può essere applicato a un piano di servizio con scalabilità gratuita o condivisa.

Per visualizzare la causa dell'errore e risolvere il problema, seguire la procedura descritta in App Web: "Errore 403 - Questa app Web viene arrestata".

Dove è possibile ottenere altre informazioni sulle quote e i limiti per vari piani di servizio app?

Per informazioni su quote e limiti, vedere servizio app limiti.

Ricerca per categorie ridurre 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 determinato periodo di tempo. In questo modo, il sistema può risparmiare risorse. Il lato negativo è che la risposta alla prima richiesta dopo il caricamento dell'app Web è più lunga, per consentire all'app Web di caricare e iniziare a gestire le risposte. Nei piani di servizio Basic e Standard è possibile attivare l'impostazione Always On per mantenere l'app sempre caricata. In questo modo si eliminano tempi di caricamento più lunghi dopo che l'app è inattiva. Per modificare l'impostazione Always On:

Nel portale di Azure passare all'app Web.
Selezionare Configurazione
Selezionare Impostazioni generali.
Per Always On selezionare Sì.

Ricerca per categorie attivare la traccia delle richieste non riuscite?

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

Nel portale di Azure passare all'app Web.
Selezionare Tutti ilog di diagnosticadelle impostazioni>.
Per Traccia richiesta non riuscita selezionare Sì.
Selezionare Salva.
Nel pannello dell'app Web selezionare Strumenti.
Selezionare Visual Studio Online.
Se l'impostazione non è attivata, selezionare Sì.
Seleziona Vai.
Selezionare Web.config.

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>

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>

Per scaricare le tracce delle richieste non riuscite, nel portale passare al sito Web.
Selezionare Strumenti>Kudu>Go.
Nel menu selezionareCmd console >di debug.
Selezionare la cartella LogFiles e quindi selezionare la cartella con un nome che inizia con W3SVC.
Per visualizzare il file XML, selezionare l'icona a matita.

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

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

Prendere in considerazione il passaggio a processi a 64 bit in modo da poter sfruttare la memoria aggiuntiva disponibile nel ruolo di lavoro Web. Questa azione attiva il riavvio di un'app Web, quindi pianifica di conseguenza.

Si noti inoltre che un ambiente a 64 bit richiede un piano di servizio Basic o Standard. I piani gratuiti e condivisi vengono sempre eseguiti in un ambiente a 32 bit.

Per altre informazioni, vedere Configurare app Web in servizio app.

Perché la richiesta scade dopo 230 secondi?

Azure Load Balancer ha un'impostazione di timeout di inattività predefinita di quattro minuti. Questa impostazione è in genere 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 di 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 code e trigger.

WebJobs è progettato per l'elaborazione in background. È possibile eseguire l'elaborazione in background desiderata in un processo Web. Per altre informazioni sui processi Web, vedere Eseguire attività in background con processi Web.

ASP.NET Core applicazioni ospitate in servizio app a volte smette di rispondere. Ricerca per categorie risolvere questo problema?

Un problema noto con una versione precedente di Kestrel potrebbe causare l'arresto intermittente di un'app ASP.NET Core 1.0 ospitata in servizio app. Potrebbe essere visualizzato anche questo messaggio: "L'applicazione CGI specificata ha rilevato un errore e il server ha terminato il processo".

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

Non è possibile trovare i file di log nella struttura dei file dell'app Web. Come posso trovarli?

Se si usa la funzionalità Cache locale di servizio app, la struttura di cartelle delle cartelle LogFiles e Data per l'istanza di servizio app è interessata. Quando si usa Cache locale, le sottocartelle vengono create nelle cartelle LogFiles e Dati di archiviazione. Le sottocartelle usano il modello di denominazione "identificatore univoco" + timestamp. Ogni sottocartella corrisponde a un'istanza di macchina virtuale in cui l'app Web è in esecuzione o è in esecuzione.

Per determinare se si usa cache locale, controllare la scheda Impostazioni applicazione servizio app. Se si usa Cache locale, l'impostazione WEBSITE_LOCAL_CACHE_OPTION dell'app è impostata Alwayssu .

Se non si usa 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 un modo negato dalle relative autorizzazioni di accesso". Ricerca per categorie risolvere l'errore?

Questo errore si verifica in genere se le connessioni TCP in uscita nell'istanza di macchina virtuale sono esaurite. In servizio app vengono applicati limiti per il numero massimo di connessioni in uscita che è possibile effettuare per ogni istanza di macchina virtuale. Per altre informazioni, vedere Limiti numerici tra macchine virtuali.

Questo errore può verificarsi anche se si tenta di accedere a un indirizzo locale dall'applicazione. Per altre informazioni, vedere Richieste di indirizzi locali.

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

Ricerca per categorie usare Visual Studio per eseguire il debug remoto dell'app Web servizio app?

Per una procedura dettagliata che illustra come eseguire il debug dell'app Web usando Visual Studio, vedere Eseguire il debug remoto dell'app Web 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.