IIS ve ASP.NET performans iyileştirme makalelerine de linkler içeren oldukça faydalı bir indeks. Mutlaka "favoriler" altına eklenmeli:

Developer Tools & Platforms Performance
http://support.microsoft.com/kb/974348

--
AMB
 

Microsoft'ta Escalation Engineer olarak çalışan Doug Stewart'ın blog'unda (http://blogs.msdn.com/dougste/) oldukça faydalı bir bilgiye rastladım. IIS 7.0 ve IIS 7.5 için tüm konfigürasyon ayarlarına aşağıdaki web sitesinden ulaşabilirsiniz: 

IIS 7.0 and 7.5 configuration reference
http://www.iis.net/configreference

Bir başka favorilere eklenmesi gereken kaynak :)

Geçerli olduğu platformlar:

IIS 7.0
IIS 7.5

--
AMB

This is a hot topic discussed in the forums and we have decided to put this on a knowledge base article:

Web services may fail on Microsoft Internet Information Services (IIS) 7.5 and Windows 7 Service Pack 1 with .NET Framework 4.0 due to extensionless URL handlers
http://support.microsoft.com/kb/2520479

Here is the symptoms you may see:

Consider the following scenario.  You have a Microsoft Windows 7 server running Microsoft Internet Information Services (IIS) and the .NET Framework 4.0.  Your IIS web applications host web services (for example .asmx or WCF-based services) or JSON web services using .aspx page methods.  You install Service Pack 1 for Windows 7.  After installing the service pack, your web applications may begin to suffer from undesirable or unexpected behavior including (but not limited to):

• Additional internal server-side requests are issued to serve the requested resource. The requested resource is eventually served to the client as expected.
• The web service processing fails and the application returns an error to the client, or other similar unexpected behavior occurs.

For more details please read the KB article.

Applies To

Web Services, .NET 4.0, IIS 7.5, IIS 7.0

--
AMB

Application pool, IIS 6.0 ile birlikte gelen bir kavramdır. IIS 6.0 içinde yarattığınız web siteleri için ayrı application pool’lar tanımlayabilir ya da birden fazla web sitesini aynı application pool içinde çalıştırabilirsiniz. Çok kabaca, eğer iki web siteniz ayrı application pool’lar içinde çalışıyorsa, sitelerden bir tanesinde yaşayacağınız bir problemden, application pool’lar ayrı olduğu için diğer site etkilenmeyecektir. Bu tanımlamaya göre, application pool’ları, web sitelerini birbirlerinden izole çalışmak için kullanabilirsiniz.

Application pool ayarlarına baktığınız zaman, bazı özellikler göreceksiniz. Bunlardan bir tanesi de application pool’un “recycle” özelliğidir.

“Recycle”, yine çok kabaca, application pool’un yeniden başlatılması gibi düşünülebilinir. Eğer uygulamanızda bir takım problemler yaşıyorsanız ve bu application pool’un memory kullanımı çok yüksek ise, application pool’u recycle ettirmek, application pool’un kullandığı memory miktarının düşürülmesini sağlayacaktır. Tabi ki böyle bir sorun varsa, uygulanızı debug etmek ve sorunun neden kaynaklandığını bulmak çok daha doğru bir yaklaşım olacaktır.

Application pool ayarlarına baktığımız zaman karşımıza gelen ilk ekran “recycling” ekranıdır. Burada, yazıma konu olan “Recycle worker process (in minutes)” ayarından kısaca bahsetmek istiyorum. Default olarak IIS 6.0 içinde burada göreceğiniz değer 1740 dakika olacaktır. Yani, bu application pool, her 1740 dakikada bir recycle edilecektir. Bunun anlamı, 1740 dakikada bir bu application pool’un ilgili olduğu worker process kapatılacak ve yeni bir worker process başlatılacaktır. Ancak, bunun yan etkileri de olacaktır. Örneğin, eğer session’ları inproc, yani application pool memory’sinde tutuyorsanız, bu recycle işlemi sonucunda kullanıcılarınız, session’ları kaybedecektir.

