As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Gerenciando WebSocket conexões Gremlin em funções AWS Lambda
<a name="lambda-functions-websocket-connections"></a>

Se você usar uma variante da linguagem Gremlin para consultar Neptune, o driver se conectará ao banco de dados usando uma conexão. WebSocket WebSockets são projetados para suportar cenários de conexão cliente-servidor de longa duração. AWS Lambda, por outro lado, foi projetado para suportar execuções relativamente curtas e apátridas. Essa incompatibilidade na filosofia de design pode causar alguns problemas inesperados ao usar o Lambda para consultar o Neptune.

Uma AWS Lambda função é executada em um [contexto de execução](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-context.html) que isola a função de outras funções. O contexto de execução é criado na primeira vez que a função é invocada e pode ser reutilizado para invocações subsequentes da mesma função.

No entanto, qualquer contexto de execução nunca é usado para lidar com várias invocações simultâneas da função. Se a função for invocada simultaneamente por vários clientes, o Lambda [criará um contexto de execução adicional](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) para cada instância da função. Todos esses novos contextos de execução podem, por sua vez, ser reutilizados para invocações subsequentes da função.

Em algum momento, o Lambda recicla contextos de execução, especialmente se eles estiverem inativos por algum tempo. AWS Lambda [expõe o ciclo de vida do contexto de execução, incluindo as `Shutdown` fases `Invoke` e`Init`, por meio de extensões Lambda.](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html) Usando essas extensões, você pode escrever um código que limpe recursos externos, como conexões de banco de dados, quando o contexto de execução é reciclado.

Uma prática recomendada comum é [abrir a conexão do banco de dados fora da função de manipulador do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) para que ela possa ser reutilizada com cada chamada do manipulador. Se a conexão com o banco de dados cair em algum momento, você poderá se reconectar de dentro do manipulador. No entanto, com essa abordagem, existe o perigo de vazamentos de conexão. Se uma conexão ociosa permanecer aberta por muito tempo após a destruição de um contexto de execução, cenários de invocação do Lambda intermitentes poderão gradualmente vazar conexões e esgotar os recursos do banco de dados.

Os limites de conexão e os tempos limite de conexão do Neptune mudaram com as versões mais recentes do mecanismo. Anteriormente, cada instância suportava até 60.000 WebSocket conexões. Agora, o número máximo de WebSocket conexões simultâneas por instância do Neptune [varia de acordo com o tipo de instância](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html).

Além disso, a partir da versão 1.0.3.0 do mecanismo, o Neptune reduziu o tempo limite de inatividade das conexões de uma hora para cerca de vinte minutos. Se um cliente não fechar uma conexão, a conexão será fechada automaticamente após um tempo limite de inatividade de 20 a 25 minutos. AWS Lambda não documenta os tempos de vida do contexto de execução, mas experimentos mostram que o novo tempo limite de conexão do Neptune se alinha bem com os tempos limite do contexto de execução inativo do Lambda. No momento em que um contexto de execução inativo é reciclado, há uma boa chance de a conexão já ter sido fechada pelo Neptune ou ser fechada logo depois.