AWS Lambda: Otimização com HTTP keep-alive
Tags: ptbr, aws, serverless, webdev
Published: 2019-08-15 22:27:00

Recentemente assisti a uma [excelente palestra](https://vimeo.com/287511222?fbclid=IwAR31W61fC-MJcXiPdT4ywMKX-ccKiAzviQogcOaivyGpPzcj5vY16A6obCw) de Matt Lavin sobre dicas de otimização para AWS Lambda e vi um slide fazendo o DynamoDB usar o HTTP keep-alive. Isso me lembrou de uma conversa que tive com [Sebastian Cohnen](https://twitter.com/tisba), então comecei a testar o efeito dessa simples otimização.

![](https://miro.medium.com/max/700/0*bmImHeGBqn0JWrQz.png)

# Sobre o que é tudo isso?

O que acontece é, o agente HTTP padrão do Node.js não usa o **keep-alive** e, portanto, cada solicitação teria o custo de configurar uma nova conexão TCP. Isso é claramente ineficiente, já que você precisa realizar um [handshake de três vias](https://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml) para estabelecer uma conexão TCP. Para operações que são de curta duração (como operações do DynamoDB, que geralmente são concluídas em um único dígito ms), a sobrecarga de latência de estabelecer a conexão TCP pode ser maior que a operação em si.

Com o AWS SDK do Node.js, você pode [substituir o agente HTTP](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/node-configuring-maxsockets.html) que será usado em TODOS os clientes com apenas algumas linhas de código. Você também pode substituir as configurações dos clientes de modo individual.

![](https://miro.medium.com/max/700/0*8KWtgYTvHSConHj8.png)

# Os testes

Para testar o efeito de ativar o HTTP keep-alive, eu configurei uma função Lambda simples por trás do API Gateway. Essencialmente, essa função coloca um item em uma tabela do DynamoDB, e é isso!

![](https://miro.medium.com/max/700/0*tADPoWDv8mZpC6SJ.png)

Para esse experimento, eu queria ver como o HTTP keep-alive se saiu em várias invocações e qual a diferença que temos com essa simples mudança.

# Os resultados

Sem o HTTP keep-alive, a operação do DynamoDB era em **média de 33ms**.

![](https://miro.medium.com/max/700/0*Z7Z_VGlAPZCPRbO4.png)

Com o HTTP keep-alive, essa **média cai para cerca de 10ms**.

![](https://miro.medium.com/max/700/0*qI61ark1e9_VDMBo.png)

Como suspeitamos, a sobrecarga (33ms-10ms = 23ms) foi maior que o custo da operação em si. A experiência mostra que a conexão é reutilizada em várias invocações eficientemente. Com uma mudança muito simples, conseguimos melhorar o tempo de execução em ~20ms ou, para aumentar ainda mais, reduzir o tempo de resposta em 70%. Isso é bom retorno sobre o investimento no meu checklist de desenvolvimento, mas a diferença ainda não é perceptível ao olho humano.

Mas e se escalarmos isso para 10 operações seqüenciais do DynamoDB em uma única função?

Com o HTTP keep-alive, o tempo de execução da função é em **torno de 60ms**.

![](https://miro.medium.com/max/700/0*fBeR3WTV6smSBlpQ.png)

Sem o HTTP keep-alive, o **tempo médio de execução aumenta para 180 ms**.

![](https://miro.medium.com/max/700/0*ZmQBVoMUTSg0pDQe.png)

Para finalizar, a **diferença de 120ms** é definitivamente perceptível. Essa diferença pode começar a afetar a experiência do usuário e, como a Amazon descobriu há 10 anos, a [adição de 100ms de latência pode reduzir as vendas em até 1%](https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales).

# Créditos

- [Lambda optimization tip — enable HTTP keep-alive](https://medium.com/@theburningmonk), escrito originalmente por @theburningmonk