IIS server and web.config configuration optimization guide

1. Modify the maximum number of IIS work processes a. Please consider the following points: 1. Each work process will consume system resources and CPU usage; too many work processes will Lead to rapid consumption of system resources and CPU utilization; 2. Each worker process has its own state data. If the web application relies on the worker process to save state data, it may not support the use of multiple worker processes. 3. Competing for resources, let multiple worker processes run the same application will cause resource competition b. Modify the maximum number of ISS work processes to improve the performance of the application pool processing request 1. In IIS 6.0 Web Garden , specifying the number of worker processes for an application pool can improve the performance of the application pool processing requests. When the server load is small and no additional work processes are required, IIS 6.0 automatically reduces the actual number of worker processes after a certain amount of time (default 20 minutes, configurable); if the load becomes larger, additional work processes are required, IIS 6.0 again increases the number of work processes. All of this is done automatically and requires no administrator intervention. 2. Modify the method as follows: Modify the configuration of the machine.config of the server .net framework. Directory: C:\\WINDOWS\\Microsoft.NET\\Framework64\\v2.0.50727\\CONFIG\\machine.config Place the “processModel” node“ allowDefinition”value is set to “Everywhere" Modify the maximum number of iis working processes in the server: Method: Right-click on the iis application pool--> Properties-> &ldquo Maximum number of working processes Note: After testing, the server is 32 (16 * 2) core 32G memory, set to 5 performance is optimal. (PS: The processModel element (ASP.NET Settings Schema) element configures the processing model for the server (including all ASP.NET applications on the server). Therefore, the processModel setting can only be placed in the Machine.config file and cannot be Any settings in the Web.config file are rewritten.) 2. Cancel IIS web access record a. Turn off IIS access records to improve web performance 1. IIS6.0 defaults to open IIS access records for the web. When logging is turned on, IIS will faithfully record all IIS access records. The contents of these log files are very complex, such as access time, client IP, which link to access, cookies, etc., as well as Method, UserAgent, etc. These records not only take up a lot of disk space but also greatly affect the performance of the web server. Someone has done a review, stopping IIS access records can improve web performance by 5% to 8%. 2. Method: Open IIS Manager, navigate to the specific web site, right click and select “Attributes”, and uncheck the “Record Access” tab under the “Main Directory” tab. Config configuration optimization (production environment) 1. Remove useless HttpModules d. Not all Modules are required, remove the unused HttpModules can improve the request speed 1.asp.net default HttpModules management request pipeline control each request. For example: SessionStateModule intercepts every request, parses the session cookie to load the appropriate session in the HttpContext. But not all Modules are required, for example: if you don't need membership, you don't need to configure the FormsAuthentication module; if you don't use Windows identity There is no need to configure WindowsAuthentication for authentication. These modules are only included in the pipeline, and some non-essential code is executed for each request. 2. The default module definition is in machine.config (set in the web.config of the website to indicate that the current website is valid) ($WINDOWS$\\Microsoft.NET\\Framework\\$VERSION$\\CONFIG). If you do not need these pipelines, the configuration is as follows:

The code is as follows: <httpModules> <!--Remove unnecessary nodes and increase the request speed--> <remove name="OutputCache" /> <remove name="Session" /> <remove name="WindowsAuthentication" /> <remove name="FormsAuthentication" /> <remove name="PassportAuthentication" /> ; <remove name="RoleManager" /> <remove name="UrlAuthorization" /> <remove name="FileAuthorization" /> <remove name="AnonymousIdentification" /> < ;remove name="Profile" /> </httpModules>

2. Turn off page-level uselessness The <pages> node in Web.config configures global definition page-specific settings, such as profile scope ASP.NET directives within pages and controls. The default enableViewState property is “true”, which turns on the view. If you don't use this mechanism, you can set it to “false”. The default autoEventWireup attribute is “true”, which turns on page events. If you don't use this mechanism, you can set it to “false”. The default buffer property is “true”, which turns on the HTTP response buffer. The default enableViewStateMac property is "false", which turns on the view state of the page and runs a computer authentication check (MAC) to place user tampering. If set to true, performance will be degraded. The default validateRequest defaults to true. There is a cross-site scripting attack and a SQL injection vulnerability attack in the authentication user input. If there is a match, an HttpRequestValidationException will be sent. 3. Set CustomError to Non-Off State The <customErrors> node in Web.config is used to define information about some custom error messages. This node has two attributes, Mode and defaultRedirect. The defaultRedirect attribute is an optional attribute indicating the default URL redirected to the application when an error occurs. If this attribute is not specified, a general error is displayed. The Mode property is a mandatory property. It has three possible values. They represent the following meanings: Mode Description On means that the local and remote users will see the custom error message. Off Disables custom error messages, and both local and remote users see detailed error messages. RemoteOnly means that local users will see detailed error messages, and remote users will see custom error messages. It is necessary to explain the concept of local users and remote users. When we access the asp.net application, the machine used to publish the asp.net application is the same as the local machine, otherwise it is called the remote user. In the development and debugging phase, in order to facilitate the search for errors, the Mode property is recommended to be set to Off, and the Mode property should be set to On or RemoteOnly during the deployment phase to avoid the detailed error information exposing the details of the program code and attracting hackers. The configuration is as follows:

The code is as follows: <customErrors mode=" On " defaultRedirect="Error.html"/>

4. Disable debugging in Web.config < The compilation> node configures all compilation settings used by ASP.NET. The default debug attribute is “true”, which allows debugging, and there is no problem with this configuration during the development phase. However, after the official deployment is online, this will affect the performance of the support interface, so it should be set to “false” after the program is compiled. The configuration is as follows:

The code is as follows: <compilation debug="false" />

5. Connection concurrency configuration Connection concurrency limit means that the same ip is initiated for the same domain. The maximum number of connections. In fact, this limitation exists in most Microsoft products or components. Generally, this value is 2/4, which means that by default, the same ip accesses the same domain and at most 2 connections are established. The default is 2, which is too low. This means that each IP can only have up to two requests to your website, which can cause congestion. The connectionManagement node in asp.net can set the maximum number of connections initiated by a single ip pair with a certain domain. The configuration is as follows:

The code is as follows: <system.net> <connectionManagement> <add address="*" maxconnection="100" /> </connectionManagement> </system .net>

address represents which domain, maxconnection represents the maximum number of connections. 6. Remove the ASP.NET version header from the http header. enableVersonHeader: Specifies whether ASP.NET should output the version header. Use this property to determine which version of ASP.NET you are currently using. For production environments, this property is not required and can be disabled. Configuration example:

The code is as follows: <httpRuntime enableVersionHeader="false" />