IIS ve ASP.NET Notları https://docs.microsoft.com/archive/blogs/cenkiscan/feed.xml IIS ve ASP.NET üzerine denemeler Tue, 16 Apr 2019 04:52:22 GMT en-US hourly 1 IIS Best Practices https://docs.microsoft.com/archive/blogs/cenkiscan/iis-best-practices Wed, 20 Jun 2012 06:54:19 GMT https://blogs.msdn.microsoft.com/cenkiscan/2012/06/20/iis-best-practices/ For a very long time, I have been asked for a document on IIS best practices. There are some blogs/articles on the Internet but I could not find a complete one. Actually, the main problem here is that there can not be “best practices” for a web server. A web server is just a hosting platform for applications, and, each and every application has its own needs. Therefore, in many cases, you will not have one universal best practice.

Having these said, I tried to gather a list of things one should check while configuring an IIS server (and an application on IIS). I should say that these are my own thoughts based on my own experience. It is very likely that you will find some resources mentioning just the opposite of what I say.

NOTE: Some of the links I provided below refer to content in Turkish because I usually blog in Turkish.

Application pool configuration


Logging

Content

Security

  • Configure "Request Filtering":
    • “Allow unlisted file name extensions": Uncheck (add only the extensions you will use)
    • “Allow unlisted verbs": Uncheck (add only the verbs you will use) 
    • Lower "request limits" if possible
  • Remove HTTP headers which identifies the server and application. These headers are believed to cause security vulnerability:
       Server ve ASP.NET başlıkları
       http://blogs.msdn.com/b/cenkiscan/archive/2012/01/30/server-ve-asp-net-ba-l-klar.aspx
  • Set NTLM permissions on the content folders as needed; do not give unnecessary permissions to unnecessary users. You should consider authentication and impersonation configurations to do this.
  • Remove any unused modules to reduce attack surface. For example, if you do not  specifically need WebDAV, do not install it.

Other

 

CENK ISCAN

]]> Server ve ASP.NET başlıkları https://docs.microsoft.com/archive/blogs/cenkiscan/server-ve-asp-net-balklar Mon, 30 Jan 2012 01:39:34 GMT https://blogs.msdn.microsoft.com/cenkiscan/2012/01/30/server-ve-asp-net-balklar/ IIS sunucuları, gelen istekleri yanıtlarken HTTP başlık (header) bölümünde kendileriyle ilgili bazı bilgiler sunar:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Set-Cookie: ASP.NET_SessionId=awfthz48bftycdu3f7lpkku1; path=/; HttpOnly
Date: Mon, 30 Jan 2012 08:41:49 GMT
Content-Length: 5975

Yukarıdaki altı çizili üç başlığın, uygulamanın veya sunucunun çalışmasına direkt bir etkisi yoktur, dolayısıyla bunları engelleyebiliriz. Nitekim, pek çok güvenlik taramasında bu başlıklların bulunması potansiyel güvenlik açığı olarak nitelendirilir.Bunun gerekçesi, potansiyel bir saldırgana uygulama ortamı ve versiyonu bilgisi sunmasının, saldırganın işini kolaylaştıracak olmasıdır.

Bunları engellemek oldukça kolaydır:

  • Server: IIS/6.0: Bunun için sunucuya UrlScan kurulup, urlscan.ini dosyasında DisableServerHeader = 1 şeklinde bir ayar tanımlanmalıdır. Ancak, UrlScan default olarak bazı kısıtlamalar getireceğinden tüm ayarların üzerinden geçmekte fayda olacaktır.
  • Server: IIS/7.x: Bunun için sunucuya url rewrite modülü kurulup aşağıdaki ayarın yapılmasi gerekiyor:
            <rewrite>
                <outboundRules>
                    <rule name="replace server header" patternSyntax="Wildcard">
                        <match serverVariable="RESPONSE_SERVER" pattern="*" />
                        <action type="Rewrite" value="MyServer" />
                    </rule>
                </outboundRules>
            </rewrite>
    Yukarıdaki ayar, "Server" başlığını kaldırmayıp değerini "MyServer" olarak değiştirecektir.
  • X-Powered-By: ASP.NET: Bu header'ı kaldırmak için IIS'in arayüzünde "HTTP Response Headers"tan silmek yeterlidir.
  • X-AspNet-Version: 2.0.50727: Bu header'ı ASP.NET eklediği için bunu .NET Framework'ün machine.config dosyasına asağıdaki ayarı ekleyin:
    <httpRuntime enableVersionHeader="false" />

Kaynaklar:

URL Rewrite
HTTP Response Headers (IIS 7)
HttpRuntimeSection.EnableVersionHeader Property