1740 dakika, 29 saattir. Yani default ayar tutulduğu zaman her 29 saatte bir application pool recycle edilecektir. Basit bir hesap yaparsak, gece 00:00’da recylce eden application pool, bir sonraki seferde sabah 05:00’te recyle edecektir. Bir sonraki recycle, sabah 10:00’da olacaktır. Bir sonraki recycle ise 15:00’a denk gelecektir. Göreceğiniz gibi, bu default ayarla, recycle eden saatleri, uygulamanızın az kullanıldığı saatler olarak belirleyememiş oluyorsunuz.

Bunu engellemek için, bu seçeneği kaldırıp, bunun yerine application pool’un daha spesifik bir saatte recycle edecek şekilde ayarlayabilirsiniz. Örneğin, “Recycle worker process at the following times” seçeneğini aktif hale getirip, uygulamanızın en az kullanıldığı bir saatte recycle edilmesini sağlayabilirsiniz. Bu ufak değişiklik, size gelen şikayetleri azaltacaktır.

Geçerli olduğu platformlar:

IIS 6.0
IIS 7.0
IIS 7.5

Kaynaklar:

Configure Application Pool Recycling (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1eee28e2-b319-4b4e-8267-a8c0aa0dcf36.mspx?mfr=true

How Worker Process Recycling Works (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/24e3c22e-79a9-4f07-a407-dbd0e7f35432.mspx?mfr=true

--
AMB

“Web siteniz varsa, doğal olarak arama makinalarında arama yapıldığında ilk sıralarda görünmesini istersiniz. Fakat web siteniz söz konusu arama makinasının kriterlerine uygun şekilde tasarlanmamışsa, siteniz arama sonuçlarında ilk sıralarda çıkmayabilir; üstelik aranan kelimeyle gayet de ilgili bir iş yapıyor olsanız bile...”

Yukarıdaki paragraf ilginizi çektiyse ya da aynı dertten muzdaripseniz, Microsoft’un ücretsiz “Search Engine Optimization” yazılımı ile ilgili bilgi almak isteyebilirsiniz J Bu durumda size çalışma arkadaşım Faruk Çelik’in, "Ücretsiz SEO Toolkit" başlıklı makalesini incelemenizi öneririm.

--
AMB

(Bu makale, http://blogs.msdn.com/b/webtopics/archive/2009/08/04/iis7-and-above-using-freb-to-capture-dumps-for-a-long-running-request.aspx adresinde yayınlanmış olan makalenin Türkçe’sidir – orijinal makale yazarı olan Rakki Muthukumar’dan izin alınmıştır)

Dump analizi ile web uygulamalarınızda karşılaşılabilecek performans / hang / crash problemlerine çözüm bulabilirsiniz. Dump toplamak için uygulamanın çalıştığı platforma göre Debug Diagnostic Tool ya da Debugging Tools For Windows gibi uygulamaları kullanabilirsiniz. Örneğin, web uygulamanızın uzun süre yanıt vermiyor durumda kaldığı durumlarda bahsedilen araçlarla worker process’in (w3wp.exe) dump’ını alarak inceleyebilirsiniz.

Ancak bazı senaryolarda problemin oluştuğu anı yakalayamayabilir ve dump toplayamayabilirsiniz. Örneğin, web uygulamanızın çok kısa aralıklarla geç yanıt verdiğini düşünün. Mesele bir ASP.NET sayfasının normalde yanıt verme süresi 3 saniye olsun ve bazı durumlarda bu süre 40 saniyeye kadar çıksın ama siz problemi tespit ettiğiniz anda tekrar normale dönmüş olsun. Bu durumda uygulamanın problemli zamanını yakalayamadığınız için dump toplama şansınız yoktur.

Bu gibi durumlarda IIS 7.0 ile birlikte gelen Failed Request Tracing özelliğini kullanabilirsiniz. Failed Request Tracing ile yaratacağınız kurallara göre IIS’in ilgili sayfada hangi modüllerde neler yaptığını görebilirsiniz. Ancak sayfanızda, uygulamanızın çalışmasının uzun sürmesine neden olan problemleri her zaman Failed Request Tracing ile yakalayamayabilirsiniz.

Failed Request Tracing ile sayfanın çalışmasının belli bir süreyi geçmesi durumunda spesifik bir EXE’nin çalışmasını sağlayabilirsiniz. İşte bu özelliği kullanarak uygulamanın çalışma süresinin belli bir süreyi geçmesi durumunda dump aldırabilirsiniz.

Aşağıda, bu konfigürasyonun nasıl yapıldığını anlatmaya çalışacağım. Dump toplamak için “Debugging Tools For Windows” uygulamasını kullanacağız.

Debugging Tools For Windows kurulumu

İlk olarak IIS’in çalıştığı server üzerine Debugging Tools For Windows’u indirip kurulumunu yapın. Aracı aşağıdaki web sayfasından indirebilirsiniz:

Debugging Tools for Windows 32-bit Version
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Debugging Tools for Windows 64-bit Version
http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx

İşletim sisteminiz 64bit olsa bile indireceğiniz versiyon, application pool’unuzun çalıştığı mimariye göre değişecektir. Eğer application pool’unuz 32bit ise 32bit debugger’ı, 64bit ise 64bit debugger’ı indirip kurmalısınız.

Örneğimde application pool’un 64bit çalıştığını varsayıyorum.

Process’im 64bit olduğu için http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.11.1.404.msi adresinden x64 versiyonunu server’a indirip kurulumunu yapın. Bu versiyon, debugger’ın son versiyonu değildir ve adplus.vbs script’ini kullanmaktadır. Eğer yeni versiyonu indirmek isterseniz yukarıdaki linklerde bulunan SDK download’u kullanabilirsiniz. Yeni versiyonda adplus script’i exe olarak değişmiştir, dolayısıyla aşağıdaki ayarlarda değişiklik yapmanız gerekecektir.

Debugger kurulumunu c:\Debuggers64 isimli bir klasöre yapın. Eğer kurulumu bu klasöre yapmayı unutursanız, kurulumu yaptığınız klasörün içindeki tüm dosyaları c:\Debuggers64 isimli klasöre kopyalayabilirsiniz. Kurulum herhangi bir registry ayarı yapmamakta, sadece dosyaları kurulum klasörüne kopyalamaktadır.

Kurulumu yaptıktan sonra dump’ların oluşacağı klasörü yaratın. Ben örneğimde c:\dumps klasörünü kullanıyorum. Failed Request Tracing kuralı ile dump’ı bu klasör içinde oluşturacağız.

Failed Request Tracing konfigürasyonu

Bu noktada, değişiklikleri yapmadan önce ilk olarak IIS’in konfigürasyonunun bir yedeğini almanız iyi olacaktır. Herhangi bir problemde kolayca yedekten geri dönebilirsiniz. Bunun için C:\Windows\System32\inetsrv\config klasöründeki .config dosyalarının bir kopyasını almanız yeterli olacaktır.

Failed Request Tracing konfigürasyonu için aşağıdaki adımları takip edin:

NOT: Eğer IIS arabirimde Failed Request Tracing Rules ikonunu göremiyorsanız, ilgili modülü server’a kurmamışsınız demektir. Bu durumda Server Manager üzerinden “Roles” ayarlarında, “Web Server (IIS) à Healths and Diagnostics” altından “Tracing”i eklemeniz gerekmektedir:



Bu modülü kurduktan sonra aşağıdaki ayarlar ile Failed Request Tracing kuralını oluşturabilirsiniz:

İlk olarak IIS arabirimini açın ve uzun süren isteklerin çalıştığı web sitesine geçin ve “Failed Request Tracing Rules” ikonuna çift tıklayın:



Gelen ekranda sağ taraftaki “Actions” paneli altında “Edit Site Tracing”e tıklayın. Eğer aktif değilse “Enable”a tıklayarak aktif hale getirin. Burada default değerleri bırakmanızı tavsiye ederim.



Tracing’i aktif hale getirdikten sonra “Add”e tıklayarak “All content (*)”i seçin ve next’e tıklayın. Gelen ekranda sadece “Time taken (in seconds)” seçili olsun ve değerini 30 yapın. Bu ayar ile 30 saniye ve üzerinde olan istekler için Failed Request Tracing logları toplanacaktır.

Daha sonra tekrar next’e tıklayın, bütün provider’ları seçili bırakın (ASP, ASPNET, ISAPI Extension ve WWW Server) ve Finish’e tıklayın. Aşağıdaki şekilde görüldüğü gibi bir kuralın oluşmuş olması lazım:



Şimdi uygulamanızın web.config dosyasını açıp aşağıda sarı ile işaretli olan eklemeleri yapın. Bu ayarlar, debugger’ın c:\Debuggers64 klasörüne kurulduğu ve server’da c:\dumps isimli bir klasör olduğu varsayımına göre yapılmıştır. Eğer kurulum ya da dump’ların oluşacağı klasör farklıysa aşağıdaki ayarları da uygun şekilde değiştirin.

NOT: Aşağıda ASPNET ve WWW Server ile ilgili ayarlar, server’ınızda yüklü olan modüllere göre farklılık gösterebilir.

<tracing>
<traceFailedRequests>
<addpath="*"customActionExe="c:\windows\system32\cscript.exe"customActionParams="c:\Debuggers64\adplus.vbs -hang -quiet -pn w3wp.exe -o c:\dumps"customActionTriggerLimit="20">
...
...
</add>
</traceFailedRequests>
</tracing>

Yukarıda göreceğiniz customActionExe, ilgili Failed Request Tracing kuralında belirtilen kriterler oluştuğu zaman çalıştırılacak uygulamayı ve customActionParams bu uygulamanın alacağı parametreleri belirler.

Son olarak “custom action” ayarlarının server bazında aktif hale getirilmesi gerekmektedir. Bunun için administrator yetkileriyle bir komut satırı açarak c:\Windows\System32\inetsrv klasörüne geçin ve aşağıdaki komutu çalıştırın:

appcmd.exe set config  -section:system.applicationHost/sites "/[name='Wait'].traceFailedRequestsLogging.customActionsEnabled:true" /commit:apphost

Bu adımdan sonra ayarlar tamamlanmıştır. Web sitenizde herhangi bir sayfanın çalışması 30 saniyeye ulaştığı zaman hem Failed Request Tracing logları hem de tüm worker process’lerin (w3wp.exe) dump’ları belirtmiş olduğunuz klasörde oluşacaktır.

Ayarların test edilmesi

Ayarları test etmek için bir test.aspx sayfası hazırlayarak Page Load event’ine aşağıdaki kodu ekleyin:

System.Threading.Thread.Sleep(40000);
Response.Write("Sayfa yüklendi...");

Yukarıdaki kod parçası C# için yazılmıştır ve ASPX isteğinin yanıtlandığı thread’i 40 saniye boyunca askıya alacaktır. Dolayısıyla bu sayfanın çalışması en az 40 saniye sürecektir. İsteğin yanıtlanması 30 saniyeyi geçtiği anda hem Failed Request Tracing logları hem de dump dosyasının oluşmuş olması gerekir. Eğer dump oluşmadıysa yukarıdaki ayarları tekrar kontrol edebilirsiniz.

Geçerli olduğu platformlar:

IIS 7.0
IIS 7.5

Referanslar:

IIS7 (and above) – Using FREB to capture dumps for a long running request
http://blogs.msdn.com/b/webtopics/archive/2009/08/04/iis7-and-above-using-freb-to-capture-dumps-for-a-long-running-request.aspx

Troubleshooting Failed Requests Using Tracing in IIS 7
http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

Tess Ferrandez - Debugging Labs
http://blogs.msdn.com/b/tess/archive/tags/debugging+labs/

--
AMB

Hello,

one of my colleauges shared the following blog post which provides a list for free e-books for different technologies including web and mobile development. Definetly it is worth to check:

Huge collection of Free Microsoft eBooks for you, including: Office, Office 365, SharePoint, SQL Server, System Center, Visual Studio, Web Development, Windows, Windows Azure, and Windows Server
http://blogs.msdn.com/b/mssmallbiz/archive/2013/06/18/huge-collection-of-free-microsoft-ebooks-for-you-including-office-office-365-sharepoint-sql-server-system-center-visual-studio-web-development-windows-windows-azure-and-windows-server.aspx

Enjoy

—
AMB

“Windows Phone App Studio is about giving everyone the ability to create an app, regardless of experience. It also can radically accelerate workflow for all developers.”

Read the full story at Windows Phone Developer Blog.

—
AMB

A colleague of mine, Matteo Pagani, has published a free e-book about Windows 8.1 Universal Application Development, it is a second part of the same topic. Below is what he says about it:

More Windows 8.1 Succinctly

Move beyond the development stage and present your apps to the world. In this final volume, author Matteo Pagani guides you through the process of readying your Windows 8.1 and Windows Phone 8.1 apps for the Windows Store. You’ll learn how to integrate your app into Microsoft’s infrastructure to maximize its functionality and appeal.

Table of Contents

1. Publishing an Application on the Store
2. Interacting with the Network
3. Interacting with the Real World
4. Contracts and Extensions
5. Creating Multimedia Applications
6. Tiles and Notifications
7. Supporting Background Operations

You can get a copy of the e-book from the following site:

http://www.syncfusion.com/resources/techportal/ebooks/morewindows8.1

—
AMB

Consider the following scenario:

• You are running a web application on IIS and you need to collect a memory dump of the application pool process (w3wp.exe).
• W3wp.exe in subject consumes huge memory, for example, around 40 GB, and it takes some time to write the dump file.
• When you try to collect a memory dump of the worker process, it is terminated and the memory dump is corrupted.

This may be happening because of the “health monitoring” configuration of the application pool. For example the following screenshot shows the default settings for health monitoring:

The following happens with the default configuration seen in the screenshot above:

• WAS will monitor application pool by pinging it every 30 seconds (Ping Period configuration).
• If the process does not respond in 90 seconds (Ping Maximum Response Time) then WAS will terminate the process.

Remember that the process is suspended when a dump is written to the disk, which means that it will not respond to WAS’ ping request and if that exceeds the ping maximum response times then WAS will terminate the process.

If you see the similar behavior and you need to collect a useful dump then you may need to increase the ping timeout or set “ping enabled” to false until you collect the memory dump.

Please note that changing these settings will cause application pool recycle.

—
AMB

PROBLEM

• You are running an ASP.NET application in IIS.
• You noticed that the worker process shuts down and restarts.
• At the same time you see one or both of the following events in the event logs:

Event ID 2262: ISAPI ‘C:\Windows\Microsoft.NET\Framework\<version>\aspnet_isapi.dll’ reported itself as unhealthy for the following reason: ‘Deadlock detected’.

Event ID 5013: A process serving application pool ‘app_pool name’ exceeded time limits during shut down. The process id was ‘<PID>’.

ACTION PLAN

Memory dump analysis is required to find out the root cause most of the times. You can follow the steps below to collect memory dumps automatically:

1)  Download ProcDump from https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx on your server and extract it.

2)  Copy the ProcDump.exe, ProcDump64.exe and Eula.txt files to both C:\Windows\System32 and C:\Windows\SysWOW64 folders.

3)  Create C:\Dumps folder where the dump files are written. You can use another local disk or folder but you should change it in the step 5.

4)  Open IIS manager, find your application pool which is reported unhealthy and open its advanced settings.

5)  Find Process Orphaning settings and configure it as below, as seen in the screenshot:

1. Enabled: True
2. Executable: c:\windows\system32\procdump.exe
3. Executable Parameters (if your application pool is 32bit): -accepteula -ma %1% c:\Dumps
4. Executable Parameters (if your application pool is 64bit): -accepteula -64 -ma %1% c:\Dumps
   
    

6)  Click OK to close the dialog box. When the same issue happens the dump(s) should be generated in the c:\Dumps (or where you configured) folder.

NOTES

1)  Do not forget to disable Process Orphaning when the dumps are collected.

2)  A memory dump is a snapshot of a process memory so the size of a dump file will be approximately the same as the size of the process in the memory. For example, if a process consumes 2 GB of memory when taking the dump, then the dump file will take approximately 2 GB in the disk. Please set a location where you have enough free disk space.

3)  Avoid writing dumps to a network share or a slow disk (is there any slow disk left?) because when a dump is being written, all threads of the process will be suspended. Any requests arrive while the dump is written will be queued until the dump file is completed.

TIP FOR ANALYZING THE MEMORY DUMP

The issue described in the PROBLEM section may be mostly related with some requests waiting to acquire a lock which is owned by another thread. If a lock is not relased for enough time, IIS assumes that the process is deadlocked and WAS terminates the worker process, reports it as unhealthy and restarts a new one.

