Correzione del caricamento iniziale lento per IIS


129

IIS ha una funzione fastidiosa per i siti Web a basso traffico in cui ricicla i processi di lavoro inutilizzati, facendo sì che il primo utente al sito dopo un po 'di tempo ottenga un ritardo estremamente lungo (oltre 30 secondi).

Ho cercato una soluzione al problema e ho trovato queste potenziali soluzioni.

A. Utilizzare il plug-in di inizializzazione dell'applicazione

B. Utilizzare Auto-Start con .NET 4

C. Disabilitare il timeout di inattività (in Ripristino IIS)

D. Precompila il sito

Mi chiedo quale di questi sia preferito e, cosa ancora più importante, perché ci sono così tante soluzioni allo stesso problema? (La mia ipotesi è che non lo sono, e non sto capendo qualcosa correttamente).

modificare

L'esecuzione di C sembra essere abbastanza per riscaldare il mio sito, ma ho scoperto che la vera radice della lentezza del mio sito ha a che fare con Entity Framework, che non riesco a capire perché stia diventando freddo. Vedi questa domanda, che purtroppo non ha ancora ricevuto risposta!

Alla fine ho dovuto solo fare uno script di riscaldamento per colpire il mio sito di tanto in tanto per assicurarmi che rimanesse veloce.


Ciao amico, l'esecuzione di C è abbastanza? Perché ? Dobbiamo solo usarlo o disabilitare anche il riciclaggio? Sento sempre la prima richiesta del secondo giorno molto lenta di IIS7.5
qakmak,

Risposte:


36

Le opzioni A, B e D sembrano essere nella stessa categoria poiché influenzano solo l'ora di inizio iniziale, eseguono il riscaldamento del sito Web come la compilazione e il caricamento delle librerie in memoria.