CENK

]]> 401 Unauthorized https://docs.microsoft.com/archive/blogs/cenkiscan/401-unauthorized Tue, 13 Sep 2011 07:07:00 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/09/13/401-unauthorized/ Daha önce de kimlik doğrulama ile ilgili bir yazı yazmıştım. Orada detaylı olarak bahsettiğim gibi, 401 hataları kimlik doğrulama işleminin normal bir parçasıdır. Ancak bazen, her şeyi doğru yaptığımız halde tarayıcı bize kullanıcı adı/şifre sorar ve buna rağmen giriş yapamayız ve 401.1 "Logon failed" hatası alırız.

Bu tür bir sorunun ilk akla gelen nedeni, elbette kullanıcı adı veya şifrenin yanlış olmasıdır. Eğer yetki sorunumuz olsa 401.3 "Unauthorized due to ACL on resource" veya bazı durumlarda da 403 hataları alırdık. Ama kullanıcı adımız ve şifremiz doğru olsa bile 401.1 alabileceğimiz bir senaryo var: Kerberos.

IIS 6.0 (Windows 2003 SP1 sonrası) ve 7.x versiyonlarında "integrated windows authentication" kullandığımızda kullanıcıya hem NTLM hem de Negotiate seçenekleri sunulur. Kullanıcı - aslında tarayıcı - bunlardan duruma göre birini seçer. Tarayıcının ilk tercihi - Intranet uygulamalarında - Negotiate/Kerberos kullanmak yönündedir. Aslında IIS de Kerberos kullanımını default olarak destekler. Ancak burada küçük bir sorun vardır: NTLM kullanmak için hiçbir ekstra ayara gerek olmazken, Kerberos için Domain Controller üzerinde bazı ayarların yapılması gerekmektedir. Bu ayarları yapmadıysak, kullanıcıdan gelecek olan Kerberos bileti IIS'e hiçbir şey ifade etmeyecek ve 401.1 hatası dönecektir.

Bu tür bir problemle karşılaştığımızda, sorunun Kerberos olup olmadığını anlamanın çok basit bir yolu vardır: Internet Explorer'da aşağıdaki seçeneği kaldırmak:

Tools -> Internet Options-> Advanced -> Enable Integrated Windows Authentication

image

İsim biraz yanıltıcı olsa da bunu kaldırmak aslında sadece Kerberos kullanımını engeller, NTLM kullanılmasını sağlar. Eğer bu şekilde bir istekte bulunduğunuzda sorunsuz giriş yapabiliyorsanız, o zaman sorun kesin olarak Kerberos ayarlarındadır.

NOT 1: Bu ayarı değiştirdikten sonra IE'yi kapatıp yeniden açmak gerekecektir.

NOT 2: Kerberos ayarları ve sorun çözümleri için aşağıdaki makalelerden yararlanabilirsiniz:

Kerberos authentication and troubleshooting delegation issues 

How to troubleshoot Kerberos-related issues in IIS

CENK İŞCAN

]]> 404 Dosya Bulunamadı https://docs.microsoft.com/archive/blogs/cenkiscan/404-dosya-bulunamad Tue, 23 Aug 2011 05:58:01 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/08/23/404-dosya-bulunamad/ "404 Dosya bulunamadı" hatasının nedeni aslında çok açık görünüyor: "Dosya bulunamadı". Ancak işin aslı tam olarak öyle değil.

IIS, ve bazı başka web sunucular, güvenlik nedeniyle bir isteği blokladıklarında, yine güvenlik nedeniyle neden bloklandığını son kullanıcıya söylemezler. Bunun yerine "404 Dosya bulunamadı" hatası dönerler. Bazı senaryolarda IIS içeriğin gerçekte var olup olmadığına bile bakmadan bu hatayı döner.

Önce bu "bazı senaryolar"ın ne olduğundan biraz bahsedelim. IIS'e ait olan sürücü (driver) http.sys ve IIS 7.x ile gelen "Request Filtering" modülü, gelen her isteği işlenmeden önce bir takım güvenlik kontrollerinde geçirirler. Bu kontrollerden bazıları:

  • İstenilen dosyanın uzantısı
  • İstekte bulunulan metot (verb)
  • İstek verisinin ebatı
  • URL uzunluğu

Tüm bunlar için tanımlı değerlerin dışında bir istek geldiği takdirde istemciye 404 hatası dönülecektir. Ancak elbette bir site yöneticisinin bunları ayırt edebiliyor olması lazımdır. İşte bunu da IIS loglarında hata alt-kodları ile yapabiliyoruz:

  • 404.0 - Not found.
  • 404.1 - Site Not Found.
  • 404.2 - ISAPI or CGI restriction.
  • 404.3 - MIME type restriction.
  • 404.4 - No handler configured.
  • 404.5 - Denied by request filtering configuration.
  • 404.6 - Verb denied.
  • 404.7 - File extension denied.
  • 404.8 - Hidden namespace.
  • 404.9 - File attribute hidden.
  • 404.10 - Request header too long.
  • 404.11 - Request contains double escape sequence.
  • 404.12 - Request contains high-bit characters.
  • 404.13 - Content length too large.
  • 404.14 - Request URL too long.
  • 404.15 - Query string too long.
  • 404.16 - DAV request sent to the static file handler.
  • 404.17 - Dynamic content mapped to the static file handler via a wildcard MIME mapping.
  • 404.18 - Querystring sequence denied.
  • 404.19 - Denied by filtering rule.

IIS 7.x sunucuların tüm hata kodlarının listesine şuradan ulaşabilirsiniz.

CENK İŞCAN

]]> System.InvalidOperationException https://docs.microsoft.com/archive/blogs/cenkiscan/system-invalidoperationexception Tue, 16 Aug 2011 04:21:00 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/08/16/system-invalidoperationexception/ Uzunca bir süredir hakkında yazmak istediğim bir "exception"dı bu, ancak henüz fırsat bulabildim. Tam hata mesajımız şu şekildedir:

System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool.

This may have occurred because all pooled connections were in use and max pool size was reached.

Aslında hata mesajı yeterince açık ama "InvalidOperationException" tabiri biraz yanıltıcı olabiliyor. Hatanın nedeni çok net: havuzda bağlantı kalmamış.

Veritabanı bağlantılarında (ister SQL Server olsun, ister Oracle veya başka bir veritabanı), genel olarak bir bağlantı havuzu kullanılır; veritabanına her istek için yeniden bağlantı açılıp kapatılmaz. Bu havuzun da bir kapasitesi vardır. Örneğin SQL Server için bunun ön tanımlı değeri 100'dür (max pool size değeri). Yani havuzda herhangi bir anda en fazla 100 adet bağlantı bulunur ve veritabanına gidecek tüm işler bu havuzdan bir bağlantı alıp, veritabanı işini yapıp, sonra tekrar havuza bırakırlar.

Şimdi bu senaryoda ters gidebilecek bazı şeyler var: İsteklerin gelme hızı veritabanından yanıt alma hızımızda fazla olursa, bir süre sonra havuzda bağlantı kalmayacaktır. Bu durumda yeni gelecek olan bir istek 15 saniye boyunca havuza bağlantı dönmesini bekler (connect timeout süresi kadar). İşte tam da bu süre sonunda havuz hala boşsa yukarıdaki exception alınır.

ÇÖZÜM:

Bu tür bir sorun yaşadığımızda bağlantı havuzunun ebatını artırabiliriz. Bağlantı cümlesine "max pool size" parametresini ekleyip buna 100'den büyük bir değer vermek yeterli olacaktır. Ancak bu değeri artırırken, bunun veritabanına eşzamanlı daha fazla istek gönderilmesi anlamına geleceğini, yani veritabanındaki yükü artıracağını unutmamak gerekir. Bazı durumlarda bu, veritabanının daha da yavaş yanıt vermesine ve durumun daha da kötüleşmesine neden olabilir.

Veritabanı bağlantılarını kullanırken dikkat etmemiz gereken çok önemli bir nokta vardır: İşi biten bağlantı, eğer Close() veya Dispose () metotlarından birini çağırırsak, hemen havuza geri döner. Eğer baglantıyı kapatmayı unutmuşsak, bu durumda bu bağlantı ilk hemen havuza dönemez, GC tarafından temizlenmeyi bekler ve havuza dönme süresi uzar. Bu da, yukarıdaki sorunu yaşama ihtimalimizi kat kat artıracaktır. "Max pool size" değerini 5000 verdiği halde bu hatayı zaman zaman alan uygulamalarla karşılaştım. Bu nedenle daha uygulamayı geliştiriken açılan her bağlantının mutlaka kapatıldığından emin olmalıyız. Bağlantıyı açtıktan sonra oluşabilecek sorunlara karşı try/catch bloğu kullanıp, finally altında bağlantıyı kapatmalıyız. Bir diğer yöntem de using kullanmak olacaktır.

Özetle, kod geliştiriken göz ardı edeceğimiz ufak şeyler, uygulama yük altına girince büyük sorunlar olarak karşımıza çıkabilir. Sadece veritabanı bağlantıları anlamında değil, her türlü nesneyle işimiz bittiğinde, eğer nesnenin bir "Close()" metodu varsa çağırmalıyız. Ve bunu işimiz biter bitmez yaptığımızdan, ve bunu engelleyecek bir sorun olmayacağından emin olmalıyız.

CENK İŞCAN

]]> OutOfMemoryException (OOM) https://docs.microsoft.com/archive/blogs/cenkiscan/outofmemoryexception-oom Fri, 05 Aug 2011 00:06:18 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/08/05/outofmemoryexception-oom/ Daha önceki bir yazımda .NET ortamındaki uygulamaların hafıza kullanım limitlerinden bahsetmiştim. Gün geçtikçe daha çok uygulama 64bit ortamda koşmaya başlıyor, ve bu da yazılımcılara belirli bir rahatlık sağlıyor. Ancak bu rahatlık, bazen istenmeyen sonuçlara neden olabiliyor.

Son birkaç ay içerisinde çok sayıda OutOfMemoryException problemi üzerinde çalıştım. Bunlardan çoğu da 64bit sunucu üzerinde 64bit ASP.NET uygulamalarıydı. Böyle bir ortamda aslında OOM almak çok kolay değildir. 64bit bir .NET uygulaması, 64bit sunucuda hafıza kullanımında oldukça yüksek rakamlara çıkabilir:

Limit = ( RAM + Page File Ebatı ) * 60%

Örneğin 8 GB RAM''e sahip bir sunucuda, page file ebatı da 12 GB ise:

Limit = ( 8 + 12 ) 60% = 12 GB

Bu kolay ulaşabileceğimiz bir rakam değildir - gerçi ben 35 GB'a ulaşan "worker process"le karşılaştım ama bu kesinlikle istisnaydı.

Bahsettiğimiz limitlere ulaşmadan çok önce OOM alınan senaryolarla karşilaştım son dönemde çokça. Bunların nedeni ise, ebatı 2GB olan nesneler olarak karşımıza çıktı. Bu çok fazla bilinmez, çünkü zaten 32bit ortamlarda bu limite ulaşmak imkansızdır, ancak bir .NET uygulaması içerisinde yaratılabilecek nesneler 2GB'tan büyük olamazlar. Eğer bir nedenle uygulamanız içerisinde bu ebatta bir nesne yaratılmaya kalkışılırsa, bunun sonucu da OOM olmaktadır - hafıza kullanım limitlerinden çok uzak olsak da.

Limitlere ulaşmadan OOM almanın bir diğer nedeni de, sunucu hafıza'sının "fragmante" olması olabilir. Örneğin, oldukça büyük, belki birkaç yüz MB kadar, bir nesne yaratmak istediniz. GC, hafızadan bu ebatta tek parça bir alan almak ister. Eğer hafızamız çok fazla fragmante olmuşsa bu ebatta bir alan bulamayabilir, ve toplam boş alanımız bundan çok daha fazla olsa da OOM alabiliriz.

Sonuç olarak, ortamımız ve uygulamamız 64bit olsa dahi, uygulamamızı geliştirirken hafıza kullanımına dikkat etmemiz gerekir. Uygulamamız OOM almasa bile, hafıza kullanımı .NET uygulamalarında performansa direkt etki eder.

CENK İŞCAN

]]> Web uygulamalarında performansa dair...-2- https://docs.microsoft.com/archive/blogs/cenkiscan/web-uygulamalarnda-performansa-dair-2 Wed, 18 May 2011 02:09:00 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/05/18/web-uygulamalarnda-performansa-dair-2/ Bir .NET uygulamasında performanstan bahsederken ilk konuşulması gereken şey, uygulamanın hafıza kullanım miktarıdır. .NET uygulamalarında - ve özellikle de ASP.NET uygulamalarında da - yanlış hafıza yönetimi ve/veya kullanımı performansı direkt olarak olumsuz etkileyecektir.

.NET uygulamalarında hafıza yönetimi işini (yani nesneler için hafızada yer ayrılması ve sonra temizlenmesi) Garbage Collector (GC) mekanizması yapar. GC'nin faklı çalışma şekilleri vardır. Normalde hangi modun kullanılacağına CLR otomatik olarak karar verir. ASP.NET uygulamaları genellikle çok CPU'lu makinelerinde çalışacağından, "server GC" kullanırlar. Bunun anlamı, en basit şekliyle, şudur:

Uygulama çalışmaya başladığında mantıksal (logical) CPU sayısı kadar "thread", GC'ye ayrılır. Bu thread'ler GC dışında bir iş yapmazlar. GC devreye girmeye karar verdiğinde aktif tüm istekler, tüm işler askıya alınır ve bu thread'ler hafızadaki nesneleri taramaya ve temizlemeye başlarlar. Bu iş boyunca yeni gelen istekler de kuyruğa düşerler. Yani uygulamamız tamamen durur.

Sırf bu tanıma bakarak bile şu sonucu çıkarabiliriz: GC ne kadar seyrek devreye girerse ve devreye girdiğinde ne kadar kısa süre çalışırsa, uygulamanın genel performansına olumsuz etkisi o kadar az olacaktır. Ancak asıl sorun da tam olarak burada karşımıza çıkıyor: Bunu nasıl sağlayacağız?

.NET uygulamalarında, manuel olarak tetiklemek dışında GC'ye müdahale edemiyoruz. Manuel tetiklemenizi de, çok istisnai senaryolar dışında - kesinlikle önermiyoruz. GC sayısını azaltmanın ve kısa sürmesini sağlamanın tek yolu, uygulamanın genel hafıza kullanımını düşürmektir. Ancak bu, özellikle de ASP.NET uygulamalarında çok da kolay bir iş değildir.

  • İlk dikkat etmemiz gereken nokta "string" birleştirme (concatination) işleridir. Daha önce bir blogumda bahsettiğim gibi aşırı miktarda "string concatination" yapmak memory kullanımını olumsuz etkileyecektir. Bununla ilgili çok sayıda sorunla karşılaştık.
  • Bir başka nokta, aşırı büyük DataTable/DataSet nesneleri yaratmamak, veritabanından sadece ihtiyacımız olduğu kadar veri çekmektir.
  • Session'larda tutulan nesneler potansiyel olarak uzun süre hafızada kalacaklarından bunların ebatları ve adetlerine de dikkat etmenizi öneririm.
  • Ebatı 85000 byte'tan büyük nesneler diğerlerinde farklı bir "heap"te tutulur  ve GC onlara farklı davranır. Bu nedenle bu büyüklükteki nesnelerin sayısının olabildiğince az olması gerekir.
  • "Viewstate" nesnelerinin ebatı oldukça büyüyebilmektedir. Bunları kontrol altında tutmak, ve ihtiyaç olmayan kontroller için kapatmak da fayda sağlayacaktir.
  • Veritabanı başlantı nesneleri gibi "Close" veya "Dispose" metoduna sahip nesnelerin işleri biter bitmez kapatılması gerekir. Böylece mümkün oduğunca kısa süre hafızada kalmış olurlar.

Tüm bunlara ve daha fazlasına, uygulamanızın yapısına ve ihtiyaçlarına göre sizin karar vermeniz gerekmektedir.

Performance monitor

Aşağıdaki performans sayaçları hem hafıza kullanımımız hakkında fikir verecektir, hem de GC'nin genel performansımıza etkisini gösterecektir (tüm sayaçlar ".NET CLR Memory" altındadır):

  • # Bytes in all Heaps: Uygulama üzerindeki tüm .NET nesnelerinin toplam ebatını gösterir.
  • # Gen 0, 1, 2 Collections: Bu sayaçlar, her bir "generation" için GC'nin toplam kaç defa devreye girdiğini gösterir. Burada göreceğimiz rakamlardan ziyade artış hızı önemli olacaktır. Bununla ilgili net bir rakam vermemiz mümkün değildir. Ancak, örneğin, saniyede onlarca defa GC devreye giriyorsa, bunun performansa etkisinin çok olumsuz olacağını rahatlıkla söyleyebiliriz. İşte tam da bunları azaltmanın yolu yukarıda bahsettiklerimizdir.
    Bu sayaçlarla ilgili bir diğer önemli nokta da, Gen 0, 1 ve 2 arasındaki orandır. İdeal olan aralarında sırasıyla 100:10:1 gibi bir oran olmasıdır. Elbette gerçekte bu neredeyse hiç bir zaman mümkün olmayacaktır. Ama yine de birbirlerine çok yakın değerler görüyorsak hafıza kullanımızda sorunlar/sıkışmalar yaşadığımız açıktır.
  • # Induced GC: Manuel olarak tetiklenen GC adedini gösterir. Bunun, yukarıda da bahsettiğim gibi, sıfır olmasını bekliyoruz.

Kaynaklar

Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

Automatic Memory Management
http://msdn.microsoft.com/en-us/library/f144e03t.aspx

<gcServer> Element
http://msdn.microsoft.com/en-us/library/ms229357.aspx

<gcConcurrent> Element
http://msdn.microsoft.com/en-us/library/yhwwzef8.aspx

]]> İstemci IP adresleri https://docs.microsoft.com/archive/blogs/cenkiscan/stemci-ip-adresleri Thu, 03 Feb 2011 01:34:22 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/02/03/stemci-ip-adresleri/ Bugün pek çok web uygulaması birden fazla sunucu üzerinde hizmet vermektedir. Bu sunucular arasında yük dağılımı ise çeşitli şekillerde yapılabilmektedir:

  • DNS round-robin
  • Windows Network load balance servisi
  • Yük dağıtım cihazları (hardware load balancer)
  • Applicatıon Request Routing (ARR) modülü (bununla ilgili bir yazı yazmayı planlıyorum)

Yük dağıtım cihazları ve ARR'nin ortak bir sorunu var: We sunuculara yönlendirdikleri isteklerde istemci IP adresi yerine kendi IP'lerini gönderirler. Elbette yapacağımız ayarlarla bunu kapatabiliriz. Ancak kapatırsak bu cihazların/madülün sağlayacağı pek çok hizmetten ve özellikten de mahrum kalıyoruz.

Sunucu loglarında istemci IP adreslerinin bulunması çoğu zaman zaruridir. Bun göre istatistiki veriler çıkarabileceğimiz gibi, geçmişe dönük güvenlik taramaları da yapabiliriz. Veya belirli bir kullanıcının yaşadığı sorunların nedenini araştırırken de bu bilgiye ihtiyacımız olacaktır. Yük dağıtım cihazları da, yukarıdaki soruna çözüm için, istemci IP adresini sunucuya bir "header" ile gönderebilmektedirler. Hatta genel kabul görmüş "header" adı olarak da "X-Forwarded-For" kullanılır.

Burada bir sonraki sorun, "X-Forwarded-For" "header"ı ile gelen bu bilgiyi IIS loglarına kaydetmektir. IIS 6.0 ve öncesinde bu iş için yük dağıtıcı cihaz firmalarının sağladığı veya Internet'te örnek kodlarını bulabileceğiniz "ISAPI filter"lar kullanılıyordu. Ancak IIS 7.0'dan itibaren mimari değiştiği için bunları kullanma şansımız kalmadı. İşte bu noktada "Advanced Logging" modülü devreye giriyor. Daha önceki bir yazımda kısaca bahsettiğim bu modülü kullanarak istediğiniz hemen her şeyin IIS loglarına kaydedilmesini sağlayabilirsiniz. Elbette buna istek "header"ları da dahildir. Bunun için izlemeniz gereken adımlar aşağıdaki gibidir:

  1. "Advanced Logging" modülünü indirip kurun.
  2. IIS Manager arayüzünde bunu tanımlamak istediğiniz web sitesini sol taraftan seçip, orta bölümde "Advanced Logging" ikonuna çift tıklayın:
    AL_1
  3. "%COMPUTERNAME%*Server"ı seçip sağ taraftan "Clone Log Definition."a tıklayın:
    AL_2
  4. Daha sonra yeni yaratılan log tanımını seçip sağ taraftan "Edit Logging Fields."a tıklayın:
    AL_3
  5. Açılan pencerede "Add Field." butonuna tıklayarak şu bilgilerle bir tanım yaratın:
    Field ID: OrigClient-IP
    Category: Default
    Source type: Request Header
    Source name: X-Forwarded-For
    AL_4
  6. Bu yarattığımız tanımı aktif hale getirmek için "Advanced Logging" arayüzünde yine yeni yaratılan tanımı seçip sağ taraftan "Edit Log Definition."a tıklayın:
    AL_5
  7. Bu ekranda "Select Fields" butonuna tıklayarak loglanmasını istediğiniz tüm alanları seçebilirsiniz. Buradaki listede yeni eklediğimiz "OrgClient-IP" isimli alanı da görebilirsiniz:
    AL_6

Tüm bu tanımlardan sonra, IIS'in kendi loglarının yanısıra bu loglar da tutulmaya başlayacaktır. İhtiyaçlarınıza bağlı olarak IIS'in loglarını kapatabilir, ya da her ikisinin de tutulmasını sağlayabilirsiniz.

Advanced Logging, IIS loglarının aksine kernel modda yazılmadığı için, direkt "kernel cache"ten yanıtlanan veya kernel seviyesinden bloklanan istekler bu loglarda bulunmayacaktır.

Son olarak şunu da belirtmek lazım: Bu şekilde tutacağınız loglar da W3C formatında olacağından Log Parser ile inceleme şansınız olacaktır.

NOT: Yukarıda bahsettiklerim, "Advanced Logging" modülü ile gelen özelliklerden sadece biri ("Custom logging"). Diğer ilginç ve faydalı olabilecek özellikleri "Request Filtering", "Real-time logging" ve "Client logging"dir. Bunlarla ilgili detaylı bilgileri aşağıdaki linklerden bulabilirsiniz:

Advanced Logging
http://technet.microsoft.com/en-us/library/ee791852(WS.10).aspx

Advanced Logging
http://www.iis.net/download/AdvancedLogging

CENK ISCAN

]]> Log Parser: Örnek komutlar https://docs.microsoft.com/archive/blogs/cenkiscan/log-parser-rnek-komutlar Mon, 17 Jan 2011 04:51:31 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/01/17/log-parser-rnek-komutlar/ Daha önceki bir yazımda Log Parser isimli araçtan ve ne şekilde kullanılabileceğinden bahsetmiştim. Şimdi ise, işinize yarayacağına inandığım bazı örnekleri paylaşmak istiyorum. Aşağıda her komutun açıklamasını ve hemen altında da örnek bir sonucu bulabilirsiniz:

  • Sayfa bazlı olarak istatistiki bilgiler çekmek için aşağıdaki komutu kullanabilirsiniz (bunun bir benzerini daha önceki yazımda da paylaşmıştım ancak bu seferki daha detaylı bilgi sağlıyor). Sonuç olarak çıkan text dosyada her sayfa için ortalama ve maksimum yanıtlanma süresi, ortalama ve maksimum istek ve yanıt büyüklükleri bulunmaktadır. İdeal bir ortamda, herhangi bir sayfanın ortalama yanıtlanma süresinin bir saniyenin altında olmasını bekleriz - ancak elbette bunun istisnaları olabilir. Aşağıdaki görüntü, log parser'dan alınan sonucun Excel'e taşınmasıyla elde edilmiştir.
    • logparser "SELECT COUNT(*) As Hits, AVG(time-taken) AS AvgTimeTaken, MAX(time-taken) AS MaxTimeTaken, AVG(cs-bytes) AS AvgRecievedBytes, MAX(cs-bytes) AS MaxRecievedBytes, AVG(sc-bytes) AS AvgSentBytes, MAX(sc-bytes) AS MaxSentBytes, TO_LOWERCASE(cs-uri-stem) AS PageName, sc-status AS Status, sc-substatus AS SubStatus INTO istatistik.txt FROM *.log GROUP BY PageName, Status, SubStatus ORDER BY PageName" -i:IISW3C -o:W3C
      image

 

  • Aşağıdaki komutla istek sayılarının - tüm sayfalara ve tüm içeriğe gelen toplam isteklerin - zamana göre dağılım grafiğini çizdirebiliriz:
    • logparser "SELECT TO_LOCALTIME(QUANTIZE(TO_TIMESTAMP(date, time), 600)) AS ZamanDilimi, COUNT(*) AS IstekAdedi INTO IstekDagilimi.gif FROM *.log GROUP BY ZamanDilimi ORDER BY ZamanDilimi" -i:W3C -o:CHART -chartType:ColumnClustered -chartTitle:"İstek Dağılımı"
      IstekDagilimi

 

  • Ortalama istek sayısının ortalama yanıtlanma süresine etkisini aşağıdaki grafikte görebiliriz:
    • logparser "SELECT TO_LOCALTIME(QUANTIZE(TO_TIMESTAMP(date, time), 600)) AS ZamanDilimi, MUL(AVG(time-taken), 20) AS 20x_AvgTimeTaken, COUNT(*) AS Hits INTO AvgTimeGraph.gif FROM *.log GROUP BY ZamanDilimi ORDER BY ZamanDilimi" -i:W3C -o:CHART -chartType:line -chartTitle:"Ortalama yanıt süresi / Toplam istek sayısı" -e:10
      image

 

  • Dosya uzantılarına göre gelen isteklerin dağılım grafiğini aşağıdaki şekilde çıkarabiliriz:
    • logparser "SELECT TOP 10 CASE EXTRACT_EXTENSION(cs-uri-stem) WHEN '' THEN '/' ELSE EXTRACT_EXTENSION(cs-uri-stem) END AS Uzantı, COUNT(*) AS Adet INTO extensions.gif FROM *.log GROUP BY Uzantı ORDER BY Adet DESC" -i:W3C -o:chart  -chartType:PieExploded3D -chartTitle:"Dosya uzantısı dağılımı"
      extensions

CENK ISCAN

]]> ProcDump https://docs.microsoft.com/archive/blogs/cenkiscan/procdump Mon, 17 Jan 2011 04:39:00 GMT https://blogs.msdn.microsoft.com/cenkiscan/2011/01/17/procdump/ Daha önceki bir yazımda, hangi sorun türlerinde ne şekilde "dump" alınması gerektiğinden bahsetmiştim. O yazımda bahsetmediğim ancak zaman zaman rastladığımız bir senaryo da, kısa süreli CPU yükselmeleridir.

 

Yüksek CPU kullanımı sorunlarında, arka arkaya 2-3 defa "hang dump" alıp incelemek gerekecektir. Ancak, CPU kullanımı sadece bırkac saniye için yükselip sonra düşüyorsa - ve birkaç saniye sonra bunu tekrarlıyorsa - bu şekilde alacağımız dumplar her zaman yardımcı olmayabilir. İşte tam da bu soruna bir çözüm olarak Mark Russinovich bir araç geliştirmiş: ProcDump.

Bu araç ile, belirli bir "process", belirli bir süre, belirli bir limitin üstünde CPU tüketirse dump aldırabiliyoruz. Komut satırından çalısan bu aracın oldukça basit bir kullanımı var. Aşağıda da paylaştığım kendi "yardım"ında detaylı olarak kullanımdan behsediliyor ve oldukça güzel örnekler de verilmiş. ancak birkaç şeyin altını özellikle çizmek istiyorum:

  • Bir process'in CPU kullanımı X değerini Y süresi boyunca geçtiğinde toplam Z adet dump al diyebiliyoruz.
  • "Crash" dump aldırabiliyoruz.
  • Bir process'in hafıza kullanımı belirli bir limite geldiğinde dump aldırabiliyoruz.
  • Dump almadan önce process'in RAM üzerinde bir kopyasını yaratabiliyoruz. Böylece dump dosyasının diske yazılması sırasında process hizmet vermeye devam edecektir.

Aşagıda procdump.exe'nin yardım bilgilerini bulabilirsiniz:

C:\>procdump.exe /?

ProcDump v3.01 - Writes process dump files
Copyright (C) 2009-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Monitors a process and writes a dump file when the process exceeds the
specified CPU usage.

usage: procdump [-64] [[-c CPU usage] [-u] [-s seconds]] [-n exceeds]  [-e [1]] [-h] [-m commit usage] [-ma | -mp] [-o] [-p counter threshold] [-r] [-t] < <process name or PID> [dump file]] | [-x <image file> <dump file> [arguments]>
   -64     By default Procdump will capture a 32-bit dump of a 32-bit process
           when running on 64-bit Windows. This option overrides to create a
           64-bit dump.
   -c      CPU threshold at which to create a dump of the process.
   -e      Write a dump when the process encounters an unhandled exception.
           Include the 1 to create dump on first chance exceptions.
   -h      Write dump if process has a hung window (does not respond to
           window messages for at least 5 seconds).
   -m      Memory commit threshold in MB at which to create a dump of the
           process.
   -ma     Write a dump file with all process memory. The default
           dump format includes thread and handle information.
   -mp     Write a dump file with thread and handle information, and all
           read/write process memory. To minimize dump size, memory areas
           larger than 512MB are searched for, and if found, the largest
           area is excluded. A memory area is the collection of same
           sized memory allocation areas. The removal of this (cache)
           memory reduces Exchange and SQL Server dumps by over 90%.
   -n      Number of dumps to write before exiting.
   -o      Overwrite an existing dump file.
   -p      Trigger on the specified performance counter when the threshold
           is exceeded. Note: to specify a process counter when there are
           multiple instances of the process running, use the process ID
           with the following syntax: "\Process(<name>_<pid>)\counter"
   -r      Reflect (clone) the process for the dump to minimize the time
           the process is suspended (Windows 7 and higher only).
   -s      Consecutive seconds CPU threshold must be hit before dump is
           written (default is 10).
   -t      Write a dump when the process terminates.
   -u      Treat CPU usage relative to a single core.
   -x      Launch the specified image with optional arguments.
Use the -accepteula command line option to automatically accept the
Sysinternals license agreement.

To just create a dump of a running process, omit the CPU threshold. If
you omit the dump file name, it defaults to <processname>_<datetime>.dmp.

Example: Write up to 3 dumps of a process named 'consume' when it exceeds
         20% CPU usage for five seconds to the directory
         c:\dump\consume with the name consume.dmp:
            C:\>procdump -c 20 -s 5 -n 3 -o consume c:\dump\consume
Example: Write a dump for a process named 'hang.exe' when one of it's
         windows is unresponsive for more than 5 seconds:
            C:\>procdump -h hang.exe hungwindow.dmp
Example: Write 3 dumps 5 seconds apart:
            C:\>procdump -s 5 -n 3 notepad.exe notepad.dmp
Example: Launch a process and then monitor it for excessive CPU usage:
            C:\>procdump -c 30 -s 10 -x consume.exe consume.dmp
Example: Write a dump of a process named 'iexplore' to a dump file
         that has the default name iexplore.dmp:
            C:\>procdump iexplore
Example: Write a dump of a process named 'outlook' when total system
         CPU usage exceeds 20% for 10 seconds:
            C:\>procdump outlook -p "\Processor(_Total)\% Processor Time" 20
Example: Write a dump of a process named 'outlook' when Outlook's handle count
         exceeds 10000:
            C:\>procdump outlook -p "\Process(Outlook)\Handle Count" 10000

CENK

]]>