Warum wird der IIS-Arbeitsprozess alle 29 Stunden und nicht alle 24 Stunden wiederverwendet?

Wenn Sie eine Site in IIS einrichten, wird der Arbeitsprozess standardmäßig alle 1740 Minuten (29 Stunden) neu gestartet. Warum eine ungerade Zahl wie 29 Stunden und nicht zum Beispiel 24 oder 48 Stunden?

Bei der Tech Ed 2003 wurde dem Moderator diese Frage gestellt und die Antwort lautete, dass ein unregelmäßiger Zyklus gewünscht wird, um zu verhindern, dass er an einer täglichen Grenze auftritt (z. B. um sich von anderen täglichen Aufgaben zu unterscheiden, die auf dem Server / der Domäne geplant sind).

Die Seite hier (Link tot) spekuliert:

... (29 ist die) erste Primzahl nach 24, wodurch die geringste Wahrscheinlichkeit besteht, dass sie in einem regulären Muster mit einem anderen Serverprozess auftritt. Erleichterung der Untersuchung von Problemen

Eine andere Site scheint dies zu bestätigen:

( Wade Hilmo ) schlug 29 Stunden vor, aus dem einfachen Grund, dass es die kleinste Primzahl über 24 ist. Er wollte ein gestaffeltes und sich nicht wiederholendes Muster, das nicht häufiger als einmal pro Tag auftritt

OK, das hat mich nervt, also habe ich mich umgesehen und endlich diesen Beitrag von einem Typen gefunden, der anscheinend im IIS-Team war:

Der Grund, warum IIS6 standardmäßig alle 29 Stunden wiederverwendet wird (und wir hatten einen Grund)

Der Grund, warum IIS6 standardmäßig alle 29 Stunden wiederverwendet wird (und wir hatten einen Grund, 29 Stunden als Standardwert zu wählen), ist, dass die darauf ausgeführte Webanwendung höchstwahrscheinlich unzuverlässig ist und buchstäblich häufig neu gestartet werden muss.

Daher basiert IIS6 auf der Voraussetzung (zugegebenermaßen zynisch), dass die Webanwendung des Benutzers nicht länger als 24 aufeinander folgende Stunden ausgeführt wird, die Funktionen entsprechend geplant und die Standardeinstellungen ausgewählt werden. Worker-Prozesse werden alle 29 Stunden wiederverwendet, der Start und das Herunterfahren von Prozessen werden überwacht, der Prozess wird ständig gepingt, um sicherzustellen, dass er ausgeführt wird, das Prozesshandle wird verfolgt und signalisiert, wenn er unerwartet beendet wird, usw. usw.

IIS6 erkennt, dass Recycling ein normaler Bestandteil des Betriebs ist und isoliert dieses Recycling auch vom Endbenutzer. Die TCP-Verbindung des Endbenutzers wird während eines Recyclings aufgrund von Kernelmodus-Magie niemals beendet. In Kombination mit einer Anwendung im Benutzermodus, in der der Sitzungsstatus außerhalb des Prozesses gespeichert wird (wie beim ASP.Net-Sitzungsstatusdienst), ist praktisch eine zuverlässige Betriebszeit ohne sichtbaren Datenverlust gewährleistet, selbst wenn die Webanwendung nach jeder einzelnen Verarbeitung abstürzt Benutzeranfrage.

Dies ist ungefähr so ​​gut, wie es mit IIS6 möglich ist - wenn eine unzuverlässige Webanwendung vorhanden ist, sie für den Endbenutzer als zuverlässig erscheint und keine Korrekturen für die unzuverlässige Webanwendung erforderlich sind.

Natürlich kann nicht jede unzuverlässige Bewerbung als zuverlässig eingestuft werden - wenn ja, dann sind wir alle arbeitslos! - aber IIS6 versucht sicher noch viel mehr, widerstandsfähig zu sein.

In Ihrem Fall hat die Ausfallsicherheit nur einen Nebeneffekt auf den nicht beständigen Benutzerstatus, kann jedoch leicht angepasst werden.

Angenommen, Ihre Webanwendung hat nie ein Problem und verbleibt im Sitzungsstatus "In Bearbeitung". Dann sollten Sie die folgenden Standardeinstellungen ändern: 1. Deaktivieren Sie das regelmäßige Recycling für 29 Stunden

Dadurch wird ein unerwarteter Verlust des Sitzungsstatus verhindert.

Wenn Sie eine Anwendung mit einem Sitzungsstatus außerhalb des Prozesses verwenden, können Sie natürlich alle Einstellungen als Standardeinstellungen beibehalten und keinen Unterschied in der Funktionalität oder Zuverlässigkeit feststellen.