Timer_MinBytesPerSecond in HTTP.SYS logs

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:

 

 

2020-07-26 14:09:01 10.123.12.12 35316 10.12.123.123 80 - - - - - Timer_MinBytesPerSecond 2020-07-26 14:09:01 10.123.12.12 48012 10.12.123.123 80 - - - - - Timer_MinBytesPerSecond

 

 

 

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.

 

Solution

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.

 

  1. 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
  2. Remove or alter the threshold for minimum response rate
    • If the client IPs are legit (not malicious sources or possible attackers), set minBytesPerSecond to 0 
    • 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 minBytesPerSecond:
      1. Go to IIS Manager
      2. Click on the server name
      3. Double click on Configuration Editor
      4. Go to “system.applicationHost/webLimits”
      5. Configure minBytesPerSecond
      6. Reset IIS

Nedim_0-1596842456880.png

 

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.