IIS 7.x Uygulama Havuzu En İyi Uygulamaları

Bazı yeni sunuculara birkaç site dağıtmak üzereyiz. Uygulama havuzları ile ilgili aşağıdaki sorularım var:

Her web sitesi için bir uygulama havuzuna sahip olmak tavsiye edilir. Bu yaklaşıma herhangi bir uyarım var mı? Bir uygulama havuzu tüm CPU, Memory, Etc ... 'yi domuz edecek mi?
Bir uygulama havuzunda birden fazla çalışan işlemine ne zaman izin vermelisiniz? Ne zaman yapmamalısın?
Bir uygulama havuzunun diğerine karışmasını önlemek için özel bellek sınırı kullanılabilir mi? Çok düşük ayar yapılması, geçerli isteklerin geçerli bir yanıt almadan uygulama havuzunu geri dönüştürmesine neden olur mu?
Özel ve sanal bellek sınırları arasındaki fark nedir?
Site başına bir uygulama havuzu çalıştırmamanın zorunlu nedenleri var mı?

— Eric Burcham
kaynak

Size ilk soru: Bu web siteleri (yani: .htm / .js) veya web uygulamaları (yani .aspx / .php) mi?

— Gorilla

Çoğunlukla .Net 3.5 uygulamaları. Bir üçüncü parti PHP uygulamasıdır.

— Eric Burcham

Bu çok geniş bir konu yelpazesidir - Konu (ve @ CodingGorilla'nın cevapları) ilginçtir, ancak SF'nin Q ve A stiline en uygun olmayabilir

— voretaq7

Yanıtlar:

1) Her web sitesi için bir uygulama havuzuna sahip olmanız tavsiye edilir. Bu yaklaşıma herhangi bir uyarım var mı? Örneğin bir uygulama havuzu tüm CPU, Memory, Etc ...

Bu oldukça iyi bir yaklaşım; Aynı havuzu paylaşan farklı "siteler" (uygulamalar) olması gerektiğini düşünmek için iyi bir neden yok. Tabi bir çeşit tek bir kaynağı paylaşmaları gerekmedikçe. Bir uygulama teorik olarak çok fazla CPU veya belleği barındırabilir, ancak uygulamaların nasıl bir araya getirildiğini değiştirmek gerçekten bu kadar etkili olmaz.

2) Bir uygulama havuzunda çoklu çalışan işlemlerine ne zaman izin vermelisiniz? Ne zaman yapmamalısın?

Bu, varsayılan ayarları kullanarak en iyi şekilde yalnız bırakılabilir. Ne yaptığınızı gerçekten bilmiyorsanız, bu aslında web sitenizi / uygulamanızı olumsuz yönde etkileyebilir.

3) Bir uygulama havuzunun diğerine karışmasını önlemek için özel bellek sınırı kullanılabilir mi? Çok düşük ayar yapılması, geçerli isteklerin geçerli bir yanıt almadan uygulama havuzunu geri dönüştürmesine neden olur mu?

a) Teorik olarak

b) Evet, düşürmek olumsuz etkilere neden olabilir. Yine, özel gereksinimleriniz olmadığı ve ne yaptığınızı bilmediğiniz sürece, bunları yalnız bırakın.

4) Özel ve sanal bellek limitleri arasındaki fark nedir?

Bu çok karmaşık, işte size yardımcı olabilecek kısa bir mesaj: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) Site başına bir uygulama havuzu çalıştırmamanın zorunlu nedenleri var mı?

Yine, düşünebilmemin tek nedeni, çoklu uygulamaların ihtiyaç duyduğu bir çeşit "paylaşılan kaynak" varsa, o zaman onları aynı süreçte çalıştırmak istersiniz.

Genel amaçlı uygulamalar ve web siteleri için, IIS varsayılan değerleri ile oldukça iyi ayarlanmıştır.

****GÜNCELLEŞTİRME****

# 2 ile ilgili ek bilgi talebinizle ilgili olarak, özel bir gereksiniminiz olmadıkça bunu yapmamalısınız. Uzun süren sunucu işlemleriyle bile, isteklere birden çok iş parçacığı kullanılarak yanıt verilir ve uzun süredir çalışan görevleri (diğer istekleri işlemek için bir iş parçacığı havuzu iş parçacığını serbest bırakır) işlemek için "Zaman Uyumsuz İstekler" kullanmak istersiniz. Gerçekçi olarak, tek bir havuz için birden fazla işleme izin vermek için iyi bir sebep düşünemiyorum.

Birden çok işlem konuşmaya başladığınızda, potansiyel olarak şu durumlarla karşılaşırsınız: 1. oturumda bir oturum canlı olduğu için oturum durumunu kaybetme, ancak istek işlem 2 tarafından gerçekleştiriliyor. Veya daha da kötüsü Gerçek bir acı olan bazı süreçler arası iletişim kurar.

Birden fazla işlemin bir nedeni ile ilgili olarak ne olursa olsun, bununla başa çıkmanın daha iyi bir yolu olduğuna bahse girerim (başka bir işlemi başlatmak yerine).

