2009-09-17 16 views
13

Ho un sito web ASP.NET 3.5 in esecuzione sotto IIS7 su Windows 2008.applicazione ASP.NET su IIS7 - molto lento avvio dopo iisreset

Quando ho riavviare IIS (iisreset), poi ha colpito una pagina, la prima messa in servizio è veramente lento.

vedo la seguente attività di Process Explorer:

  • depone le uova w3wp.exe, ma mostra 0% della CPU attività per circa 60 secondi
  • Infine, w3wp.exe va al 50% della CPU per circa 5 secondi e poi i carichi della pagina .

Non vedo altri processi che utilizzano la CPU durante questo periodo. In pratica si blocca.

Cosa succede durante tutto questo tempo? Come posso rintracciare cosa sta prendendo tutto questo tempo?

risposta

4

Ho trovato che c'era un ritardo di rete che effettua una connessione iniziale dal server Web front-end al server del database.

Il problema riguardava Windows 2008 e il nostro hardware di rete specifico.

La risoluzione è stato quello di disabilitare il seguente sui server web:

4

IL viene convertito in codice nativo della macchina (Assembly) dal compilatore Just-In-Time e si arriva ad aspettare mentre tutta la magia accade.

Quando si compila il codice sorgente per codice gestito, il compilatore traduce la fonte in Microsoft intermedio lingua (MSIL). Questo è un set di istruzioni indipendente dalla CPU che può essere convertito in modo efficiente nel codice nativo . Microsoft intermedia lingua (MSIL) è una traduzione utilizzata come l'output di un numero di compilatori . È l'input per un compilatore JIT (just-in-time) . Il Common Language Runtime include un compilatore JIT per la conversione di MSIL nel codice nativo .

Prima di Microsoft Intermediate Language (MSIL) può essere eseguito esso, deve essere convertito da .NET Framework just-in-time (JIT) in codice nativo . Questo è il codice specifico della CPU che viene eseguito sulla stessa architettura del computer come compilatore JIT. Piuttosto che usare il tempo e la memoria per convertire tutto il file MSIL in un file eseguibile portatile (PE) in codice nativo. Converte l'MSIL come necessario durante l'esecuzione, quindi memorizza nella cache il codice nativo risultante in modo che sia accessibile per tutte le successive chiamate .

source

+0

Se fosse JIT compilazione, non dovrei vedere csc.exe in Process Explorer? Non vedo csc.exe in esecuzione durante i 60 secondi di attesa. – frankadelic

+0

@frankadelic csc.exe è il compilatore C#. Il JIT è parte di .NET e perché .NET deve essere installato su macchine che eseguono C#. –

+0

Se fosse csc o JIT, vedresti l'utilizzo della CPU. –

4

Quella è la compilazione di pagine ASP.NET in linguaggio intermedio + compilazione JIT - succede solo la prima volta che la pagina viene caricata. (Vedi http://msdn.microsoft.com/en-us/library/ms366723.aspx)

Se davvero ti infastidisce, puoi impedire che ciò accada pre-compilando il tuo sito.

MODIFICA: Basta rileggere la domanda: 60 secondi sono molto lunghi e ci si aspetterebbe di vedere alcune attività del processore durante quel periodo.Controllare EventLog per errori/messaggi nelle destinazioni di Sistema e Applicazione. Prova anche a creare un crash dump del processo w3wp durante questi 60 secondi: c'è la possibilità che tu possa riconoscere ciò che sta facendo guardando alcuni degli stack di chiamate.

Se ci vuole esattamente 60 secondi ogni volta poi la sua probabile che la sua attesa di qualcosa da Time Out - 60 secondi è un bel numero tondo. Assicurati che abbia connessioni adeguate ai controller di dominio, ecc ...

(Se ci sono alcuni strumenti di diagnostica IIS che farebbero un lavoro migliore allora temo di non essere a conoscenza di loro, questa domanda potrebbe essere più adatto a ServerFault, il precedente è un approccio molto più sviluppatore alla risoluzione dei problemi :-p)

+0

come menzionato in altri commenti: non vedo alcun csc.exe in esecuzione durante questo ritardo. – frankadelic

1

Questo cappello non ha nulla a che fare con la compilazione JIT. Il normale compilatore C# compila il codice dietro i file (.aspx.cs) in linguaggio intermedio in un assembly all'avvio se questo assembly non esiste oi file di codice sono stati modificati. L'assieme del tuo sito web si trova nella cartella "bin" del tuo sito web.

In effetti la compilazione JIT si verifica dopo, ma questo è molto veloce e non richiederà alcuni minuti. Compilazione JIT avviene ad ogni avvio di un'applicazione .net e non richiede più di una visualizzazione per secondi.

È possibile evitare il copmpiling del sito Web se si distribuisce l'assembly del sito Web già compilato (YourWebsite.dll) nella cartella bin. È anche possibile distribuire solo i file aspx e lasciare il codice dietro i file (aspx.cs).

+0

In realtà, anche con un sito precompilato, i file .aspx, .ascx, ecc. Vengono analizzati nel codice C#, compilato e poi JIT. Quindi c'è molta attività quando si riscalda un'applicazione ASP.NET per la prima volta. – Kev

2

Più di 60 secondi suona pesce. Prova a eseguire una pagina test.html per vedere quanto tempo ci vuole. Questo isolerà il ruolo di IIS7.

Quindi rinominare temporaneamente le cartelle web.config, global.asax e dell'applicazione e provare una pagina test.aspx (pagina molto semplice). Questo isolerà ASP.NET.

Se entrambi sono veloci (ovvero circa 10 secondi), allora è la vostra applicazione. Ma, se entrambi sono lenti allora non l'applicazione e qualcosa con il server stesso.

+0

La pagina HTML di test è durata circa 2 secondi dopo l'iisreset. Se IIS era in esecuzione e cambio web.config, ci vogliono circa 3 secondi per caricare una pagina ASPX di test. – frankadelic

+3

Sembra che IIS e ASP.NET stiano andando bene. Deve essere qualcosa nell'app che sta causando questo. Se è solo lento al primo caricamento, è la conversazione in codice nativo. Hai un progetto enorme? Esaminerò il tipo e le dimensioni del tuo progetto e vedremo come suddividerlo in parti o pre-compilare prima di caricarlo sul server. –

6

Abbiamo avuto un problema simile e si è verificato il controllo del timeout di Windows per la revoca dei certificati di firma. Verifica se il tuo server sta tentando di chiamare da qualche parte (ad esempio, crl.microsoft.com). Forse hai un'impostazione proxy errata? O un firewall nel modo? Alla fine abbiamo determinato che avevamo abbastanza controllo sul server e non volevamo "chiamare casa", quindi abbiamo semplicemente disabilitato il controllo. È possibile farlo con .NET 2.0 SP1 e versioni successive aggiungendo quanto segue a machine.config.

<runtime> <generatePublisherEvidence enabled="false"/> </runtime> 

Non sono sicuro di poterlo inserire nell'app.config/web.config.