IIS’te uygulama havuzu recycle’ı satış saatinde sürpriz olmasın

Dijital ürün sattığım bir mağaza için IIS üzerinde çalışan ASP.NET uygulamasında, uygulama havuzunun yeniden başlamasını yalnızca “bakım işi” olarak görmemek gerektiğini fark ettim. Recycle çoğu zaman kesintiyi önleyecek şekilde gerçekleşse de uygulamanın açılış süresi ve oturumların nerede tutulduğu kullanıcı deneyimini doğrudan etkiliyor.

Özellikle şu üç noktayı kontrol ediyorum:

• Oturum yönetimi: Oturum verisi bellekte, yani InProc tutuluyorsa havuz yeniden başladığında kullanıcıların sepeti veya oturum bilgisi kaybolabilir. Sepet gibi kritik verileri veritabanında saklamak, oturumu da paylaşımlı bir depoya taşımak daha dayanıklı olur.
• Recycle nedeni ve zamanı: IIS’te havuzun hangi nedenle yeniden başladığını olay günlüklerinden ve IIS yapılandırmasından takip ediyorum. Zamanlanmış recycle gerekiyorsa yoğun sipariş saatlerine denk getirmemek önemli; yalnızca varsayılan ayarlara güvenmek yerine gerçek trafik saatlerine bakıyorum.
• İlk isteğin gecikmesi: Idle timeout veya sunucu yeniden başlatması sonrasında uygulamanın ilk istekte derleme ve başlangıç işlemleri yapması gecikme yaratabilir. Trafik alan projelerde başlangıç davranışını test etmek ve uygulamayı önceden ısıtma seçeneklerini değerlendirmek faydalı.

Siz IIS’te sepet ve oturum bilgisini nasıl koruyorsunuz? Recycle kaynaklı gecikme ya da kullanıcı kaybı yaşayıp hangi ayarla çözdünüz?