IIS Sunucuda Performansı Etkileyen Faktörler

IIS SERVER DA PERFORMANSI ETKİLEYEN FAKTÖRLER

IIS Server da fiziksel donanımdan sunucu üzerinde çalışan diğer uygulama ve servislere varıncaya kadar performansı etkileyen birçok faktör bulunmaktadır. Web uygulamamızın verimli çalışması noktasında yukarıdaki adımlar dışında direkt IIS sunucu üzerinde yapılabilecek bir takım IIS Server performans tuning işlemleri bulunmaktadır.

1. İçerik Kullanımını Optimize Etmek

• Compression: Sunucu üzerinde yayınlanan içerik, doğrudan yanıt süresini etkiler. Eğer uygulamanız çok fazla bant genişliği tüketiyor veya network bant genişliği kullanımını optimize etmek istiyorsanız clienta döndüğünüz yanıtları sıkıştırmanız gerekmektedir. Bu sayede network üzerinde daha az paket transfer olacaktır. Örneğin mobil telefonlara publish edilen bir web uygulaması için içerik sıkıştırma önemli bir kavramdır. IIS, aşağıdaki içerik sıkıştırma seçeneklerini gerçekleştirebilir.

• Sadece statik dosyaların sıkıştırılması
• Sadece dinamik uygulama yanıtları
• Yukarıdakilerin her ikisi de

İçerik sıkıştırma tipini belirlemeden önce aşağıdaki resimdeki gibi bu özelliği etkinleştirmemiz gerekiyor.

• Static Content Compression: Statik içerik (htm,html) sıkıştırmanın dinamik içerik sıkıştırmaya göre avantajı şudur: Client tarafından bir request geldiğinde içerik direkt servis edilir ve IIS te cachelenir. Gelecek diğer request için IIS, cahce den yanıt dönebilir. Böylece CPU ve Memory kaynakları içerik sıkıştırmak için daha az kullanılmış olur.(Networkün iyi olduğu ancak CPU ve Memory kaynak kullanımının önemli olduğu yapılar için uygundur)
   
• Dynamic Content Compression: Dinamik uygulama (asp.net,php,asp) yanıtlarının sıkıştırılması CPU kaynak kullanımını doğrudan etkileyebilir. Çünkü IIS, sıkıştırılmış dinamik içerikleri cachelemez. Örneğin kullanıcı dinamik içerikli bir dosya için IIS’ e request yaptı ve IIS bu requesti CPU ve Memory de işleyip yanıtladı. Dinamik içerik sıkıştırma gerçekleştiği için IIS herhangi bir caching yapmadı ve clienttan gelen her isteği her defasında sıkıştırıp aynı işlemi yaparak yeniden yanıtlayacak ve bu da CPU ve Memory kaynaklarının fazla kullanımına sebep olabilecektir.  (CPU ve Memory kaynaklarının iyi olduğu bir sunucu, düşük bant genişliğine sahip bir networkte çalışıyorsa bu özellik tercih edilebilir.)

Logging bölümünden send paketlerinin de loglanması aktif edilip compression öncesi ve sonrası kıyaslanabilir.

 

 

• Caching: Sunucunun, uygulama veya websitesinin performansını artırmak için IIS üzerinde caching işlemi yapılabilir. Caching işlemi aktif edildiğinde IIS, clienta döndüğü yanıtın bir kopyasını memory de saklar. Aynı talep başka bir client tarafından gerçekleştirildiğinde IIS, artık requesti tekrar işlemez ve cache deki yanıtı direkt olarak döner. Bu uygulama, web siteniz dışarıdan bir program çalıştırıyorsa(CGI gibi. Common Gateway Interface) veya harici bir kaynaktan (remote share veya database gibi) bir data içeriyorsa requestlere daha hızlı yanıt vermenizi sağlayacaktır.

• Maximum Cache Response Size : Outputcahce de tutulacak yanıtın (response) byte cinsinden en fazla nekadar olacağını belirler. Default 256 kb. Eğer bu değer ‘0’ yapılırsa response lar için bir üst limit koyma anlamını taşır.
   
• Cache Size Limit : IIS’ in, caching işlemleri için memory üzerinde nekadar kaynak kullanabileceğini mb cinsinden belirleyebilirsiniz. ‘0’ = Memory yönetim işlemini IIS’ e bırakmak anlamını taşır.
   
• Add Output Caching : Örneğin bir asp.net dosyanızın diğer dosyalardan daha uzun süre cachelenmesini istiyorsanız yeni bir caching rule u oluşturabilirsiniz.

