A large number of timer_minbytespersecond,timer_connectionidle errors were found in the \logfiles\httperr log.
According to the online introduction, the following changes have been made:
1 Right-click the local Computer Selection property from IIS Manager. Tick allows you to edit the metabase directly.
2 Open the C:\Windows\system32\inetsrv\MetaBase.xml file in Notepad,
Search MinFileBytesPerSec To change the minfilebytespersec setting from 240 to 0.
Search ConnectionTimeout To change the ConnectionTimeout setting from 120 to 600.
MinFileBytesPerSec if not C:\Windows\system32\inetsrv\MetaBase.xml file is in C:\Windows\system32\inetsrv\MBSchema.xml file
3 Restart IIS.
In the modification Mbschema pay particular attention to stopping the IIS process, the first step is to modify
MetaBase
• In the "IIsComputer" node, change the value of enableeditwhilerunning from 0 (FALSE) to 1 (TRUE). The changes should look like the following:
<iiscomputer Location = "/LM"
enableeditwhilerunning= "1"
enablehistory= "1"
Maxbandwidth= "4294967295"
Maxhistoryfiles= "Ten" >
• Save the changes to the MetaBase.xml file.
Before you can modify the Mbschema file ...
-------------------------------a different view
A few days ago, I found my website inaccessible, ask the computer room this side, said the machine recently often crashed, I will move the site to a friend of the host, the result was not a few days after the machine hung, ask a friend of the room that is the hardware firewall was attacked and died, details do not know. It does not seem to be a hardware problem, mostly by SYN flood or cc attacks. Exactly the original room said recently purchased a new firewall, I put back.
Since it's not a hardware problem and it could be an attack, I started checking IIS log and found many timer_connectionidle and Timer_minbytespersecond errors in IIS, and Google it on the web, The common saying is that the error is due to improper setup of IIS because the connection timeout setting is too small, the workaround is to set the connection timeout to 600 seconds and modify the MinFileBytesPerSec setting from 240 to 0 (equivalent to turning off the setting). Think these solutions are problematic, if the vehicle alarm often ring, the correct solution is to see who often come to the idea of your car, or put the car in a more secure place, but definitely not turn off the alarm.
Because the HTTP service needs to occupy a TCP connection, and TCP connections require system resources, and IIS needs to allocate the appropriate resources for each connection. The current host is able to handle tens of thousands of connections can be said that the hardware and software design is very good (see C10K). If a malicious person initiates a large number of connections through one or more machines without requesting content (which does not consume much of the bandwidth of the attacking machine), it can consume server resources and achieve the purpose of denial of service.
So IIS needs to turn off a long, inactive connection, which is the origin of the Timer_connectionidle error.
Since the shield improved, of course, the spear to develop, the attacker can give the server deliberately slow to send and receive content and consumption of server resources, so as to avoid the server for Timer_connectionidle protection, the corresponding IIS prevention is MinFileBytesPerSec settings, the MinFileBytesPerSec property prevents malicious or software-working clients from consuming resources by maintaining a connection with the smallest amount of data. If the throughput is lower than the value set by MinFileBytesPerSec, the connection is terminated. Log inside will show Timer_minbytespersecond error (some Timer_minbytespersecond error is caused by Windows 2003 HTTP.sys error, the solution is to play the latest servicepack:http://support.microsoft.com/kb/919797 http://support.microsoft.com/kb/919797/en-us)
So these settings are used to protect the IIS server, to some extent, some malicious behavior consumes the resources of the server, so I instead of the IIS connection timeout from the original 600 seconds changed to 30 seconds
But after we solve the problem discovery because the site is in the application pool of the request queue limit, limited to 1000, according to their own site traffic, determined to 5000-10000 on the resolution, the default of 1000 indeed a little less