— Goril kodlama
kaynak

Düşünceli cevabı takdir ediyorum ve kabul ettim. Eğer # 2 ile ilgili daha spesifik bir bilginiz varsa, minnettar olurum. “Yalnız en iyi sol” kesinlikle adalet tavsiyesidir, ancak çoklu işçi işlemlerinin ne zaman kullanılacağını bilmek de iyi olacaktır. Büyük bir rapor, büyük gönderileri kabul eden web hizmeti ve benzeri yanıtları döndürmek için uzun zaman alan bazı sunucu işlemleriniz olduğunda bunun daha alakalı olduğunu düşünüyorum. Ayrıca tüm normal iş parçacığı eşzamanlılık şeyler geçerli olduğunu varsayalım?

— Eric Burcham

Eklemek gerekirse: uygulamalarınızın birlikte oynamasını bekliyorsanız, IIS'nin yükleme iletişim kutusu, Windows Sistem Kaynağı Yöneticisi'nin yüklenebileceğini ve uygulama havuzları tarafından CPU ve bellek kullanımını sınırlamak için kullanılabileceğini belirtir.

— TristanK

@TristanK, bahşiş için teşekkür ederim. Bu son derece yardımcı oldu.

— Eric Burcham

@ Goril Gorilla - İçgörü için tekrar teşekkürler. “Neden bir web bahçesi kullanıyorsunuz” üzerine ciddi bir şekilde kazı yapmaya karar verdim ve birkaç yanıt aldım. Bahsettiğiniz tüm uyarılar, özellikle çeşitli önbellek ve kullanıcı oturumları gibi paylaşılan kaynaklara asenkron erişim ile ilgilidir. Web bahçesi özelliği, temelde, bakiye isteklerini çekirdekten fazlası olan tek bir sunucuya yüklemenize izin verir. Bu nedenle, talepleri yönlendirmek dışında normalde yük dengeli bir senaryoda ele aldığınız uyarılarla ilgilenmeniz gerekir.

— Eric Burcham

@Goldilla Gorilla - Devam ... Birden fazla alt işlem özelliğini kullanırken bulduğum en iyi "sebep" performansı artırmak. Bu bağlantıya göz atın: iis-aid.com/articles/performance_testing/… . Elbette, çoğu zaman (en azından başlamak üzere) tek bir çalışan iş parçacığı çalıştırdığı için, web sitelerini göz önünde bulundurmayı sık sık ihmal ettiğimiz, programlamanın tüm asenkron yönleriyle ne yaptığınızı daha iyi biliyordunuz. Yani soruma kısa cevap: Performans problemleri yaşıyorsanız deneyin.

— Eric Burcham

Her zaman bir web sitesi için özel bir uygulama havuzu yapılandırırım. Düşük maliyetli web sitesi barındırma senaryoları, uygulama havuzu başına çok sayıda siteye sahip olmanın anlam ifade ettiği yerlerdir.

Bellek sınırları, bir sitenin tüm sistem kaynaklarını tüketmesini önlemek için gerçekten yalnızca ilkel güvenlik eşikleridir. Bunun Windows 2008 R2 x64'te IIS 6.0 x86'da olduğundan daha olası bir sorun olduğuna dikkat edin, çünkü x86 uygulamaları doğal 2 GB bellek tavanına sahipti. Çok miktarda bellek tüketen bellek sızıntısı olan bir uygulama için IIS 7.5'te çok daha kolaydır.

Ayrıca geri dönüşüm uygulama havuzlarının büyük bir hayranı değilim. Bir uygulama havuzum varsa ve çalışan tek uygulamayım, kodumuzda yanlış bir şey yoksa, muhtemelen uygulama havuzunu geri dönüştürmeye gerek yoktur. Ve uygulamada bir kusur varsa, nihai uygun işlem kodu düzeltmek olacaktır.

— Greg Askew
kaynak

32bit kapağı hafızaya kaydettiğiniz için teşekkür ederiz. Bunları nasıl unuttuğumu bilmiyorum. Ayrıca, bir uygulama havuzunu çökertecek kadar kusurlu bir uygulamanız varsa, koda erişebildiğinizi varsaymak suretiyle düzeltmek için doğru yaklaşımı düşünüyorum. Tavsiyen için teşekkür ederim!

— Eric Burcham

Kendi testlerimizi yaptık. Bir uygulama havuzunun çalıştırılması, aynı uygulama havuzundaki uygulamaları çalıştırmanın üstünde, uygulama havuzu başına yaklaşık 64.000 ek yüke sahip gibi görünüyor. Bu, bellek tüketimini izlemek için performans izleyiciyi kullanarak 12 saatlik bir örneklem süresinin üzerindedir. Bu 64-bit bir sunucudaydı. Bu basit testin doğru olduğu ortaya çıkarsa, uygulama başına bir uygulama havuzunun kaynak maliyetinin modern donanım için temel olarak ihmal edilebilir olduğunu düşünüyorum.

— Eric Burcham