Sou o autor de pg-promise .
Existem vários níveis de otimização para comunicações de banco de dados. O mais importante deles é minimizar o número de consultas por solicitação HTTP, porque a E/S é cara, assim como o pool de conexões.
- Se você precisar executar mais de uma consulta por solicitação HTTP, sempre use tarefas, por meio do método tarefa .
- Se sua tarefa exigir uma transação, execute-a como uma transação, por meio do método tx .
- Se você precisar fazer várias inserções ou atualizações, sempre use operações de várias linhas. Consulte Inserção de várias linhas com pg-promise e atualizações de várias linhas do PostgreSQL no Node.js .
node-postgres começou a usar pg-pool a partir da versão 6.x, enquanto pg-promise permanece na versão 5.x que usa a implementação do pool de conexão interna. Aqui está o motivo .
Minha longa prática nesta área sugere:Se você não puder encaixar seu serviço em um conjunto de 20 conexões, você não será salvo por mais conexões, você precisará corrigir sua implementação. Além disso, ao passar de 20, você começa a sobrecarregar a CPU, e isso se traduz em mais lentidão.
O tamanho dos dados não tem nada a ver com o tamanho do pool. Você normalmente usa apenas uma conexão para um único download ou upload, não importa o tamanho. A menos que sua implementação esteja errada e você acabe usando mais de uma conexão, você precisa corrigi-la, se quiser que seu aplicativo seja escalável.
Ele aguardará a próxima conexão disponível.
Veja também:
