Neste último mês fiquei investigando incidentes relacionados a alto consumo de memória por parte das nossas aplicações. Consegui encontrar alguns problemas e quero compartilhar com vocês, vamos começar com a utilização do HttpClient, esse cara pode ser um vilão se não for bem utilizado. As APIs da Wiz têm uma característica de chamar outras APIs e me atrevo a dizer que é mais consumo de API do que utilização de banco de dados. Nesse artigo quero explicar como você pode otimizar o desempenho do HttpClient ao lidar com dados como cargas úteis JSON no HttpResponseMessage.

Teoria

O que eu não sabia era que por padrão, na maioria dos casos, ao usar HttpClient e seus metodos (GetAsync, PostAsync e SendAsync), todo o corpo da resposta é lido em um buffer de memória antes que o método seja concluído. Nesse ponto, a conexão TCP, usada para a solicitação fica inativa e estará disponível para reutilização para outra solicitação, um ponto aqui é que estou falando do dotnet core 3.1, se for falar do dotnet 5, existem opções melhores como é o caso da utilização do protocolo http2, aí a história é outra.

Na maioria dos casos esse comportamento é aceitável, já que evita o uso da conexão tcp pelo período mínimo de tempo necessário. Mas... em casos que não temos memória sobressalente, aí entramos no caminho infeliz da história pois essa abordagem padrão introduz alguma sobrecarga de memória. Já que a resposta da API, vou generalizar aqui, o JSON é armazenado em buffer usando um MemoryStream, podemos acessar esse buffer pela classe HttpResponseMessage. Dependendo do tamanho da carga de resposta, isso pode significar que armazenamos em buffer uma grande quantidade de dados na memória.

Solução

O que eu não sabia era que existe uma sobrecarga desses métodos esperando um enum HttpCompletionOption, esse enum possui 2 valores o padrão é o ResponseContentRead, esse aí informa para o HttpClient que é para ler o corpo do JSON e colocar em memória mesmo que a nossa aplicação não vai usar esse objeto, sim isso é possível. O segundo valor é o que iremos começar a utilizar aqui na Wiz chamado ResponseHeadersRead, esse cara indica para o HttpClient quando os cabeçalhos de resposta forem totalmente lidos. O corpo da resposta pode não ser totalmente recebido neste momento.

O principal benefício é o desempenho. Ao usar esta opção, evitamos o buffer MemoryStream intermediário, em vez de obter o conteúdo diretamente do fluxo exposto no Socket. Isso evita alocações desnecessárias, o que é uma meta em situações altamente otimizadas.

Aqui vai um exemplo, quero serializar uma lista de livros apenas quando receber um status code 200. Se eu receber um 500 vou lançar uma exception e não preciso do conteúdo da API que estou consumindo.

A forma de utilizar esse enum é bem simples, olha como fica:

_httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

O normal é analisar o conteúdo de alguma forma. Vou mostrar um código de como podemos escrever nossa chamada para isso.

using var response = await _httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

response.EnsureSuccessStatusCode();

if (response.Content is object)
{
      var stream = await response.Content.ReadAsStreamAsync();

      var data = await JsonSerializer.DeserializeAsync<Search>(stream);

      // do something with the data or return it
}

Usamos o EnsureSuccessStatusCode para garantir que o status code recebido é um 2xx. Em caso afirmativo, verificamos se há conteúdo disponível na resposta. Agora podemos acessar o fluxo do conteúdo de resposta usando ReadAsStreamAsync.

O problema dessa abordagem é que assumimos mais responsabilidade em relação aos recursos do sistema, uma vez que a conexão com o servidor remoto fica presa até decidirmos que terminaremos com o conteúdo. A maneira como sinalizamos isso é descartando o HttpResponseMessage, que então libera a conexão para ser usada para outras solicitações. Por isso não esquecer do using.

using var response = await _httpClient.GetAsync

Outra forma de garantir isso é usar o try/finaly, veja um exemplo:

var response = await _httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

response.EnsureSuccessStatusCode();

Search data = null;

try
{

      if (response.Content is object)
      {
            var stream = await response.Content.ReadAsStreamAsync();
            data = await JsonSerializer.DeserializeAsync<Search>(stream);
      }
}
finally
{
      response.Dispose();
}

if (data is object)
{
      // intensive and slow processing of books list. We don't want this to delay releasing the connection.
}

Estudo de caso

Fiz um programa de teste para ter um benchmark da performance do que citei nesse artigo. Essa analise é feita tanto no Windows como no Linux, usando o dotnet core 3.1. Vocês podem acessar aqui.

Observe a coluna Allocated, usando um sistema Windows com o método WithHttpCompletionOption chegamos a uma performance de 26,87% em comparação com WithoutHttpCompletionOption que representa 73,13% do consumo de memória.

Agora usando um sistema Linux com o método WithHttpCompletionOption chegamos a uma performance de 28,62% em comparação com o método WithoutHttpCompletionOption que representa 71,38% do consumo de memória.

Windows

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=3.1.404
  [Host]           : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Server           : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  ServerForce      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Workstation      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  WorkstationForce : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10  

Linux

BenchmarkDotNet=v0.12.1, OS=ubuntu 20.04
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 2 logical cores and 1 physical core
.NET Core SDK=3.1.405
  [Host]           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Server           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  ServerForce      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Workstation      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  WorkstationForce : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10  

Pode me chamar de Juscélio ReisFollow

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #