views:

2466

answers:

4

We're experimenting with various ways to throttle user actions in a given time period:

  • Limit question/answer posts
  • Limit edits
  • Limit feed retrievals

For the time being, we're using the Cache to simply insert a record of user activity - if that record exists if/when the user does the same activity, we throttle.

Using the Cache automatically gives us stale data cleaning and sliding activity windows of users, but how it will scale could be a problem.

What are some other ways of ensuring that requests/user actions can be effectively throttled (emphasis on stability)?

A: 

Have you tried the using Bit Rate Throttling Module for IIS7?

Links:

http://learn.iis.net/page.aspx/147/bit-rate-throttling-setup-walkthrough/

http://learn.iis.net/page.aspx/148/bit-rate-throttling-configuration-walkthrough/

Download x64: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1641

Download x86: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1640

MartinHN
I do not think this is what the question was asking -- bit rate is for bandwidth, this is for actions-per-unit-of-time.
Jeff Atwood
+6  A: 

We use the technique borrowed from this URL http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx, not for throttling, but for a poor man's Denial Of Service (D.O.S). This is also cache-based, and may be similar to what you are doing. Are you throttling to prevent D.O.S. attacks? Routers can certainly be used to reduce D.O.S; do you think a router could handle the throttling you need?

Rob Kraft
That's pretty much what we're already doing - but it's working great :)
Jarrod Dixon
+19  A: 

Microsoft has a new extension for IIS 7 called Dynamic IP Restrictions Extension for IIS 7.0 - Beta.

"The Dynamic IP Restrictions for IIS 7.0 is a module that provides protection against denial of service and brute force attacks on web server and web sites. Such protection is provided by temporarily blocking IP addresses of the HTTP clients who make unusually high number of concurrent requests or who make large number of requests over small period of time." http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

notandy
We actually installed this last night!
Jarrod Dixon
+22  A: 

Here's a generic version of what we've been using on Stack Overflow for the past year:

/// <summary>
/// Decorates any MVC route that needs to have client requests limited by time.
/// </summary>
/// <remarks>
/// Uses the current System.Web.Caching.Cache to store each client request to the decorated route.
/// </remarks>
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class ThrottleAttribute : ActionFilterAttribute
{
    /// <summary>
    /// A unique name for this Throttle.
    /// </summary>
    /// <remarks>
    /// We'll be inserting a Cache record based on this name and client IP, e.g. "Name-192.168.0.1"
    /// </remarks>
    public string Name { get; set; }

    /// <summary>
    /// The number of seconds clients must wait before executing this decorated route again.
    /// </summary>
    public int Seconds { get; set; }

    /// <summary>
    /// A text message that will be sent to the client upon throttling.  You can include the token {n} to
    /// show this.Seconds in the message, e.g. "Wait {n} seconds before trying again".
    /// </summary>
    public string Message { get; set; }

    public override void OnActionExecuting(ActionExecutingContext c)
    {
        var key = string.Concat(Name, "-", c.HttpContext.Request.UserHostAddress);
        var allowExecute = false;

        if (HttpRuntime.Cache[key] == null)
        {
            HttpRuntime.Cache.Add(key,
                true, // is this the smallest data we can have?
                null, // no dependencies
                DateTime.Now.AddSeconds(Seconds), // absolute expiration
                Cache.NoSlidingExpiration,
                CacheItemPriority.Low,
                null); // no callback

            allowExecute = true;
        }

        if (!allowExecute)
        {
            if (String.IsNullOrEmpty(Message))
                Message = "You may only perform this action every {n} seconds.";

            c.Result = new ContentResult { Content = Message.Replace("{n}", Seconds.ToString()) };
            // see 409 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
            c.HttpContext.Response.StatusCode = (int)HttpStatusCode.Conflict;
        }
    }
}

Sample usage:

[Throttle(Name="TestThrottle", Message = "You must wait {n} seconds before accessing this url again.", Seconds = 5)]
public ActionResult TestThrottle()
{
    return Content("TestThrottle executed");
}

The ASP.NET Cache works like a champ here - by using it, you get automatic clean-up of your throttle entries. And with our growing traffic, we're not seeing that this is an issue on the server.

Feel free to give feedback on this method; when we make Stack Overflow better, you get your Ewok fix even faster :)

Jarrod Dixon
@Jarrod Dixon: quick question - you're using the c.HttpContext.Request.UserHostAddress value as part of the key. Is that value possible empty or null or all the same value? (ie, if u're using a load balancer and it's the IP of that machine .. not the real clients) Like, do proxy's or load balancers (ie an BIG IP F5) put the same data in there and you need to check for X-Forwarded-For also or something?
Pure.Krome
@Pure.Krome - yes, it could be. When retrieving the client IP, we use a helper function that checks both the `REMOTE_ADDR` and `HTTP_X_FORWARDED_FOR` server variables and sanitizes appropriately.
Jarrod Dixon