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á.
Gerencie pools de conexão e ciclo de vida em ambientes em contêineres
Gerenciar conexões com o Neptune de forma eficaz é essencial em ambientes em contêineres em que os contêineres (pods no Kubernetes) iniciam, param e escalam com frequência. O Neptune impõe vários limites de conexão: WebSocket
Cada tipo de instância tem um número máximo de conexões simultâneas WebSocket
As conexões inativas são fechadas após 20 a 25 minutos de inatividade
Alguns drivers suportam pulsações periódicas de manutenção de atividade para evitar desconexões inativas. Por exemplo, o driver Gremlin Java keepAliveInterval envia um ping periódico para o servidor. Consulte as opções específicas de configuração do driver para determinar quais configurações de keep-alive estão disponíveis e como elas interagem com o tempo limite de inatividade do Neptune.
Entender esses limites ajuda você a projetar um tratamento de conexão que funcione bem com padrões de orquestração de contêineres, como implantações contínuas, escalonamento automático e reciclagem de contêineres. Para obter orientações gerais sobre gerenciamento de conexões com o driver Java Gremlin, consulte e. Fechar o cliente para evitar o limite de conexões Criar uma conexão após o failover
Fechar conexões no desligamento do contêiner
Implemente um desligamento normal adicionando um SIGTERM manipulador que fecha seu cliente gráfico antes que o contêiner saia. Por exemplo, chame Gremlin Java'scluster.close(), Gremlin's em driverRemoteConnection.close() Go ou Python ou Bolt's para o driver Neo4j. driver.close() No Kubernetes, use um preStop gancho para drenar as conexões antes do SIGTERM envio, especialmente durante atualizações contínuas.
nota
O Docker e o Amazon ECS entregam somente SIGTERM para o PID 1 no contêiner. Use o formulário exec em seu Dockerfile (por exemplo, ENTRYPOINT ["java", "-jar", "app.jar"] nãoENTRYPOINT java -jar app.jar) ou um processo de inicialização, como tini para garantir que seu aplicativo receba o sinal.
Use uma única instância de cliente por contêiner
Criar várias neo4j.Driver instâncias do Gremlin DriverRemoteConnection ou do Bolt no mesmo contêiner multiplica o uso da conexão. Compartilhe uma única instância de cliente em todos os segmentos no contêiner. Os objetos do cliente são thread-safe.
Tamanho dos pools de conexão em relação à sua frota
Defina maxConnectionPoolSize para que o total de conexões em todos os contêineres não exceda o limite de conexão da instância Neptune. Por exemplo, se você executar 20 contêineres com 8 threads cada, calcule o tamanho do pool por contêiner para que 20 × o tamanho do pool permaneça dentro do limite de instância do seu tipo de instância. Para obter mais informações sobre como configurar os tamanhos do pool de conexões, consulteDefinir maxInProcessPerConnection e maxSimultaneousUsagePerConnection como o mesmo valor.
Definir um tempo limite de espera da conexão
No driver Java Gremlin, configure maxWaitForConnection com um valor razoável, como 5 a 10 segundos. O padrão geralmente é infinito ou muito longo, o que faz com que os encadeamentos travem quando o pool está esgotado, em vez de falharem rapidamente com um erro claro. Nem todos os drivers de idioma oferecem suporte a essa configuração. Consulte a documentação do driver para obter a opção de configuração equivalente.
