IIS7 ASP.NET uygulaması - 2 özdeş uygulama havuzunda 2 özdeş uygulama, 1 yanıt veren ve 1 değil

(Uygulama olarak) sanal bir dizinde yüklü ve kendi uygulama havuzunda barındırılan bir ASP.NET (v4.0) web uygulaması var. Bu, uygulamanın her örneği için tekrarlanır (örn. Müşteri başına).

Uygulama havuzları tümleşik (klasik değil) kiptedir ve LoadUserProfile öğesi true olarak ayarlanmıştır. Aksi takdirde, varsayılan ayarlar.

Her örneğin şu anda kendi kod / config kopyası ve kendi veri klasörü vardır (temel dosya okuma / yazma).

Bu uygulamanın 1 örneği iyi çalışıyor (karşılaştırma için kullanılan işlem ~ 4 saniye sürer). Diğer her örnek yavaş çalışır (aynı işlem için 10-25 saniye arasında).

Yavaş örneği "en hızlı" uygulama havuzuna taşırsam o örnek hayata döner. Daha hızlı örneği daha yavaş uygulama havuzuna taşırsam bu örnek yavaşlamaya başlar.

Uygulama havuzları başlangıçta aynı şekilde oluşturuldu - manuel olarak. Daha sonra daha hızlı uygulama havuzunun tam bir kopyasını ve yine aynı davranışı sağlamak için powershell kopya rutini kullandım. Apppool.config dosyalarının karşılaştırılması, bunların sanal dizin atamalarını aynı şekilde engellediğini gösterir.

Söylenebildiğim kadarıyla engellenen paylaşılan kaynaklar yok ve performans uygulama havuzunu kapatarak ve yeniden başlatarak ... yavaş hala yavaş ve sonra o uygulama havuzunu yeniden başlattığımda test ettim (böylece yüklü son) hala daha hızlı ...

Sorunu daha fazla izole etmek için, iki oturum için ana sistemde Wireshark (veya başka bir paket analizörü) çalıştırmanızı öneririm. Yaptığım varsayım, her uygulama havuzunun kendisine atanmış benzersiz bir IP'ye veya benzersiz bir bağlantı noktasına sahip olmasıdır.

Öncelikle hızlı uygulama havuzunuzun IP: bağlantı noktasını filtreleyerek temel performansınızı elde edin. "Normal" koşullar altında uygulamadan gelen ve giden trafiğin nasıl göründüğüne bakın.

İkinci adımda, yavaş / yanıt vermeyen uygulama havuzundan trafik yakalamanız gerekir. Tüm ağ yönlendirmesi ve benzeri kutulara kadar doğruysa, büyük olasılıkla başka bir yerden uygulama için tekrarlanan istekleri görmelisiniz, ancak uygulamanız başka bir sunucuya çok fazla istekte bulunan bir şeyse, trafiğiniz giriş yerine çıkış üzerinde ağır.

Bu test, sorunun uygulama içinde olup olmadığını veya iletişimin düşük olması / iletişim olmaması nedeniyle uygulamanın zaman aşımına uğramasıyla sonuçlanan TCP / IP ile ilgili sorunların olup olmadığını size bildirir.

Sınamalarınızın zaman damgalarını sunucunun olay günlükleriyle ve (varsa) izleme günlükleriyle ilişkilendirin; sorunu sıfırlayabilmeniz gerekir.

Başarısız İstek İzleme (FRT) bunu izlemek için en iyi araçtır. Boru hattını ve her adımın ne kadar sürede tamamlandığını gösterecektir. Bu, asp.net bölümünde bir şey olup olmadığını veya IIS boru hattı içinde bir şey olup olmadığını belirtmelidir.

FRT'yi ayarlamak için, IIS'den site düzeyinde 200 durum aralığı 200-999 olan bir FRT kuralı oluşturun ve FRT'yi etkinleştirdiğinizden emin olun (eylemler bölmesinden ayrı bir adımdır).

Ardından sorunu yeniden oluşturun ve oluşturulan dosyalara bakın (% SystemDrive% \ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}). Bunları Internet Explorer'da açın.

IIS, belirgin bir nedenden ötürü uzun süre ertelendiğinde, genellikle dış hizmetin zaman aşımına uğramasını beklediği anlamına gelir. O zaman başka bir yaklaşım dener. Bu nedenle bu, Windows veya Linux'taki hemen hemen her şey için geçerlidir. Bu durumlarda benim için ilk şüpheli her zaman ağ adı çözümleme yapılandırmasıdır. Masum olduğu kanıtlanana kadar suçlu.

Bu, bir kullanıcı yinelenen sitelerden birine isabet ederek yeniden oluşturulabilir mi? 10 ila 20 saniye tepki süresini yeniden oluşturduğunuzda CPU ve disklerin ne yaptığını bilmek iyi olur. 10-20 saniye boyunca çok fazla bir şey olmadığı anlaşılıyorsa, bağlayıcı adlarınızı ve bağlı adlar için ad çözümlemenizi kontrol etmelisiniz. CPU veya diskler çiğniyorsa, hangi işlemin çok çalıştığını ve nedenini bulmanız gerekir.

Lütfen bulgularınızı gönderin, merak ediyorum.

PS Ayrıca ad çözümleme ve oyunda olabilecek herhangi bir kimlik doğrulama hizmetlerine erişim kontrol ediyorum. Örneğin, etki alanı sunucusuna başvurulması gerekiyorsa, listenizdeki ilk DNS sunucusunun etki alanı için DNS sunucusu olduğundan emin olun.

Bu çözüm değil ama biz bunun için çalışacağız;

1. IISRESET'i (bakım saatleri içinde) çalıştırın veya yanıt vermeyen uygulama havuzuna ait W3WP'yi öldürün

2. Uygulamayı başlat

3. Yanıt vermiyor olsa da, yavaş uygulama havuzuna ait bir W3WP döküm dosyasını alın. Ya kullanın süreç kaşif bir döküm dosyası oluşturmak veya görev yöneticisini

4. Mscordacwks.dll ve mscorwks.dll dosyasını C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX altından alın

5. Bu dosyayı zip ve indirebileceğim bir yere yükleyin.