IIS neden her 1740 dakikada bir Uygulama Havuzunu Geri Dönüşüm'e çeviriyor?

Neden IIS belirli bir süre sonra uygulama havuzunu geri dönüştürmek için varsayılan? Belki de çoğu web uygulamasının hafızayı ihtiyatlı bir şekilde yönetmemesinden başka belirli bir neden var mı? Uygulamanızın hafızasını doğru yönettiğinizi göz önüne alındığında, devam etmek ve bunu kapatmak güvenli midir? Potansiyel aşağı yönleri nelerdir, geri dönüşümü kapatmanın veya devam etmenin faydaları nelerdir?

Evet, günde bir kez varsayılan olmasının nedeni, web uygulamasında bellek sızıntısı olabileceğinden endişe duymamaktır. Sık sık IIS uygulama havuzlarını geri dönüştürmenin en büyük dezavantajı, web.config okuma, derleme yükleme ve asp.net sayfalarının yeniden derlenmesine ve (onları önceden derlemeye inanmıyorsanız) kod uyuşmasına neden olmasıdır. Bu oldukça ağır bir işlemdir ve uygulama havuzu geri dönüştürüldükten sonra bir sayfa için bir sonraki talebe kadar gerçekleşmez ve bu özel isteği büyük ölçüde yavaşlatır. IIS7 artık bu sorunla "başa çıkmanıza " yardımcı olmak için Application Warm Up adında indirebileceğiniz bir modüle sahip.

Şahsen geri dönüşümümü planlamak yerine, uygulama başlangıcında oturum açmakla birlikte bellek temelli maksimumları kullanmayı tercih ediyorum. Bu, uygulamamın bellek sızıntısı olmadığını varsaymamı ve uygulama havuzu geri döndüğünde yanlış olduğunu kanıtlamamı sağlıyor.

1740 dakika 29 saattir:

IIS 6 geliştirilirken (uygulama havuzlarını tanıtan sürüm), uygulama havuzları otomatik olarak geri dönüştürüldüğünde Normal Zaman Aralığı için ayarlanması gereken bir varsayılan ayar.

Wade basit nedenlerden dolayı 24 saat içinde en küçük asal sayı olmasını 29 saat önerdi . Günde bir kereden daha sık gerçekleşmeyen, şaşırtıcı ve tekrar etmeyen bir model istedi. Wade'in sözleriyle: “rezonans paterni almıyorsunuz”. Varsayılan değer, o zamandan beri 1740 dakikadır (29 saat)!

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

Özellik, her şeyi belleğe sızdıran ve yapmak zorunda kaldığınız klasik ASP günlerinden kalma bir giriştir. Çoğu insan gece boyunca web sunucusunda zamanlanmış bir yeniden başlatma yaptı. IIS6 bunu her 1740 dakikada bir uygulama havuzu kapatmalarıyla otomatikleştirdi (veya uygulama 20 dakika boşta kaldıysa). IIS7 geleneği sürdürdü.

O günlerde microsoft’tan aldığım tavsiyeler, bilinen bir bellek sızıntısı olan eski bir uygulamanız olmadığı sürece bunun gereksiz olmasıydı. Yani tamamen yönetilen bir kod kullanıyor olsaydınız sorun olmazdı.

Kapatın ve uygulama havuzlarını izleyin. Çoğu karmaşık kurumsal uygulama çok sayıda eski kod kullanır ve bu kodun çoğu çok sızdırabilir. Yani çoğu uygulama için uygulama havuzunun tekrar başlatılması kötü bir fikir değil.

Durumunuz için daha iyi bir çözüm olabilecek hareketsizlik zamanını izlemek gibi başka seçenekler de var.

Bir uygulama havuzunun çevrilmesi biraz zaman alabilir ve uygulamanın daha az yanıt vermesine neden olabilir;

Aslında, bu tamamen mevcut olabilecek sızıntı kaynaklarını temizlemek içindir. 1740 dakika da yalnızca tetikleyici olay değil. Ayrıca, belirli bir maksimum istek sayısından sonra veya belirli bir çalışan işlem belleği miktarını aştıktan sonra da olur. MSDN kütüphanesinde oldukça iyi belgelenmiştir. Ne yazık ki, bu politika oturum durumu ve singletonlar gibi statik durumları bozuyor. Uygulamanızın, kullanıcı deneyimini rahatsız etmekten kaçınmak için kullanıcıları yeniden doğrulaması ve / veya tekilleri yeniden başlatması için yeterince sağlam olması gerekir. ASP.NET oturumundan ziyade kimliği doğrulanmış oturumları veritabanında yönetmemize zorladı. Aksi halde, bu tetikleyicilerden biri nedeniyle sunucu geri dönüştürüldüğünde kullanıcılarımız giriş sayfamıza geri yüklendi.