A melhor maneira de implementar a otimização de solicitações no ASP.NET MVC?

Estamos experimentando várias maneiras de controlar as ações do usuário em um determinado período :

• Limitar postagens de perguntas / respostas
• Limitar edições
• Limitar recuperações de feed

Por enquanto, estamos usando o cache para simplesmente inserir um registro de atividade do usuário - se esse registro existir se / quando o usuário fizer a mesma atividade, aceleramos.

Usar o cache automaticamente nos fornece janelas obsoletas de limpeza e deslizamento de dados dos usuários, mas como será dimensionado pode ser um problema.

Quais são algumas outras maneiras de garantir que solicitações / ações do usuário possam ser efetivamente controladas (ênfase na estabilidade)?

Aqui está uma versão genérica do que usamos no Stack Overflow no ano passado:

/// <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;
        }
    }
}

Uso da amostra:

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

O ASP.NET Cache funciona como um campeão aqui - ao usá-lo, você obtém a limpeza automática das entradas do acelerador. E com o nosso tráfego crescente, não estamos vendo que isso seja um problema no servidor.

Sinta-se livre para dar feedback sobre esse método; quando aprimoramos o Stack Overflow, você obtém o reparo do Ewok ainda mais rápido :)

A Microsoft possui uma nova extensão para o IIS 7 chamada Dynamic IP Restrictions Extension para IIS 7.0 - Beta.

"As restrições de IP dinâmico para IIS 7.0 são um módulo que fornece proteção contra negação de serviço e ataques de força bruta em servidores e sites da Web. Essa proteção é fornecida bloqueando temporariamente os endereços IP dos clientes HTTP que fazem um número incomumente alto de solicitações simultâneas ou que fazem um grande número de solicitações em um pequeno período de tempo ". http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

Exemplo:

Se você definir os critérios para bloquear depois X requests in Y millisecondsou X concurrent connections in Y millisecondso endereço IP for bloqueado Y milliseconds, as solicitações serão novamente permitidas.

Usamos a técnica emprestada deste URL http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx , não para otimização, mas para o Negial Of Service (DOS) de um homem pobre. Isso também é baseado em cache e pode ser semelhante ao que você está fazendo. Você está se esforçando para impedir ataques do DOS? Os roteadores certamente podem ser usados ​​para reduzir o DOS; você acha que um roteador pode lidar com a otimização necessária?