Dicas para um serviço web de alto tráfego, c# asp.net sql2000
-
09-06-2019 - |
Pergunta
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
Solução
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.
Outras dicas
Acho que o cache é uma abordagem razoável e você pode dar um passo adiante e adicionar uma dependência SQL a ele.
Se você seguir o caminho do arquivo, tenha isso em mente.
http://petesbloggerama.blogspot.com/2008/02/aspnet-writing-files-vs-application.html
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.
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.
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.
É 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;
}
}