You can open the dump in WinDBG and use SOS extension’s SyncBlk command to analyze the locks. Try to find out which thread owns the lock and why it does not release that (e.g.: thread may be doing a long running task in a lock). You can also use Debug Diagnostic’s Auto Analyse feature and review the report generated.

MORE INFORMATION

Process Orphaning feature of IIS allows you to avoid terminating the “unhealthy” or “deadlocked” process so the “orphaned” process could live in the memory, without accepting any requests, for troubleshooting purposes (for example attaching a debugger to it or taking the dumps of it).

REFERENCES

Managing, Tuning, and Configuring Application Pools in IIS 7.0
https://technet.microsoft.com/en-us/library/cc745955.aspx

APPLIES TO

All supported IIS versions
All ASP.NET versions

When an HTTP request is made from a client machine to a web server, a TCP connection is established between the client and the server machines. That TCP connection is built on the port numbers on both server and client sides. A web server, for example IIS, listens on port 80 for HTTP and on port 443 for SSL requests. Those are default ports of course and can be configured.

On the client side, operating system uses a random port number from an available port list, between 1024 – 65535.

You can read the following article for the TCP / IP details:

How TCP/IP Works
https://technet.microsoft.com/en-us/library/cc786128(v=ws.10).aspx

Getting the client port information

