Behebung einer langsamen Anfangslast für IIS


129

IIS verfügt über eine lästige Funktion für Websites mit geringem Datenverkehr, bei der nicht verwendete Arbeitsprozesse recycelt werden. Dadurch erhält der erste Benutzer nach einiger Zeit eine extrem lange Verzögerung (über 30 Sekunden).

Ich habe nach einer Lösung für das Problem gesucht und diese möglichen Lösungen gefunden.

A. Verwenden Sie das Plugin zur Anwendungsinitialisierung

B. Verwenden Sie den automatischen Start mit .NET 4

C. Deaktivieren Sie das Leerlaufzeitlimit (unter IIS-Reset).

D. Kompilieren Sie die Site vor

Ich frage mich, welche davon bevorzugt wird, und was noch wichtiger ist, warum gibt es so viele Lösungen für dasselbe Problem? (Ich vermute, sie sind es nicht und ich verstehe etwas einfach nicht richtig).

Bearbeiten

Das Ausführen von C scheint genug zu sein, um meine Site warm zu halten, aber ich habe festgestellt, dass die wahre Wurzel der Langsamkeit meiner Site mit Entity Framework zu tun hat, was ich anscheinend nicht herausfinden kann, warum es kalt wird. Siehe diese Frage, die leider noch nicht beantwortet wurde, wurde beantwortet!

Ich musste schließlich nur ein Aufwärmskript erstellen , um gelegentlich auf meine Website zu gelangen und sicherzustellen, dass sie schnell blieb.


Hallo Freund, reicht es aus, C auszuführen? Warum ? Müssen wir es nur verwenden oder müssen wir es auch recycelt deaktivieren? Ich fühle mich immer am zweiten Tag erste Anfrage sehr langsam von IIS7.5
Qakmak

Antworten:


36

Die Optionen A, B und D scheinen in derselben Kategorie zu sein, da sie nur die anfängliche Startzeit beeinflussen und die Website wie das Kompilieren und Laden von Bibliotheken in den Speicher aufwärmen.

Die Verwendung von C zum Festlegen des Leerlaufzeitlimits sollte ausreichen, damit nachfolgende Anforderungen an den Server schnell bearbeitet werden können (der Neustart des App-Pools dauert einige Zeit - in der Größenordnung von Sekunden).

Soweit ich weiß, besteht das Zeitlimit, um Speicherplatz zu sparen, den andere Websites, die parallel auf diesem Computer ausgeführt werden, möglicherweise benötigen. Der Preis ist die einmalige langsame Ladezeit.

Neben der Tatsache, dass der App-Pool bei Inaktivität des Benutzers heruntergefahren wird, wird der App-Pool standardmäßig alle 1740 Minuten (29 Stunden) recycelt.

Von technet:

IIS-Anwendungspools (Internet Information Services) können regelmäßig recycelt werden, um instabile Zustände zu vermeiden, die zu Anwendungsabstürzen, Hängen oder Speicherverlusten führen können.

Solange das Recycling des App-Pools aktiviert ist, sollte dies ausreichen. Wenn Sie jedoch für die meisten Komponenten wirklich erstklassige Leistung erzielen möchten, sollten Sie auch das von Ihnen erwähnte Anwendungsinitialisierungsmodul verwenden.


Würden Sie empfehlen, nur das Leerlaufzeitlimit zu deaktivieren? Würde das Probleme auf der ganzen Linie verursachen (ich vermute, es gibt einen Grund dafür)?
Cavyn VonDeylen

3
Dies behebt mein Problem nicht wirklich (siehe meine Bearbeitung), aber ich habe akzeptiert, da Sie meine ursprüngliche Frage beantwortet haben.
Cavyn VonDeylen

10

Webhosting-Herausforderung

Sie müssen sich daran erinnern, dass keine der Maschinenkonfigurationsoptionen verfügbar ist, wenn Sie auf einem gemeinsam genutzten Server gehostet werden, wie es viele von uns (kleinere Unternehmen und Einzelpersonen) sind.

ASP.NET MVC-Overhead

Meine Website dauert mindestens 30 Sekunden, wenn sie seit mehr als 20 Minuten nicht mehr aufgerufen wurde (und die Web-App gestoppt wurde). Es ist schrecklich.

Eine andere Möglichkeit, die Leistung zu testen

Es gibt noch eine andere Möglichkeit zu testen, ob es sich um Ihren ASP.NET MVC-Start oder etwas anderes handelt. Legen Sie eine normale HTML-Seite auf Ihrer Website ab, auf die Sie direkt zugreifen können.
Wenn das Problem mit dem Start von ASP.NET MVC zusammenhängt, wird die HTML-Seite fast sofort gerendert, auch wenn die Webanwendung noch nicht gestartet wurde.
So erkannte ich zum ersten Mal, dass das Problem beim Start von ASP.NET MVC auftrat. Ich habe jederzeit eine HTML-Seite geladen und sie wurde blitzschnell geladen. Nachdem ich diese HTML-Seite aufgerufen hatte, traf ich eine meiner ASP.NET MVC-URLs und erhielt die Chrome-Meldung "Warten auf raddev.us ...".

Ein weiterer Test mit hilfreichem Skript

Danach schrieb ich ein LINQPad- Skript ( weitere Informationen finden Sie unter http://linqpad.net ), das alle 8 Minuten auf meine Website gelangt (weniger als die Zeit, die die App zum Entladen benötigt - das sollten 20 Minuten sein), und ließ es es läuft stundenlang.

Während das Skript ausgeführt wurde, habe ich meine Website aufgerufen und jedes Mal, wenn meine Website blitzschnell aufgerufen wurde. Dies gibt mir eine gute Vorstellung davon, dass die Langsamkeit, die ich hatte, höchstwahrscheinlich auf die Startzeiten von ASP.NET MVC zurückzuführen war.

Holen Sie sich LinqPad und Sie können das folgende Skript ausführen - ändern Sie einfach die URL in Ihre eigene und lassen Sie es laufen und Sie können dies einfach testen. Viel Glück.

HINWEIS : In LinqPad müssen Sie F4 drücken und einen Verweis auf System.Net hinzufügen, um die Bibliothek hinzuzufügen, die Ihre Seite abruft.

AUCH : Stellen Sie sicher, dass Sie die Variable String URL so ändern, dass sie auf eine URL verweist, die eine Route von Ihrer ASP.NET MVC-Site lädt, damit die Engine ausgeführt wird.

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

Das Schreiben eines Ping-Dienstes / Skripts für Ihre inaktive Website ist eher der beste Weg, da Sie die vollständige Kontrolle haben. Andere Optionen, die Sie erwähnt haben, sind verfügbar, wenn Sie eine dedizierte Hosting-Box geleast haben.

In einem gemeinsam genutzten Hosting-Bereich sind Aufwärmskripte die beste Verteidigung der ersten Ebene (Selbsthilfe ist die beste Hilfe). In diesem Artikel finden Sie eine Idee, wie Sie dies mit Ihrer eigenen Webanwendung tun können .


habe gerade diesen alten Thread aktualisiert, falls jemand danach sucht
David Chelliah

2

Ich würde B verwenden, weil dies in Verbindung mit dem Recycling von Arbeitsprozessen bedeutet, dass es nur eine Verzögerung beim Recycling geben würde. Dies vermeidet die Verzögerung, die normalerweise mit der Initialisierung als Antwort auf die erste Anforderung nach dem Leerlauf verbunden ist. Sie können auch die Vorteile des Recyclings beibehalten.


2

Eine gute Option, um die Site nach einem Zeitplan zu pingen, ist die Verwendung von Microsoft Flow, das für bis zu 750 "Läufe" pro Monat kostenlos ist. Es ist sehr einfach, einen Flow zu erstellen, der jede Stunde auf Ihre Website gelangt, um sie warm zu halten. Sie können sogar das Limit von 750 umgehen, indem Sie einen einzelnen Flow mit Verzögerungen erstellen, die mehrere Treffer Ihrer Website trennen.

https://flow.microsoft.com


1

In diesem Artikel finden Sie Tipps zur Behebung von Leistungsproblemen. Dies umfasst beide Leistungsprobleme im Zusammenhang mit dem Start im Abschnitt "Kaltstart". Das meiste davon spielt keine Rolle, egal welchen Servertyp Sie lokal oder in der Produktion verwenden.

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

Wenn die Anwendung etwas von XML deserialisiert (und dazu gehören auch Webdienste…), stellen Sie sicher, dass SGEN für alle an der Deseriaisierung beteiligten Binärdateien ausgeführt wird, und platzieren Sie die resultierenden DLLs im Global Assembly Cache (GAC). Dadurch werden alle von den Baugruppen, für die SGEN verwendet wurde, verwendeten Serialisierungsobjekte vorkompiliert und in der resultierenden DLL zwischengespeichert. Dies kann zu einer enormen Zeitersparnis bei der ersten Deserialisierung (Laden) von Konfigurationsdateien von der Festplatte und bei ersten Aufrufen von Webdiensten führen. http://msdn.microsoft.com/en-us/library/bk3w6240(VS.80).aspx

Wenn IIS-Server keinen ausgehenden Zugriff auf das Internet haben, deaktivieren Sie die CRL-Prüfung (Certificate Revocation List) für Authenticode-Binärdateien, indem Sie generatePublisherEvidence = "false" in machine.config hinzufügen. Andernfalls können alle Worker-Prozesse während des Startvorgangs länger als 20 Sekunden hängen bleiben, während das Zeitlimit für den Versuch, eine Verbindung zum Internet herzustellen, um eine CRL-Liste zu erhalten, abgelaufen ist. 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

Erwägen Sie die Verwendung von NGEN für alle Baugruppen. Ohne sorgfältige Verwendung führt dies jedoch nicht zu einem großen Leistungsgewinn. Dies liegt daran, dass die Basisladeadressen aller Binärdateien, die von jedem Prozess geladen werden, zum Zeitpunkt der Erstellung sorgfältig festgelegt werden müssen, damit sie sich nicht überschneiden. Wenn die Binärdateien beim Laden aufgrund von Adresskonflikten neu basiert werden müssen, gehen fast alle Leistungssteigerungen bei der Verwendung von NGEN verloren. http://msdn.microsoft.com/en-us/magazine/cc163610.aspx


0

Nach 4 Minuten Inaktivität erhielt ich bei der ersten Anfrage eine konstante Verzögerung von 15 Sekunden. Mein Problem war, dass meine App die integrierte Windows-Authentifizierung für SQL Server verwendete und sich das Dienstprofil in einer anderen Domäne als der Server befand. Dies führte bei der App-Initialisierung zu einer domänenübergreifenden Authentifizierung von IIS zu SQL - und dies war die eigentliche Ursache für meine Verzögerung. Ich habe ein SQL-Login anstelle der Windows-Authentifizierung verwendet. Die Verzögerung war sofort weg. Ich habe immer noch alle Einstellungen für die App-Initialisierung, um die Leistung zu verbessern, aber in meinem Fall wurden sie möglicherweise überhaupt nicht benötigt.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.