Connection pool

Wat is een connection pool?

Een connection pool is een voorraad open connecties naar een database of ander systeem. Een applicatie leent een connectie uit de pool, voert een query uit en geeft de connectie terug.

Dat is sneller dan telkens opnieuw verbinden. Een databaseconnectie opzetten vraagt authenticatie, netwerkhandshake en geheugen aan beide kanten. Bij een drukke webapplicatie zou dat veel onnodig werk zijn.

Bij een database die je via SQL bevraagt, merk je dit vooral wanneer veel requests tegelijk korte queries uitvoeren. De pool voorkomt dan dat elke request een nieuwe databaseverbinding moet opbouwen.

De pool is dus een wachtrij en voorraadkast tegelijk: hij houdt connecties klaar, maar begrenst ook hoeveel gelijktijdige connecties de applicatie mag gebruiken.

Hoe werkt een connection pool?

Bij de start of op het eerste gebruik opent de applicatie een aantal connecties. Elke request die databasewerk doet, vraagt een connectie aan. Is er eentje vrij, dan gebruikt de request die meteen. Is de pool leeg, dan wacht de request of krijgt hij een timeout.

Na de query sluit de applicatie de connectie niet echt. Ze geeft hem terug aan de pool, waar hij opnieuw gebruikt kan worden door de volgende request.

In code zie je vaak niet veel meer dan een connection string met instellingen zoals maximum pool size, idle timeout en connect timeout. De driver doet het beheer.

Waarom pool sizing moeilijk is

Een te kleine pool veroorzaakt wachttijd in de applicatie. Requests staan dan te wachten op een vrije connectie, ook al kan de database op zich nog werk aan.

Een te grote pool duwt het probleem naar de database. Honderden gelijktijdige connecties vragen geheugen, CPU en locks. De database kan dan net trager worden doordat iedereen tegelijk wil binnenkomen.

De juiste grootte hangt af van queryduur, piekverkeer, databasecapaciteit en hoeveel applicaties dezelfde database delen.

Connection pool versus cache

Een cache bewaart resultaten of data. Een connection pool bewaart verbindingen. De pool maakt queries niet inhoudelijk sneller, maar vermindert de kost om bij de database te geraken.

Als dezelfde query duizenden keren dezelfde data ophaalt, helpt caching. Als elke query andere data ophaalt maar de applicatie veel requests verwerkt, helpt pooling.

Wanneer krijg je problemen met een connection pool?

1. Connecties worden niet teruggegeven. Een bug houdt connecties open tot de pool leegloopt.

2. Queries duren te lang. Elke trage query houdt een connectie langer bezet.

3. Te veel applicaties delen dezelfde database. Elke pool lijkt redelijk, samen zijn ze te groot.

4. Serverless pieken. Veel korte instanties openen plots allemaal eigen pools.

Waar moet je op letten bij connection pools

• Meet wachttijd op de pool. Database-CPU vertelt niet of requests wachten op een vrije connectie.

• Gebruik timeouts. Eindeloos wachten maakt incidenten langer en moeilijker te vinden.

• Sluit logisch af. Gebruik de patronen van je framework zodat connecties terug naar de pool gaan.

• Stem pools op elkaar af. Kijk naar de totale som van alle applicaties, jobs en datapijplijnen.