IIS writes the server side port configured for the web site request on the IIS logs. However it does not write the client port and you may need to get that client port information for some reason.

Luckily that information is available on Server Variables. From Microsoft’s explanation, the Server Variables means the following:

IIS server variables provide information about the server, the connection with the client, and the current request on the connection. Ref.: https://msdn.microsoft.com/en-us/library/ms524602(v=vs.90).aspx

Enhanced Logging feature of IIS 8.5

In IIS 8.5, the administrator has the option of logging additional custom fields from request or response headers, or from server variables. Ref.: http://www.iis.net/learn/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85

That means that we can log any information available in request or response headers, or in server variables.

Logging the client port number

Client Port information is stored as REMOTE_PORT in server variables. So you can follow the instructions below:

• Open IIS 8.5 manager and choose the site you would like to configure logging with client port. You can do that on server level as well so all of the sites can log the client port.
• Open Logging and choose Select Fields.
• On Custom Fields section click Add Field.
• Give a name for Field Name, note that you cannot use space.
• Choose Server Variables from Source Type.
• Type REMOTE_PORT in Source text box.
• Click OK. 

You should be seeing something like below:

From that point on, you should be seeing the client TCP port logged in the IIS logs. A sample output is below. For readability reasons I disabled most of the logging fields. I also disabled the HTTP Keep-Alive for my test web site so each request I made from the same client just created a new TCP/IP connection:

Applies To:

IIS 8.5 and onwards.

For IIS 7.0, 7.5 and 8.0 you can use Advanced Logging module (http://www.iis.net/downloads/microsoft/advanced-logging).

—
AMB

Let’s assume that you are running an ASP.NET application and you disable the File Change Notifications in web.config file (for ASP.NET 4.5 or later) or in the registry as explained in https://support.microsoft.com/kb/911272.

However the appDomains are still unloaded and reloaded when you change a web.config file.

—
AMB