This post has been republished via RSS; it originally appeared at: IIS Support Blog articles.
In order to troubleshoot slowness in web, system administrators should analyze IIS logs, Failed Request Tracing logs, dump files, and HTTP.SYS logs to narrow down the issue.
In a slowness issue I worked on, these records in HTTPERR file took my attention:
Apparently, requests take more than 35 seconds to response due to a Timer_MinBytesPerSecond related issue.
What is MinBytesPerSecond?
It’s a parameter HTTP.SYS uses to determine what speed is allowed for the response to the client.
From the official document:
Specifies the minimum throughput rate, in bytes, that HTTP.sys enforces when it sends a response to the client. The minBytesPerSecond attribute prevents malicious or malfunctioning software clients from using resources by holding a connection open with minimal data. If the throughput rate is lower than the minBytesPerSecond setting, the connection is terminated.
The current implementation only terminates the connection after the time it would have taken to stream the entire response back to the connecting client at the minimum bandwidth transfer rate has elapsed. If the transfer rate goes below the value specified by minBytesPerSecond only for a small period of time, but the overall transfer rate is higher, the connection will not be terminated.
The default value is 240.
HTTP.SYS logs above shows that the root cause of the issue is the slow response throughput. The client is not receiving IIS response at a reasonable speed.
For Windows Server 2012 R2 (it was the server I worked on), IIS wants to send response at minimum 240 bytes per second. If the client cannot receive it at this minimum speed, IIS terminates the connection. This logic prevents the server against denial-of-service (DoS) attacks.
- Find out which clients are causing this issue
- The client machines might be in a slow network. If the issue is caused by the same client(s), you may be able to improve their condition to solve the issue
- Find out client IP addresses in the HTTPERR file and investigate their network as well as their OS
- If the client IPs are legit (not malicious sources or possible attackers), set
- If the issue doesn’t happen again, play around the value (Try 500). It’s not recommended to set it 0 because it may make your application vulnerable to DoS attacks
- Steps for changing
- Go to IIS Manager
- Click on the server name
- Double click on Configuration Editor
- Go to “system.applicationHost/webLimits”
- Reset IIS