Jeg er forfatter til pg-promise .
Der er flere niveauer af optimering for databasekommunikation. Den vigtigste af dem er at minimere antallet af forespørgsler pr. HTTP-anmodning, fordi IO er dyrt, det samme er forbindelsespuljen.
- Hvis du skal udføre mere end én forespørgsel pr. HTTP-anmodning, skal du altid bruge opgaver via metoden opgave .
- Hvis din opgave kræver en transaktion, skal du udføre den som en transaktion via metoden tx .
- Hvis du har brug for at lave flere indsættelser eller opdateringer, skal du altid bruge flere rækker. Se Multi-row insert with pg-promise og PostgreSQL multi-row opdateringer i Node.js .
node-postgres begyndte at bruge pg-pool fra version 6.x, mens pg-promise forbliver på version 5.x, som bruger den interne forbindelsespoolimplementering. Her er grunden .
Min lange praksis på dette område tyder på:Hvis du ikke kan passe din tjeneste ind i en pulje på 20 forbindelser, bliver du ikke reddet ved at gå efter flere forbindelser, du bliver nødt til at rette din implementering i stedet. Ved at gå over 20 begynder du også at lægge yderligere pres på CPU'en, og det udmønter sig i yderligere langsommere.
Størrelsen af dataene havde intet at gøre med størrelsen af poolen. Du bruger typisk kun én forbindelse til en enkelt download eller upload, uanset hvor stor den er. Medmindre din implementering er forkert, og du ender med at bruge mere end én forbindelse, skal du rette det, hvis du ønsker, at din app skal være skalerbar.
Den vil vente på den næste tilgængelige forbindelse.
Se også: