Single Database Connection vs Multiple Database Connections?

[siDDis]

Eg lurer på ein ting angående dette, når lønner det seg å bruke fleire connections mot ein database? Når databaser har fleire tråder som kan kjøre samtidig? Når det er snakk om fleire brukere og låsing er involvert? Finner lite informasjon om dette på Google og lurer på om det er nokre kloke hovuder her som har betre svar

 

Tenker spessielt på webapplikasjoner!

Endret 20. februar 2008 av siDDIs

[j000rn]

.Net f.eks. har en intern connectionpool. Dermed bør du åpne connection så sent som mulig, og lukke den igjen så fort du er ferdig med den. Når den lukkes blir den lagt tilbake i pool'en slik at den kan bli brukt igjen av andre request'er. Dermed vil .Net som oftest ha mange åpne connections mot databasen som er inaktive og venter på å bli brukt. Connectionpooling virker kun dersom du har identisk connectionstring. Dessuten er det VELDIG viktig å huske å lukke connection'n slik at ikke pool'n blir oppbrukt.

 

Å åpne en connection (som ikke ligger i en pool) vil ta litt tid. På samme måte vil hver connection som er åpen bruke litt minne på databaseserveren.

[blackbrrd]

Siden jeg bruker Postgres til daglig så kan jeg ta den som eksempel.

 

Postgres kjører en prosess pr connection. Det tar litt tid å opprette en slik prosess. Derfor lønner det seg å bruke connection pooling av ett eller annet slag, enten i applikasjonen(e) (som gjør det på maskinen applikasjonen kjører på) eller via pgbouncer (som gjør det på databaseserveren) e.l.

 

Hvis du kjører postgres så lønner det seg å ha minst like mange connections som du har cpu-cores, ellers har du ikke mulighet til å bruke alle cpu-corene.

 

La oss si at du har to quad core cpu-er. Du bør da ha minst 8 connections til databasen, men det kan nok lønne seg å ha litt flere! F.eks er det rimelig dumt hvis du har 8 tunge spørringer som kjører som blokker alle andre (lette) spørringer. Hvor mange du trenger kommer an på applikasjonen. Hvis jeg skulle si ett tall hadde jeg sagt mellom 20 og 200.

 

Applikasjonene vi kjører mot databaseserveren vår har vanligvis rundt regnet 300 connections, uten at det strengt tatt er nødvendig. Tenker vi kunne klart oss med ca 100. Grunnen er at vi har flere applikasjoner som ikke deler samme connection pool. Som nevnt tidligere, noen idle connections er ikke noe problem.

 

Hver prosess bruker bittelitt minne når den ikke er i bruk (400 bytes eller deromkring), men de kan bruke vesentlig mer når de kjører, f.eks til sortering.

 

Å ha opprettet en connection er ikke nødvendigvis så farlig, evt transaksjon starter først når du kjører den første queryen til databasen. Å ha 10000 connections stå åpne er selvfølgelig ingen god ide... :o)

 

Webapplikasjonen vi bruker kjører apache som frontend og vi har da vanligvis max 40 connections gjennom den, noe som tilsier at databasen ikke trenger mer enn max 40 connections. (Grensene er satt vesentlig høyere)

 

Hadde en gang et buggy script som satte igang en svært tung spørring en gang i minuttet. Spørringen ble aldri ferdig. I det vi hadde 120 slike spørringer kjørende samtidig så var loaden på databaseserveren på 124 eller deromkring (load utfra hva top sier i linux). Ingenting hadde kræsjet enda, men det tok 5 min å logge inn på maskinen for å se hva som var feil. Kan kanskje nevne at spørringen trengte mer enn 10gb data som var mengden ram på serveren, så hele spørringen ble kjørt fra disk...

 

Angående spørsmål om låsing, så bruker postgres et system som kalles MVCC ( http://en.wikipedia.org/wiki/PostgreSQL#MVCC ) som gjør at lesing aldri blir blokkert av skriving, og skriving aldri blir blokkert av lesing. Det eneste blokkeringen du kan få er hvis to transaksjoner skriver til samme celler i samme rad i samme tabell samtidig. Da vil den transaksjonen som startet sist få en exception når den første transaksjonen commiter.

Endret 20. februar 2008 av blackbrrd