Radfahren IIS App-Pool Ursache langsam erste Benutzererfahrung

Question

Wenn ich den Anwendungspool für meine Webanwendung über IIS MMC recyceln, erfährt der erste Benutzer eine Seite in der Webanwendung anfordern eine wirklich langsame Antwort von der Website. Nach dieser anfänglichen Anfrage ist jede nachfolgende Seite in Ordnung. Der Benutzer kann sich auch abmelden, später wiederkommen und die Geschwindigkeit ist schnell. Meine Sorge ist mit der ersten, anfänglichen Belastung der Website. Wenn ich ein Skript schreiben würde, um den Anwendungspool um 3 Uhr am Morgen neu zu starten, was kann ich sonst noch tun, um entweder einen Benutzer, der die Seite besucht, anzunehmen und diese anfängliche langsame Last zu bekommen, um so die App "bereit" für die Benutzer am Morgen.

oder

b.) Erzählen die app-Pool, um den Speicher und solche ohne Benutzer spulen zu müssen, diesen Prozess zu initiieren.

Answer 1

Alles passiert beim ersten Laden der Website. Das einzige, was Sie tun können, ist eine Anfrage an die Website nach dem Recycling zu simulieren. Dies kann mit einer einfachen Anwendung geschehen. Der einfachste Weg, dies in .NET zu tun, wäre die Verwendung der Klasse HttpWebRequest.

Answer 2

Zunächst benötigen Sie kein Skript, um die App um 3 Uhr morgens zu recyceln. Die App-Pools haben Einstellungen, die beim Recycling ausgewählt werden können. Standardmäßig denke ich, dass sie alle 29 Stunden recyceln, was eine seltsame Einstellung ist, und ich empfehle, sie zu ändern. Andernfalls erhalten Sie Anrufe zu verlorenen Sitzungen zu zufälligen Zeiten des Tages.

Ich muss davon ausgehen, dass Sie eine ASP.NET-Anwendung im betreffenden App-Pool haben. Bei der ersten Anforderung ist die Verzögerung hauptsächlich darauf zurückzuführen, dass der ASP.NET-Workerprozess eine Website kompilieren und/oder DLLs laden muss, die zur Laufzeit erforderlich sind. Um dieses Problem zu lösen, verwenden die meisten eine Keep-Alive-Task, die regelmäßig Anfragen an die Site stellen kann, um sicherzustellen, dass sie vollständig geladen sind. Matts Vorschlag ist ebenfalls ein guter Vorschlag, löst das Problem jedoch nur, wenn Sie den App-Pool selbst recyceln. App-Pools können aus verschiedenen Gründen selbstständig recycelt werden, und der Keep-Alive-Modus kann die meiste Zeit geladen bleiben.

Answer 3

Ich hatte ein ähnliches Problem. Beim ersten Laden muss der JIT-Compiler die MSIL in Maschinencode konvertieren. In der Regel ist dies sehr schnell erledigt und erfolgt aus dem Ordner "Temporäre ASP.NET-Dateien" Schattenkopie, wenn dies nicht das erste Mal ist, dass die Anwendung verwendet wurde. Ihre Anwendungsassemblys werden hier beim ersten Laden der Anwendung kopiert, damit die Anwendungs-DLLs am tatsächlichen Speicherort ausgetauscht werden können, ohne dass die Fehler "in Verwendung" auftreten.

Ich abschweifen, kompiliert der JIT-Compiler die Assemblies, wie sie benötigt werden, die in der Regel ziemlich schnell ist. Dies ändert sich, wenn Sie signierte Assemblys verwenden und der Benutzer, der die JIT-Kompilierung durchführt (dh der App-Pool-Benutzer), keinen Internetzugriff hat. In diesem Fall wird es nur für etwa 10-20 Sekunden dort sitzen, während es versucht, die Signatur im Internet zu überprüfen, die es nicht erreichen kann.

Als wir dieses Problem hatten, verwendeten wir Enterprise Library-Assemblys. Statt der JIT-Kompilierzeit dauerte es einige Sekunden nach dem App-Pool-Recycling in einigen Fällen mehr als eine Minute bis zur Zeitüberschreitung der Signaturverifizierungs-Internetanforderungen .

Deaktivieren Sie entweder die Signaturverifizierung für Ihre Assemblys während JIT (eine Konfigurationseinstellung) oder geben Sie dem App-Poolbenutzer den Internetzugriff.

Answer 4

Dies ist eine alte Frage, aber ich habe einige neue Erfahrungen damit gemacht und dachte, ich würde es posten. Abhängig von Ihrer Situation können Sie verschiedene Dinge tun.

Der Grund dafür ist, dass der IIS-Arbeitsprozess nach einer bestimmten Zeit in den Ruhezustand versetzt wird.Die Einstellung hierfür lautet Idle Timeout und kann auf 0 gesetzt werden, wenn Sie diese Funktion deaktivieren möchten. Aber ich würde dies recherchieren, bevor ich so etwas ändere.

Wenn IIS startet, registriert es außerdem die DLLs in Ihrem Bin. Wenn Sie eine kleine Site haben, gibt es wahrscheinlich nicht zu viele DLLs (anders als die Standard-.NET-DLLs). Wenn Sie viele (vielleicht einige unbenutzte) DLLs haben, müssen sie noch verarbeitet werden. Wenn Sie entfernen die alten DLLs/Code, IIS wird nicht mehr Zeit verschwenden sie zu verarbeiten und wird schneller neu gestartet.

Wir haben eine DotNetNuke-Site, die etwa 35 "Legacy" -Module hatte, die nicht mehr benutzt wurden, aber immer noch im Ordner/bin waren. Wir haben die Module und DLLs im Verzeichnis/bin entfernt und die Zeit für die Wiederverwendung der Website wurde halbiert.

Eine weitere Sache. Sie können eine Keep Alive Seite konfigurieren, die regelmäßig geladen wird, damit die Site nicht heruntergefahren wird. Ich weiß, dass unser Hosting-Provider diesen Service anbietet. Wir haben eine einfache ASPX-Seite auf der Website, die alle 30 Minuten aufgerufen wird, um sicherzustellen, dass die Site im Arbeitsspeicher bleibt.