L'uso di C, l'impostazione del timeout di inattività, dovrebbe essere sufficiente affinché le successive richieste al server vengano soddisfatte rapidamente (il riavvio del pool di app richiede parecchio tempo, nell'ordine dei secondi).

Per quanto ne so, il timeout esiste per risparmiare memoria di cui potrebbero aver bisogno altri siti Web in esecuzione su quella macchina in parallelo. Il prezzo è quel tempo di caricamento lento una volta.

Oltre al fatto che il pool di app viene arrestato in caso di inattività dell'utente, il pool di app verrà riciclato per impostazione predefinita ogni 1740 minuti (29 ore).

Da technet:

I pool di applicazioni di Internet Information Services (IIS) possono essere periodicamente riciclati per evitare stati instabili che possono causare arresti anomali, blocchi o perdite di memoria delle applicazioni.

Finché il riciclo del pool di app rimane attivo, dovrebbe essere sufficiente. Ma se vuoi davvero prestazioni di altissimo livello per la maggior parte dei componenti, dovresti anche usare qualcosa come il Modulo di inizializzazione dell'applicazione che hai citato.


Quindi consiglieresti di disabilitare il timeout di inattività? Ciò causerebbe problemi lungo la linea (immagino che sia lì per un motivo)?
Cavyn VonDeylen,

3
Questo in realtà non risolve il mio problema (vedi la mia modifica), ma ho accettato poiché hai risposto alla mia domanda originale.
Cavyn VonDeylen,

10

Sfida di web hosting

È necessario ricordare che nessuna delle opzioni di configurazione della macchina è disponibile se si è ospitati su un server condiviso come lo sono molti di noi (piccole aziende e singoli).

ASP.NET MVC Overhead

Il mio sito impiega almeno 30 secondi quando non viene colpito da oltre 20 minuti (e l'app Web è stata interrotta). È terribile.

Un altro modo per testare le prestazioni

C'è un altro modo per testare se è il tuo avvio ASP.NET MVC o qualcos'altro. Rilascia una normale pagina HTML sul tuo sito dove puoi accedervi direttamente.
Se il problema è correlato all'avvio di ASP.NET MVC, la pagina HTML verrà visualizzata quasi immediatamente anche quando l'app Web non è stata avviata.
È così che ho riconosciuto per la prima volta che il problema era all'avvio di ASP.NET MVC. Ho caricato una pagina HTML in qualsiasi momento e si sarebbe caricato velocemente. Quindi, dopo aver colpito quella pagina HTML, ho colpito uno dei miei URL MVC ASP.NET e ho ricevuto il messaggio Chrome "Aspettando raddev.us ..."

Un altro test con script utili

Successivamente ho scritto uno script LINQPad (controlla http://linqpad.net per ulteriori informazioni) che dovrebbe colpire il mio sito Web ogni 8 minuti (meno del tempo necessario per scaricare l'app - che dovrebbe essere di 20 minuti) e ho lasciato funziona per ore.

Mentre la sceneggiatura era in esecuzione, ho colpito il mio sito Web e ogni volta che il mio sito si accendeva incredibilmente veloce. Questo mi dà una buona idea che molto probabilmente la lentezza che stavo vivendo era a causa dei tempi di avvio di ASP.NET MVC.

Ottieni LinqPad e puoi eseguire il seguente script: basta cambiare l'URL con il tuo e lasciarlo funzionare e puoi testarlo facilmente. In bocca al lupo.

NOTA : in LinqPad dovrai premere F4 e aggiungere un riferimento a System.Net per aggiungere la libreria che recupererà la tua pagina.

ANCHE : assicurati di modificare la variabile URL stringa in modo che punti a un URL che caricherà una route dal tuo sito ASP.NET MVC in modo che il motore venga eseguito.

System.Timers.Timer webKeepAlive = new System.Timers.Timer();
Int64 counter = 0;
void Main()
{
    webKeepAlive.Interval = 5000;
    webKeepAlive.Elapsed += WebKeepAlive_Elapsed;
    webKeepAlive.Start();
}

private void WebKeepAlive_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
    webKeepAlive.Stop();
    try
    {
        // ONLY the first time it retrieves the content it will print the string
        String finalHtml = GetWebContent();
        if (counter < 1)
        {
            Console.WriteLine(finalHtml);
        }
        counter++;
    }
    finally
    {
        webKeepAlive.Interval = 480000; // every 8 minutes
        webKeepAlive.Start();
    }
}

public String GetWebContent()
{
    try
    {
    String URL = "http://YOURURL.COM";
    WebRequest request = WebRequest.Create(URL);
    WebResponse response = request.GetResponse();
    Stream data = response.GetResponseStream();
    string html = String.Empty;
    using (StreamReader sr = new StreamReader(data))
    {
        html = sr.ReadToEnd();
    }
    Console.WriteLine (String.Format("{0} : success",DateTime.Now));
    return html;
    }
    catch (Exception ex)
    {
        Console.WriteLine (String.Format("{0} -- GetWebContent() : {1}",DateTime.Now,ex.Message));
        return "fail";
    }
}

3

Scrivere un servizio ping / script per colpire il tuo sito Web inattivo è piuttosto il modo migliore per andare perché avrai un controllo completo. Altre opzioni che hai menzionato sarebbero disponibili se hai noleggiato una casella di hosting dedicata.

In uno spazio di hosting condiviso, gli script di warmup sono la migliore difesa di primo livello (l'auto-aiuto è il miglior aiuto). Ecco un articolo che condivide un'idea su come farlo dalla propria applicazione web .


ho appena aggiornato questo vecchio thread, nel caso in cui qualcuno cerchi lo stesso
David Chelliah,

2

Userei B perché, in combinazione con il riciclaggio dei processi dei lavoratori, significa che ci sarebbe solo un ritardo durante il riciclaggio. Ciò evita il ritardo normalmente associato all'inizializzazione in risposta alla prima richiesta dopo inattività. Puoi anche conservare i vantaggi del riciclaggio.


2

Una buona opzione per eseguire il ping del sito in base a una pianificazione è utilizzare Microsoft Flow, che è gratuito per un massimo di 750 "esecuzioni" al mese. È molto facile creare un flusso che raggiunga il tuo sito ogni ora per tenerlo al caldo. Puoi persino aggirare il loro limite di 750 creando un singolo flusso con ritardi che separano più hit del tuo sito.

https://flow.microsoft.com


1

Consulta questo articolo per suggerimenti su come aiutare i problemi di prestazioni. Ciò include entrambi i problemi di prestazioni relativi all'avvio, nella sezione "avvio a freddo". La maggior parte di ciò non importa quale tipo di server si sta utilizzando, localmente o in produzione.

http://blogs.msdn.com/b/mcsuksoldev/archive/2011/01/19/common-performance-issues-on-asp-net-web-sites.aspx

Se l'applicazione deserializza qualcosa dall'XML (e che include i servizi Web ...), assicurati che SGEN sia eseguito contro tutti i binari coinvolti nella deseriaizzazione e posiziona le DLL risultanti nella Global Assembly Cache (GAC). Ciò precompila tutti gli oggetti di serializzazione utilizzati dagli assembly SGEN è stato eseguito e li memorizza nella cache risultante. Ciò può consentire enormi risparmi di tempo sulla prima deserializzazione (caricamento) dei file di configurazione dal disco e le chiamate iniziali ai servizi Web. http://msdn.microsoft.com/en-us/library/bk3w6240(VS.80).aspx

Se alcuni server IIS non hanno accesso in uscita a Internet, disattivare l'elenco di revoche di certificati (CRL) controllando i binari Authenticode aggiungendo generatePublisherEvidence = "false" in machine.config. In caso contrario, tutti i processi di lavoro possono rimanere in sospeso per oltre 20 secondi durante l'avvio mentre scade il tentativo di connettersi a Internet per ottenere un elenco CRL. http://blogs.msdn.com/amolravande/archive/2008/07/20/startup-performance-disable-the-generatepublisherevidence-property.aspx

http://msdn.microsoft.com/en-us/library/bb629393.aspx

Prendi in considerazione l'utilizzo di NGEN su tutti gli assiemi. Tuttavia, senza un uso attento, ciò non offre un notevole miglioramento delle prestazioni. Questo perché gli indirizzi di caricamento di base di tutti i file binari caricati da ciascun processo devono essere impostati con cura al momento della compilazione per non sovrapporsi. Se i binari devono essere ridisegnati quando vengono caricati a causa di conflitti di indirizzi, quasi tutti i guadagni in termini di prestazioni derivanti dall'utilizzo di NGEN andranno persi. http://msdn.microsoft.com/en-us/magazine/cc163610.aspx


0

Stavo ottenendo un ritardo consistente di 15 secondi sulla prima richiesta dopo 4 minuti di inattività. Il mio problema era che la mia app utilizzava l'autenticazione integrata di Windows in SQL Server e il profilo del servizio si trovava in un dominio diverso rispetto al server. Ciò ha causato un'autenticazione tra domini da IIS a SQL al momento dell'inizializzazione dell'app - e questa è stata la vera fonte del mio ritardo. Sono passato all'utilizzo di un login SQL anziché dell'autenticazione di Windows. Il ritardo è immediatamente scomparso. Sono ancora presenti tutte le impostazioni di inizializzazione dell'app per aiutare a migliorare le prestazioni, ma nel mio caso potrebbero non essere affatto necessarie.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.