1. Application Pool (Uygulama Havuzu) Üzerinde Yapılabilecek Ayarlar

Uygulama havuzu, her web uygulamasının ayrı permissionlarla, ayrı .net versiyonlarında, ayrı kaynak kullanım limitleri ile çalışabilmesine olanak tanır. Farklı web uygulamaları farklı application poollar kullanabildiği gibi aynı application pool içinde 100 lerce websitesi de çalışabilir.(ikinci durum Microsoft tarafından önerilmez)
IIS consol üzerinden veya appcmd.exe ile komut satırından application pool create edilebilir,start-stop edilebilir (appcmd start apppool /apppool.name:"ASP.NET v2.0" (isim boşluk içeriyorsa tırnak kullanmak zorundayız).

• General
  
• .Net Framevork Versiyon: 4.0 veya 2.0 olarak uygulamanın yazıldığı versiyona göre ayarlanabilir.
   
• Enable 32 Bit: Uygulama 32 bit platform uyumlu yazıldı ise özellik aktif edilebilir.
   
• Managed Pipeline Mode: IIS 7.0 öncesi IIS sürümlerinde Asp.net, bir isapi extension ı olarak çalışırdı. (C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll) Yani bir php den veya diğer uygulamalardan bir farkı yoktu. Ancak IIS 7.0 ile birlikte artık Asp.net bir external plugin gibi değil, IIS in bir parçası gibi davranmaktadır. Aşağıdaki listeden seçilecek Integrated veya Classic modlar, IIS in bir requesti işlerken nasıl davranacağını belirler. Classic modda IIS, IIS 6.0 gibi davranır. İstekler önce IIS e gelir sonra işlenmesi için aspnet_isapi.dll e gönderilir. İşlenen request tekrar IIS e gönderilir ve sonra clienta servis edilir. Ancak Integrated modda IIS ve Asp.net birlikte requesti işler. (Classic Mod sadece Integrated Mod un çalışmadığı durumlarda kullanılmalıdır)

 

IIS 6

 

IIS 7

• Maximum Queue Length: Kuyrukta tutulacak maksimum request (istek) limitini belirler. Örneğin 1000 limiti dolduktan sonra gelen yeni isteğe 503:Service Unavailable hata mesajını döndürür. Mevcut requestleri görmek için INETMGR konsolundan Sunucu adı / Worker Process / Application Pool a Sağ Tık / View Current Request denir. Burada görülen Private Byte ilgili worker process e (w3wp.exe) atanan memory miktarını belirtir. Bu memory başka processlerle ortak kullanılmaz.

İlgili Application Poola sağ tık View Application dediğimizde aşağıdaki gibi mevcut requestleri görebiliriz. Örneğin agent servisi ile o an haberleşen aktif clientları aşağıdaki gibi görebiliriz. Time Elapsed bölümü ilgili process işlenirken geçen zamanı vermektedir.

Maximum Queue Length hesaplaması :

MB cinsinden kullanılabilir memory * İşlemci Core sayısı * 10 / Toplam Application Pool Sayısı = Max. Queue Length.

Örneğin : 500 MB kullanılabilir (available) memory imiz olsun. 8 tane application pool umuz olsun. 2 çekirdek işlemcimiz olsun. Formül şu şekildedir:
500 * 8 * 2 / 10 = 800 (İdeal Queue Length Değeri)

• Start Automatically: Application pool create edilir edilmez başlasın. Veya sunucuyu yeniden başlattığımızda IIS başladığında application pool da hemen başlasın.

 

• CPU

• Limit: Task manager da görülen w3wp.exe processinin maximum kullanacağı CPU limiti. 0= No Limit
   
• Limit Action: Örneğin Limit 20 seçilirse ilgili w3wp.exe %20 CPU kullanımını aştığında buradaki değer NoAction ise sadece limit aşımına dair Event Viewer a log düşer. Ancak KillW3wp seçilirse bir alt satırdaki Limit Interval değeri kadar (yukarıdaki resimde 5 dakika boyunca) ilgili application pool stop durumda kalır web sitesi görüntülenemez. Service Unavailable hatası döner. 5 dakika sonunda process yeniden canlanır.
   
• Processor Affinity Enabled: Enable edildiğinde, Çok işlemcili sunucularda bir worker processin aynı işlemcide çalışmasını enforce eder. Cpu cache inin etkin kullanılması noktasında işe yaramaktadır. Bir process, bir core den diğerine geçerken ön belleği boşaltmaktadır. Process i belirlenen core (lar) da çalıştırmak bu noktada performans sağlayabilir. Örnek : Task Manager / Bir Process e Sağ Klik / Set Affinty dediğimizde o process in aşağıdaki gibi hangi core lar üzerinde çalışacağını belirleyebiliriz. Antivirüs Programı, Oyun, Flash Oyun Siteleri gibi cpu tüketimi fazla olan uygulamalar için de tercih edilebilir.

• Processor Affinty Mask: Hexadecimal cinsinden ilgili process in çalışacağı cpu yu belirtir. Eğer bir processi bir cpu ya atayacaksak ilgili cpu nun hexadecimal cinsinden karşılığını bulup Application Pool da processor afinity mask bölümüne yazmalıyız.

• Process Model:

• Identity: İlgili Application Pool u aşağıdaki gibi ön tanımlı hesaplarla çalıştırabilir veya kendi oluşturduğumuz bir kullanıcı ile çalışmasını sağlayabiliriz. Örneğin NetworkService kullanıcısı ön tanımlı bir Microsoft hesabıdır. Düşük seviyede yetkilere sahiptir. Uygulama kaynaklı buglardan doğabilecek riskleri minimuma indirebilmek için diğer hesaplardan isole edilmiş, düşük yetkili bir hesap ile application pool çalıştırılabilir.

EmreDeneme kullanıcısı ile çalıştırıldığında Task Manager da aşağıdaki şekilde görülmektedir.

• Idle Timeout: İlgili worker process e bir request gelmediğinde shutdown olmadan önce kaç dakika idle da beklesin.
   
• Load User Profile: NetworkService hesabının user profili system tarafından oluşturulmakta ve sürekli erişilebilir durumdadır. Ancak application poolu, kendi oluşturduğumuz kullanıcı ile çalıştırıyorsak ve uygulamamız user profilini de temp e yüklemeyi gerektiriyorsa özellik aktif edilebilir.
   
• Maximum Worker Process (w3wp.exe): Öncelikle Web Garden ve Web Farm kavramlarını bilmemiz gerekmektedir. Bir application pool bir sunucu üzerinde birden fazla worker process e sahipse buna Web Garden denir. Bir application pool birden fazla sunucuda worker processlere sahipse buna Web Farm denir. Web Farm’ da request önce load balancer a gelir, sonra load balancer arkada yükü az olan sunucuya isteği dağıtır…

 

• Worker Process sayısını artırmanın avantajı: Bir request uzun süre cpu tarafından işlenmeye çalışıyorsa response time ı kısaltmak için worker process sayısı artırılabilir.
   
• Worker Process sayısını artırmanın dezavantajı: sessionlar bir worker process ten diğerine taşınamayacağı için sessionlar kaybolmaktadır (yani oturumunuz kapanmaktadır). Web Farm veya Garden yapısı kullanılacaksa sessionların sql db gibi sabit bir yerde tutulması gerekir. Aynı şekilde viewstate ler de başka w3wp.exe lere taşınamamaktadır.

   

  Sonuç olarak Worker Process sayısını artırmaktan mümkün mertebe kaçınmalıyız ve 1 olarak bırakmalıyız.

 

• Ping Enabled:   Worker Process'in (w3wp.exe) ayakta olup olmadığı WAS (Windows Process Activation Service) tarafından kontrol edilir.

Worker Process Pinging, bildiğimiz ICMP (internet control messaging protocol) pinginden farklıdır. Bu ping işleminde, WAS ile Worker Process arasında dâhili bir bağlantı kanalı kullanılır.

Bir Worker Process'te istemciye gönderilen response ta yaşanan kayıp, ilgili Worker Process'in bu istemci request(ler)ini taşıyamadığı anlamına gelebilir.

WAS, Worker Process ten aldığı ping yanıtına bağlı olarak w3wp yi unhealty (sağlıksız çalışıyor) olarak bayraklandırıp ilgili w3wp yi shut down edebilir. Varsayılan olarak Worker Process Pinging Özelliği aktiftir. Application Pool veya uygulamanızın özelliklerine bağlı olarak pingleme zaman aralığını, ping yanıt süresini vs. ayarlamak durumunda kalabilirsiniz.

 

• Ping Maximum Response Time: Buradaki değer kadar saniye içerisinde w3wp.exe yanıt vermezse shut down edilir.
   
• Ping Periyod: Buradaki değer kadar aralıklarla ilgili worker processe ping atılır.
   
• Shutdown Time Limit: worker processin verilen requesti işleyip bitireceği zaman aralığı. Bitiremezse yok edilip yenisi oluşur.
   
• Start Time Limit: Verilen süre sonunda worker process canlanıp requestleri işleyebilecek hale gelmezse yok edilip yeniden oluşturulur.