Uma estratégia de Web API Cache simples pode diminuir tanto a carga quanto o custo de infraestrutura nos servidores da aplicação.
Em uma análise utilizando o Stackify Retrace, verifiquei uma grande quantidade de requisições para endpoints específicos de nossa Web API. E, buscando otimizar o consumo de recursos, implementei um pequeno cache.
Leia mais:
- Impulsione Seus Aplicativos .NET: A Importância do Lazy Loading e Como Implementá-lo
- Desbloqueando a Velocidade: Dicas e Truques para Melhorar a Performance de Aplicações .NET
Por que Web API Cache?
É bastante comum realizarmos o cache de recursos estáticos em servidores Web, tais como imagens, arquivos CSS e JS.
Entretanto, quando se trata de recursos dinâmicos como os dados consumidos via APIs REST, por exemplo, há uma certa negligência.
Ao realizarmos, a todo momento, consultas à base de dados para retornar os mesmos conjuntos de dados, estamos gerando uma sobrecarga desnecessária no SGBD.
Com isso, para mantermos uma taxa de transferência (throughput) e de resposta adequadas, acabamos por aumentar a memória e CPU do servidor (dinheiro pelo ralo).
É aí que entram as estratégias de cache. Onde uma implementação bem feita, não só aumenta o desempenho como reduz custos.
Como desenvolvedores, temos a obrigação de extrair o máximo dos recursos de hardware disponíveis.
Como estabelecer uma estratégia de cache?
Existem várias abordagens na estruturação de um cache. Aqui, irei mostrar uma bem simples, que tira proveito tanto do cache do lado do cliente quanto do lado do servidor.
Mas antes de qualquer implementação, precisamos saber quais aspectos analisar para escolhermos a estratégia mais adequada.
Sendo assim, farei uma breve passagem pelas quatro dimensões abordadas por Elton Stoneman, e que eu as achei bastante relevantes.
Custo do cache
Consultar dados no disco, em base de dados, em APIs externas ou qualquer outra fonte fora dos limites da aplicação tem um custo, seja ele financeiro e/ou de tempo.
Tamanho do cache
O resultado de uma consulta pode variar desde bytes até megabytes, ou até mesmo gigabytes.
Portanto, enormes volumes de dados devem ser avaliados com cuidado, pois podem ocasionar um impacto grande na infraestrutura.
Vale lembrar que o custo por megabyte da memória RAM é muito superior ao dos discos.
Longevidade do cache
Por quanto tempo os dados do cache podem ser considerados atualizados?
A invalidação do cache é um fator muito importante. Assim, sendo frequente demais estaremos perdendo os benefícios do cache, sendo pouco, poderemos entregar dados defasados.
Reutilização do cache
Quanto mais a informação cacheada for utilizada, maior será a recompensa pelo uso do cache.
Implementação da Web API Cache
Em minha implementação não fiz nenhuma configuração no IIS, apenas código C# nas rotas que identifiquei necessárias.
E mesmo assim, consegui resultados bem satisfatórios com uma redução de quase 36% no uso de rede, bem como na diminuição da latência.
Primeiramente é preciso instalar o seguinte pacote NuGet no projeto:
Install-Package Strathweb.CacheOutput.WebApi2 -Version 0.11.0
Após a instalação, é possível decorar seus métodos da Web API com diversos atributos que instruem como o cache deverá funcionar.
[CacheOutput(ClientTimeSpan = 60, ServerTimeSpan = 120)]
public IEnumerable<Conta> Get()
{
return _contaService.GetAll();
}
No exemplo acima, definimos que o cliente deve armazenar o retorno da API por 60 segundos, enquanto a aplicação manterá os mesmos dados por 120 segundos.
É importante perceber, que o cache do lado do cliente previne que ele faça novas consultas desnecessárias dentre o período estipulado. Da mesma forma, que o cache do lado do servidor ajuda a evitar consultas quando outros clientes buscam os mesmos dados.
Essa biblioteca possui diversas opções, caso queira conhecê-las, nesse repositório há a documentação completa.
Resultados da Web API Cache
A título de exemplo, separei alguns recortes demonstrando os ganhos que obtive.
Na imagem acima vemos um exemplo de uma sequência de requisições ao servidor, nenhuma delas sendo cacheadas do lado do cliente.
Como podemos ver, com a ativação do cache, o servidor informa na resposta da requisição que os dados tem validade de 60 segundos.
Ao atualizarmos a página, as três requisições foram retornadas do cache em disco do próprio navegador.
Não há bala de prata
Nem tudo são flores. Apesar do cache ser uma mão na roda, ele tem suas limitações e problemas. O mais conhecido, talvez, seja em relação a sua invalidação.
Entretanto, como apresentei, mesmo uma solução simples pode gerar bons frutos.
Espero que tenham gostado. Deixe suas dúvidas e comentários. Até a próxima!
Os comentários estão fechados, mas trackbacks E pingbacks estão abertos.