Dlaczego usługi IIS domyślnie przetwarzają pulę aplikacji co 1740 minut?

Dlaczego IIS domyślnie przetwarza pulę aplikacji po określonym czasie? Czy istnieje jakiś konkretny powód inny niż być może większość aplikacji internetowych nie zarządza pamięcią ostrożnie? Biorąc pod uwagę, że właściwie zarządzasz pamięcią aplikacji, czy bezpiecznie jest je wyłączyć i wyłączyć? Jakie są potencjalne wady, zalety wyłączania recyklingu lub utrzymywania go?

Tak, powodem, dla którego domyślnie jest to raz dziennie, jest obawa, że ​​aplikacja internetowa może mieć wyciek pamięci. Największym minusem częstego recyklingu pul aplikacji IIS jest to, że spowoduje to odczytanie pliku web.config, ładowanie zestawu oraz rekompilację stron asp.net i (jeśli nie wierzysz w ich kompilację) opóźnień w kodzie. Jest to dość ciężki proces i nie pojawia się do następnego żądania strony po przetworzeniu puli aplikacji, co znacznie spowalnia to konkretne żądanie. IIS7 ma teraz moduł do pobrania o nazwie Rozgrzewanie aplikacji, który pomaga „uporać się” z tym problemem.

Osobiście wolę używać maksimów opartych na pamięci w połączeniu z logowaniem do uruchamiania aplikacji, niż planować recykling. To pozwala mi założyć, że moja aplikacja nie ma przecieku pamięci i że udowodniono, że jest błędna, gdy pula aplikacji zostanie zrestartowana.

1740 minut to 29 godzin:

Kiedy opracowywano IIS 6 - która jest wersją, która wprowadziła pule aplikacji - domyślne ustawienie musiało być ustawione dla przedziału czasu regularnego, gdy pule aplikacji są automatycznie przetwarzane.

Wade zasugerował 29 godzin z tego prostego powodu, że jest to najmniejsza liczba pierwsza powyżej 24 . Chciał rozłożonego i powtarzającego się wzoru, który nie występuje częściej niż raz dziennie. Słowami Wade'a: „nie dostajesz wzorca rezonansowego”. Od tego czasu domyślnie jest to 1740 minut (29 godzin)!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

Cechą jest pozostałość po klasycznych czasach ASP, kiedy wszystko wyciekło pamięci i trzeba było to zrobić. Większość ludzi miała zaplanowane ponowne uruchomienie na serwerze internetowym na noc. IIS6 zautomatyzował to z zamykaniem puli aplikacji co 1740 minut (lub jeśli aplikacja jest bezczynna przez 20 minut). IIS7 kontynuował tradycję.

Porada, którą otrzymałem od Microsoft w tamtych czasach, była taka, że ​​nie było to konieczne, chyba że masz starszą aplikację ze znanym wyciekiem pamięci. Więc jeśli korzystasz z czysto zarządzanego kodu, wszystko będzie dobrze.

Wyłącz i monitoruj pule aplikacji. Większość złożonych aplikacji korporacyjnych wykorzystuje dużo starszego kodu, a znaczna część tego kodu jest nieco nieszczelna. Dlatego w przypadku większości instalacji ponowne uruchamianie puli aplikacji nie jest złym pomysłem.

Istnieją inne opcje, takie jak monitorowanie czasu bezczynności, które mogą być lepszym rozwiązaniem dla twojej sytuacji.

Przyspieszenie puli aplikacji może zająć trochę czasu i sprawić, że aplikacja będzie mniej responsywna, więc utrzymanie ich może poprawić wydajność.

Rzeczywiście, jest to wyłącznie w celu oczyszczenia wyciekających zasobów, które (mogą) być obecne. 1740 minut to nie jedyne zdarzenie wyzwalające. Dzieje się tak również po określonej maksymalnej liczbie żądań lub po przekroczeniu określonej ilości pamięci procesu roboczego. Jest dość dobrze udokumentowany w bibliotece MSDN. Niestety, ta zasada psuje rzeczy takie jak stan sesji i statystyki, takie jak singletony. Twoja aplikacja będzie musiała być wystarczająco solidna, aby ponownie uwierzytelnić użytkowników i / lub ponownie zainicjować singletony w razie potrzeby, aby uniknąć zakłócania doświadczenia użytkownika. Zmusiło nas to do zarządzania uwierzytelnionymi sesjami w bazie danych, a nie w sesji ASP.NET. W przeciwnym razie nasi użytkownicy byli przywracani do naszej strony logowania za każdym razem, gdy serwer był odtwarzany z powodu jednego z tych wyzwalaczy.