Dicas para um serviço web de alto tráfego, c# asp.net sql2000

Question

Estou desenvolvendo um web service cujos métodos serão chamados a partir de um "banner dinâmico" que mostrará uma espécie de fila de mensagens lidas de uma tabela do sql server.

O banner terá forte pressão nas home pages de sites de alto tráfego;toda vez que o banner for carregado, ele chamará meu web service, para obter a nova fila de mensagens.

Agora:Não quero que todo esse tráfego direcione consultas ao banco de dados toda vez que o banner for carregado, então estou pensando em usar o cache do asp.net (ou seja,HttpRuntime.Cache[cacheKey]) para limitar acessos ao banco de dados;Tentarei atualizar o cache a cada minuto ou mais.

Obviamente tentarei receber o mínimo de mensagens possível, para limitar o tráfego.

Mas talvez existam outras maneiras de lidar com tal cenário;por exemplo, eu poderia escrever a última versão da fila no sistema de arquivos e fazer com que o serviço da Web acessasse esse arquivo;ou algo misturando as duas abordagens ...

A solução é serviço web c#, asp.net 3.5, sql server 2000.

Alguma dica?Outras abordagens?

Obrigado

Andreia

Answer 1

Isso depende de muitas coisas:

• Se houver pouca alteração nos dados (pense no backend com o botão "publicar" ou em lotes diários), então eu definitivamente usaria arquivos estáticos (atualizados via push do backend).Usamos essa solução em alguns sites grandes e funcionou muito bem.
• Se os dados forem pequenos o suficiente, o cache de memória (ou seja,Http Cache) é viável, mas cuidado com problemas de bloqueio e também cuidado com o Http Cache não vou funcionam muito bem sob carga pesada de memória, porque os itens podem expirar antecipadamente se a estrutura precisar de memória.Já fui mordido por isso antes!Com as advertências acima, o Http Cache funciona muito bem.

Answer 2

Acho que o cache é uma abordagem razoável e você pode dar um passo adiante e adicionar uma dependência SQL a ele.

Cache ASP.NET:Dependência de cache SQL com SQL Server 2000

Answer 3

Se você seguir o caminho do arquivo, tenha isso em mente.

http://petesbloggerama.blogspot.com/2008/02/aspnet-writing-files-vs-application.html

Answer 4

Escrever um arquivo é uma solução melhor IMHO - é servido pelo código do kernel do IIS, sem a enorme sobrecarga do asp.net e você pode copiar o arquivo para CDNs posteriormente.

O desconto de dependência AFAIK não é muito eficiente com o SQL Server 2000.

Answer 5

Além disso, uma maneira de contornar a limitação de memória mencionada por Skliwz é que, se você estiver usando este serviço fora do aplicativo normal, poderá isolá-lo em seu próprio pool de aplicativos.Já vi isso ser feito antes, o que também ajuda.

Answer 6

Obrigado a todos, como os dados são pequenos, mas as tabelas subjacentes vão mudar, acho que seguirei o caminho do HttpCache:Na verdade, preciso de uma maneira de reduzir o acesso ao banco de dados, mesmo que os dados estejam mudando (essa é a razão para não usar uma dependência direta do SQL, conforme sugerido por @Bloodhound).

Vou fazer alguns testes de resistência antes de ir a público, eu acho.

Obrigado novamente a todos.

Answer 7

É claro que você também poderia (deveria) usar os recursos de cache no Biblioteca SixPack .

• Cache direto (normal), baseado em HttpCache, que funciona colocando atributos em sua classe.Mais simples de usar, mas em alguns casos é necessário esperar que o conteúdo seja realmente buscado no banco de dados.
• Cache de pré-busca, do zero, que, após a primeira chamada, começará a atualizar o cache nos bastidores, e você terá a garantia de ter conteúdo sem espera em alguns casos.

Mais informações sobre Página inicial da biblioteca SixPack.Observe que o código (especialmente o cache de encaminhamento) é testado em carga.

Aqui está um exemplo de cache simples:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }