Internet Information Services, earlier known as Internet Information Server is an extensible web server created by Microsoft for use with the Windows NT family of servers. IIS contains numerous configuration parameters that affect IIS performance. IIS logs can help IT department with metrics which can be a range of websites and specific statistics, including Internet Protocol (IP) addresses, user information and site visits as well as dates, times and queries.
IIS uses a flexible and efficient logging architecture. It installs logging module plugins to help administrators customize the way that IIS server activity is logged which can be configured in IIS Manager. When an HTTP transaction, occurs, which is usually a loggable event, IIS calls the selected logging module, which then writes to one of the logs stored in %SystemRoot%system32Logfiles.
With the growth and deeper penetration of Internet technology, web servers for hosting web pages have become more advanced and allow advanced logging for the tracking and analysis of server information and data. IIS is integrated with several types of log files to help with server use and analysis. These log file formats provide information on various aspects which help optimize the IIS performance. There are 3 main options for writing to IIS log files.
You can configure your Web site or your FTP site to record log entries that are generated from user activity and from server activity. Log data can help you control access to content, determine content popularity, plan security requirements, and troubleshoot potential Website issues or FTP site issues eventually improving your overall Network Performance. For instance, you can use the log files to help determine whether a security event has occurred. The source of the attack can be identified by the data in the log files which can be saved to different file formats. While enable logging, you can specify the file format to be used. By default, IIS uses the W3C Extended log file format which is the preferred log type to use. This log format lets you configure lots of extended attributes that are useful to help analyze security.
IIS Manager can help optimize the IIS performance by selecting the logs and making sure only relevant metrics are collected. This can be done by configuring the IIS options out of the numerous configuration parameters available to monitor. The following steps can be taken in order to improve the performance of the IIS:-
Log Only Relevant Information instead of Everything
IIS logging should be minimum and should only include parameters that can be useful and relevant. Just because x number of parameters can be logged and tracked does not necessarily mean all of them to have to be tracked. Information is only useful if it’s relevant and timely, otherwise, there is information overload.
Disable ASP Debugging if not Required
Debugging of ASP.NET Applications and Web Services should be disabled for improving the IIS services. If IIS services produce a log and also simultaneously run debugging, it may strain the IT resources. This will affect the performance and may slow down IIS services.
Set the Value of ASP Threads Per Processor Limit Property
The default value of Threads Per Processor Limit is 25 and the maximum recommended value for this property is 100. The ASP Threads Per Processor Limit property specifies the maximum number of worker threads per processor that IIS creates. If you want to increase the value for the Threads Per Processor Limit follow these steps:
In the Connections pane, select the web server, click to select Features View, and then double-click the ASP feature. It should be made sure that the increase in limit does not depreciate the IIS performance or provide an unsatisfactory experience. These settings can have a dramatic effect on the scalability of the web applications and the performance of the server and as such caution is to be exercised in deciding the settings.
Tune the value of the ASP Queue Length property
The default ASP Threads Per Processor Limit property is normally set to a one-to-one ratio of queues to total threads. As an example, the ASP Queue Length property can be set to 100 without experiencing any performance issues and can be tuned from there if the ASP Threads Per Processor Limit property is set to 25 and there are four processors (4 * 25 = 100 threads). This is done to achieve the optimal use of the resources and achieve a balance between good response time and server load. The end goal of turning this property should be to make sure that the HTTP 503 (Server Too Busy) error being sent to clients when the ASP request queue is full, is minimized.
A low value of the ASP Queue Length property will mean the server will send the HTTP 503 error with greater frequency, whereas a higher value would make the users perceive that the server is not responding when in fact their request is waiting in the queue. Thus the queue has to be watched for unusual spikes and a usage pattern has to be observed before devising the optimum ASP Threads Per Processor Limit property. The other factor that needs to be observed is response time and the system can be throttled to avoid overload.
Tune the MaxPoolThreads registry entry
MaxPoolThreads is a REG_DWORD registry entry located at HKEY_LOCAL_MACHINESystemCurrentControlSetServicesInetInfoParameters with a default value of 4. This setting is used to specify the number of pool threads to create per processor. Pool threads keep a watch on the network for requests and process incoming requests. The MaxPoolThreads count does not include threads consumed by ISAPI applications. Generally, 20 threads per processor are considered normal.
Disable WCF services tracing
To disable WCF services tracing in a production environment, you can use the Configuration Editor Tool (SvcConfigEditor.exe). This should assure the performance of the IIS server is optimized.
Configure ASP.NET 2.0 and 4 MaxConcurrentRequests for IIS 7.5/7.0 Integrated mode
When ASP.NET 2.0 is hosted on IIS 7.5/7.0 in Integrated Mode and on IIS 7.5/7.0 in Classic Mode, the use of threads is handled differently. In Integrated mode, ASP.NET 2.0 restricts the number of concurrently executing requests instead of the number of threads concurrently executing requests. For synchronous scenarios, the number of threads will indirectly limit because the number of requests will be the same as the number of threads. But for asynchronous scenarios, the number of requests and threads will likely be very different because you could have far more requests than threads. The minFreeThreads and minLocalRequestFreeThreads of the “httpRuntime” element in the machine.config are ignored when you run ASP.NET 2.0 on IIS 7.5 in integrated mode. For IIS 7.5 Integrated mode, a DWORD named MaxConcurrentRequestsPerCPU within HKEY_LOCAL_MACHINESOFTWAREMicrosoftASP.NET2.0.50727.0 determines the number of concurrent requests per CPU.
.NET Framework 3.5 SP1 includes an update to the v2.0 binaries that supports configuring IIS application pools via the asp.net.config file. This configuration applies to integrated mode only (Classic/ISAPI mode ignores these settings)
In IIS 7.5 Integrated Mode, the maxWorkerThreads and the maxIoThreads parameters in the “processModel” section of the machine. the config file is not used to govern the number of running requests, per se, but they are still used to govern the size of the CLR thread pool used by ASP.NET. When the “process model” section of the machine.config has “autoConfig=true” (which is the default setting), this will give the application pool up to 100 worker threads (MaxWorkerThreads) per logical CPU. So a common commodity server with 2 dual-core CPUs would have 400 MaxWorkerThreads. This should be sufficient for all but the most demanding applications.
With .NET Framework 4, the default setting for maxConcurrentRequestsPerCPU is 5000. Since it is a very large number, it will allow plenty of asynchronous requests to execute concurrently. For more information, see Element (Web Settings).
For IIS 7.5/7.0 Integrated mode, a DWORD named MaxConcurrentRequestsPerCPU within HKEY_LOCAL_MACHINESOFTWAREMicrosoftASP.NET4.0.30319.0 determines the number of concurrent requests per CPU. The registry key does not exist by default and the number of requests per CPU is limited to 5000.
Enable IIS HTTP compression
Enabling IIS HTTP compression will help to use available bandwidth more efficiently. HTTP compression enables faster transmission time between compression-enabled browsers and IIS, irrespective of your content being served from local storage or a UNC resource.
All these tweaks will help optimize IIS performance and optimize it to run smoothly. A lot of these steps are recommended by Microsoft itself.