HTTP Request Throttling in SharePoint 2010 (Part 1)
SharePoint Web servers can generate a pretty heavy resource load, consuming processor time, memory, and disk I/O. Usually, a farm will continue to process requests even while under heavy strain, only the performance and response time for end users will gradually degrade, as Web pages take longer to return and AJAX and service requests take a long time to complete. This general slowness reflects poorly on both an organization's IT department and the SharePoint platform itself, and with SharePoint 2010 several measures have been implemented to better alert admins and users of potential issues.
One of these measures is HTTP Request Throttling, wherein for each request to a SharePoint front-end server, an evaluation of the current state of the server is carried out. A number of metrics are sampled and evaluated and a final score of 0 to 10 is assigned to the request based on the worst (highest) individual score. The server implements throttling when the score is 10, and the score is also added to the HTTP response as a header named "X-SharePointHealthScore" for client applications to react to. (For a quick way to see the HTTP headers on a request, use the Get-HTTPHeaders.ps1 script attached to this article.)
Request throttling is set at the Web Application level and is enabled by default for new Web Applications. It can be turned on and off through the Central Administration Web Site by selecting a Web Application from the Web Application management page, clicking the drop-down menu under General Settings on the ribbon, and selecting Resource Throttling. At the bottom of the popup dialog box is a setting HTTP Request Monitoring and Throttling for managing Request Throttling. While this can disable request throttling, a health score is still calculated and added to the page's HTTP headers. For more specific management of configuration settings, you'll need to turn to the object model via PowerShell (or other managed languages).
Request Throttle Configuration (SPHttpThrottleSettings)
Settings are all set via the SPHttpThrottleSettings object, available via the SPWebApplication.HttpThrottleSettings property. To access this object in PowerShell, use:
$throttleSettings = (Get-SPWebApplication "https://server:port").HttpThrottleSettings
$throttleSettings
Here we have assigned the object to a variable to improve efficiency for further manipulation.
The PerformThrottle property of this class corresponds to the on/off setting in the GUI for turning on or off Request Throttling for a given Web Application. Again, a score is still calculated and added to the HTTP headers collection. RefreshInterval governs how frequently (in milliseconds) new values from selected counters are retrieved, and NumberOfSamples determines how many past samples are considered when determining a final score - a value of 1, for example, evaluates only the most recent number. By default, the past 12 samples, gathered every 5 seconds, are considered, which reduces the chance a random spike could lead to inappropriately high scores.
With these configuration details out of the way, we turn our attention to the Performance Monitors and Throttle Classifiers which govern the inner workings of the Requst Throttling system.
Performance Monitors
The PerformanceMonitors property contains a collection of SPPerformanceMonitorCreationData objects which are to be monitored by the Request Throttling system. Each object has properties which define the category, counter, and instance of the PerfMon counter to be monitored, and an AssociatedHealthScoreCalculator property which points to a SPHealthScoreCalculator object in charge of actually computing a final health score. The CalculateScore method on this object is called by the Request Throttling system to return the Health Score for the given performance monitor. Out of the box, the only implementation of SPHealthScoreCalculator available is the SPBucketHealthScoreCalculator, which performs its CalculateScore method by determining into which of several ranges of values the current counter value falls.
Out of the box, two monitors are sampled and measured - Available MBs of RAM, and current ASP.NET requests. The Health Score for each of these monitors is calculated via the SPBucketHealthScoreCalculator. Let's take a little deeper look into how the Available MBs score is returned.
Two ways of retrieving the list of score buckets for a given monitor follow. Note that we're assuming that only a single monitor from the Memory category is configured (which is the configuration on installation).
$throttleSettings.PerformanceMonitors | ? { $_.Category -match "Memory" }
$monitor = $throttleSettings.PerformanceMonitors | ? { $_.Category -match "Memory" }
$monitor.AssociatedHealthScoreCalculator.GetScoreBuckets()
There are 10 buckets for this calculator, which creates 11 ranges (below the first bucket, between each of the 10 buckets, and above the last bucket) for classification. These 11 ranges correspond to the health scores of 0 through 10 (yes there are 11 numbers there), with 0 being most healthy and 10 being least. The default list is [1000.0,500.0,400.0,300.0,200.0,100.0,80.0,60.0,40.0,20.0], meaning when less than 20MB of RAM is free on a server, the health score returned by this calculator will be 10, when between 400 and 500 MBs of RAM is free, the health score will be 2, etc. To change these numbers, use the SetScoreBuckets( Double[] ) method on the SPHealthScoreCalculator object (this is just an example - you would choose a set of numbers based on your environment):
$monitor.AssociatedHealthScoreCalculator.SetScoreBuckets( @( 2000.0, 1500.0, 1000.0, 500.0, 400.0, 300.0, 200.0, 100.0, 75.0, 50.0) )
$throttleSettings.Update()
Note that in C# and VB you will need to cast the SPHealthScoreCalculator object to a SPBucketHealthScoreCalculator object first to expose these methods.
To clarify again, the bucket health score calculator is just one way a health score could be calculated. Although out of the box it is the only available calculator, you or a third party could easily roll another health score calculator which uses a different algorithm to return a value between 0 and 10.
Once the Request Throttling system has calculated the health score for each of the Performance Monitors being monitored, it takes the highest score as the overall health score and sets the X-SharePointHealthScore header. If this score is 10, HTTP Request throttling will be applied (if it's enabled).
This should get you started on understanding how HTTP Request Throttling works in SharePoint 2010. In future posts, we'll discuss how to add additional Performance Monitors to be monitored and how the Throttle Classifiers system works.