Dlaczego proces roboczy IIS jest przetwarzany co 29 godzin, a nie co 24 godziny?

Podczas konfigurowania witryny w IIS domyślnie proces roboczy przetwarza się co 1740 minut (29 godzin). Dlaczego liczba nieparzysta jak 29 godzin, a nie na przykład 24 lub 48 godzin?

Na Tech Ed 2003 prezenterowi zadano to pytanie, a odpowiedź brzmiała, że ​​chcieli nieregularnego cyklu, aby zapobiec jego występowaniu na codziennych granicach (np. W celu odróżnienia od innych codziennych zadań zaplanowanych na serwerze / domenie).

Witryna tutaj (Link dead) spekulowała:

... (29) jest pierwszą liczbą pierwszą po 24, co pozwala jej mieć najmniejszą szansę na regularny wzorzec z dowolnym innym procesem serwera; ułatwienie dochodzenia w sprawie problemów

Pojawia się inna strona, aby to potwierdzić:

( Wade Hilmo ) zasugerował 29 godzin z tego prostego powodu, że jest to najmniejsza liczba pierwsza powyżej 24. Chciał mieć rozłożony i nie powtarzający się wzór, który nie występuje częściej niż raz dziennie

OK, to mnie wkurzyło, więc przekopałem się i w końcu znalazłem ten post od faceta, który najwyraźniej był w zespole IIS:

Powód, dla którego IIS6 domyślnie przetwarza co 29 godzin (i mieliśmy powód

Powodem, dla którego IIS6 jest przetwarzany domyślnie co 29 godzin (i mieliśmy powód, aby wybrać 29 godzin jako wartość domyślną) jest to, że bardziej prawdopodobne jest, że aplikacja internetowa działająca na nim jest zawodna i dosłownie musi się często restartować.

W związku z tym IIS6 opiera się na założeniu (co jest cyniczne), że aplikacja internetowa użytkownika nie będzie działać przez więcej niż 24 ciągłe godziny, odpowiednio zaplanowane funkcje i wybrane ustawienia domyślne. Procesy robocze są przetwarzane co 29 godzin, uruchamianie i zamykanie procesu jest monitorowane, proces jest stale pingowany, aby upewnić się, że jest uruchomiony, uchwyt procesu jest śledzony i sygnalizowany, gdy niespodziewanie kończy się itp.

Zdając sobie sprawę, że recykling jest normalną częścią operacji, IIS6 zapewnia również izolację takiego recyklingu od użytkownika końcowego - połączenie TCP użytkownika końcowego nigdy nie kończy się podczas recyklingu, z powodu pewnej magii trybu jądra. W połączeniu z aplikacją w trybie użytkownika, która przechowuje stan sesji poza procesem (np. ASP.Net Session State Service), można praktycznie zagwarantować niezawodny czas bez widocznej dla użytkownika utraty danych, nawet jeśli aplikacja internetowa ulegnie awarii po przetworzeniu każdego pojedynczego Żądanie użytkownika.

Jest to tak dobre, jak IIS6 może uczynić - biorąc pod uwagę niewiarygodną aplikację internetową, sprawiając, że wydaje się niezawodna dla użytkownika końcowego, i rób to bez konieczności poprawiania niewiarygodnej aplikacji internetowej.

Oczywiście nie wszystkie nierzetelne aplikacje mogą sprawiać wrażenie niezawodnych - jeśli tak, to wszyscy jesteśmy bez pracy! - ale IIS6 z pewnością stara się o wiele bardziej zachować odporność.

W twoim przypadku po prostu zdarza się, że sprężystość ma wpływ uboczny na nietrwały stan użytkownika, ale można go łatwo dostosować.

Zakładając, że twoja aplikacja internetowa nigdy nie ma problemu i pozostaje w stanie sesji procesowej, będziesz chciał zmienić te ustawienia domyślne: 1. Wyłącz 29-godzinny okresowy recykling 2. Wyłącz 20-minutowy limit czasu bezczynności

Zapobiegnie to nieoczekiwanej utracie stanu sesji.

Oczywiście, jeśli kiedykolwiek użyjesz aplikacji ze stanem sesji poza procesem, możesz pozostawić wszystko jako domyślne i nigdy nie zauważać różnicy w funkcjonalności lub niezawodności.