Jack Freelander's Blog

The recent release of the Bit Rate Throttling Module for IIS provides some useful and compelling features for managing response rates for data and media files.  One of the interesting features that is included is the notion of a connection limit group.  While IIS (via HTTP.SYS) provides a mechanism for limiting the concurrent connections for an entire site (see Advanced Settings in the UI), our Bit Rate Throttling module goes a step further, allowing admins to define and configure their own connection limits, grouped according to file type (based on file extension) or mime-type (based on the content-type response header).

Connection limit groups take some explaining, and are more of an advanced feature, and as such are not exposed via the UI (at least not yet!).  Taking a peek at applicationHost.config after installing BRT, you’ll see the following settings (note that I have pruned these to fit nicely in a painfully narrow blog window):

There is a deliberate separation / independence between a throttling rule and a connection limit group.  Both file extension rules and mime type rules (not seen in the above config) can specify this attribute.  In all likelihood you'd need only a few connection limit groups, but their number, naming and limits are completely configurable – in theory each throttling rule could have its own.  The example included with the default install illustrates a scenario where you wish to manage the # of connections based on whether a response originates from an audio or video file.  The concept applies equally well to data rules, where you might want to limit the # of simultaneous downloads of large files.  Presently there is no way to group and to limit responses which don't fall into one of the rules specified in the configuration (how would we know which connection limit group to add it to?).

The connectionLimitGroup attribute is optional, as is the connectionLimitGroups collection, so removing them from your config file won't cause an error.  However, the UI does not yet support creating or modifying these rules.  It may be handy to leave them in, so that should they become appealing in the future you won't have to dig through the schema to recall the exact syntax.

Also interesting is that a connection limit group may specify not only a "connectionLimit" but also a "targetThroughputRateKbps"!  This means that responses belonging to a certain connection limit group can be throttled dynamically to stay at a target transfer rate (cumulative value).  The idea here is to throttle only when necessary, and to maintain as best as possible a target throughput (hence the name ;).  Note that by using a targetThroughputRateKbps (also referred to as "dynamic throttling") the Bit Rate Throttling module will never reduce a response's throttle rate below the value determined by the configuration settings.  The targetThroughputRateKbps attribute is only ever used to *increase* throttle rates to take advantage of surplus bandwidth, to serve responses more quickly when conditions allow.  It is a best-effort on-the-fly calculation that can and will fluctuate with load (remember too that the inital burts [specified by initialBufferTimeSeconds for media rules or initialSendSizeKBytes for data rules] are sent unthrottled!).  It is not a hard-limit or maximum.

Happy Throttling!

/jack

For more information on this release of Bit Rate Throttling for IIS 7.0, see:

http://blogs.iis.net/vsood/archive/2008/03/15/bit-rate-throttling-is-now-released.aspx

http://weblogs.asp.net/scottgu/archive/2008/03/18/iis-7-0-bit-rate-throttling-module-released.aspx