Wie ASP.NET-Assemblys in AppDomain am Leben erhalten?

Question

Szenario: Ich habe eine n-Tier-ASP.NET-Unternehmensanwendung mithilfe von Webbereitstellungsprojekten bereitgestellt. Alle Ebenen erzeugen unabhängige Assemblys, die von der ASP.NET-Anwendung verwendet werden.

Problem: Wenn ich die App ausführen. Zum ersten Mal nach dem Deployment benötigt es viel Zeit, um abhängige Assemblies im Speicher zu laden. Aber sobald seine Beleuchtung schnell App geladen. Falls keine Benutzer auf die App zugreifen, entlädt IIS die Assemblys aus dem Speicher. Wenn ein Benutzer in einer späteren Instanz auf die App zugreift, lädt er alle Assemblys erneut, wobei die Zeit für das Laden erneut benötigt wird dauert es zum ersten Mal.

Ich bin auf der Suche nach einer Lösung, die es mir ermöglicht, meine Assemblys in den Speicher geladen zu halten und dabei die volatile Natur von Assemblies in Richtung Speicherresiduum zu überschreiben.

Oder irgendeine andere Lösung, die meine Benutzer glücklich macht, die APP zu verwenden, die das erwähnte Problem löst.

Answer 1

Wechseln Sie in IIS 6 zum Abschnitt Anwendungspools, und klicken Sie mit der rechten Maustaste auf Eigenschaften im Pool, der die fragliche ASP.NET-Anwendung hostet. Wechseln Sie zur Registerkarte "Leistung" und deaktivieren Sie die Option "Worker-Prozesse nach der Inaktivierung herunterfahren":

Wechseln Sie in IIS 7 in den Bereich Verbindungen und suchen Sie Anwendungspools. Wählen Sie dann Erweiterte Einstellungen für den Pool, der Ihre Anwendung hostet. Suchen Sie die Eigenschaft "Idle Timeout" und setzen Sie sie auf "0" (dies deaktiviert sie).

Der Standardwert ist 20 Minuten Inaktivität. Wenn Sie die Box deaktivieren, sobald Ihre AppDomain von der worker process geladen wird, wird sie nie sterben (es sei denn, Sie töten den Prozess oder etwas natürlich). Standardmäßig wird IIS recycle the process, wenn es ein Limit erreicht, wie eine Speicherkapazität, aber es wird auch ein neues beginnen und alle eingehenden Anfragen "über", bis das alte nicht verwendet wird, um Störungen zu minimieren.

Ich habe auch eine kleine C# -Klasse geschrieben, die keep your ASP.NET application alive (alternate archived version) unter normalen Umständen wird. Da es innerhalb der Anwendung ausgeführt wird, kann es natürlich nicht verhindern, dass IIS oder irgendetwas anderes den Prozess explizit auslöschen, aber es wird die Anwendung "heiß" halten, z. Die App wird niemals lange genug inaktiv sein, damit IIS sich entschließen kann, sie auszuschalten.

Wenn Sie keine direkte Kontrolle über Ihre IIS-Konfiguration (z. B. freigegebenen Host) haben, ist Ihre beste Wette eine kleine Anwendung auf einem separaten System laufen - sagen, eine Always-on-Workstation - die Ihre Website alle trifft x Minuten, um zu verhindern, dass der Anwendungspool ausläuft. Nichts Besonderes - eine einfache WebRequest und eine while() - Schleife in einer Konsolenanwendung reichen aus.

Answer 2

Ich schrieb eine kleine C# -Konsolenanwendung, die meine 4 Seiten alle 10 Minuten über Windows Task Scheduler am Leben erhält. Das Leben ist wieder gut. Wir betreiben die App nicht von 2 bis 5 Uhr morgens, nur damit die Aufschläge Speicher aufräumen können, wenn es überhaupt zählt. Für unsere Websites ist sowieso kaum jemand anwesend.

Answer 3

Einer der Vorteile von ASP .net ist die Möglichkeit, statische (gemeinsame) Instanzen von Objekten zu erstellen.

Um die Notwendigkeit eines externen Prozesses zu vermeiden, können Sie in (per Beispiel) global.asax einen statischen Timer erstellen, der mit einer einfachen WebRequest eine Seite in der Domäne aufruft. Auf diese Weise bleibt die Seite selbst am Leben, bis ein manuelles Zurücksetzen des Pools erfolgt.