In onze vorige berichten in deze serie hebben we uitgebreid gesproken over het gebruik van PgBouncer en Pgpool-II, de architectuur van de verbindingspool en de voor- en nadelen van het gebruik ervan voor uw PostgreSQL-implementatie. In ons laatste bericht zullen we ze het tegen elkaar opnemen in een gedetailleerde functievergelijking en de resultaten vergelijken van PgBouncer vs. Pgpool-II-prestaties voor uw PostgreSQL-hosting!
Hoe verhouden de functies zich tot elkaar?
Laten we beginnen met het vergelijken van de functies van PgBouncer en Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Bronverbruik | Het gebruikt slechts één proces, waardoor het erg licht is. PgBouncer garandeert een kleine geheugenvoetafdruk, zelfs als het om grote datasets gaat. Winnaar! | Als we N parallelle verbindingen nodig hebben, leidt dit tot N onderliggende processen. Standaard zijn er 32 onderliggende processen die gevorkt zijn. |
| Wanneer worden verbindingen hergebruikt? | PgBouncer definieert één pool per gebruiker+database combinatie. Dit wordt gedeeld tussen alle clients, dus een gepoolde verbinding is beschikbaar voor alle clients. Winnaar! | Pgpool-II definieert één proces per onderliggende proces. We hebben geen controle over het onderliggende proces waarmee een client verbinding maakt. Een client profiteert alleen van een gepoolde verbinding als deze verbinding maakt met een kind dat eerder een verbinding heeft gediend voor deze combinatie van database en gebruiker. |
| Poolingmodi | PgBouncer ondersteunt drie verschillende modi:sessie (verbinding keert terug naar pool wanneer client de verbinding verbreekt), transactie (terug naar pool wanneer client commit of terugdraait) of statement ( verbinding die wordt geretourneerd naar de pool na de uitvoering van elke instructie). Winnaar! | Pgpool-II ondersteunt alleen de modus voor sessiepooling – de effectiviteit van pooling is afhankelijk van goed gedrag van klanten. |
| Hoge beschikbaarheid | Niet ondersteund. | PostgreSQL hoge beschikbaarheid wordt ondersteund via Pgpool-II ingebouwde watcher-processen. Winnaar! |
| Load balancing | Niet ondersteund – PgBouncer raadt het gebruik van HAProxy aan voor hoge beschikbaarheid en taakverdeling. | Ondersteunt automatische taakverdeling – is zelfs intelligent genoeg om leesverzoeken om te leiden naar standbys en schrijven naar masters. Winnaar! |
| Ondersteuning voor meerdere clusters | Eén PgBouncer-instantie kan meerdere PostgreSQL-clusters bevatten (one-node of replica-sets). Dit kan de kosten voor middleware verlagen bij gebruik van meerdere PostgreSQL-clusters. Winnaar! (Opmerking:dit voordeel geldt alleen voor specifieke scenario's) | Pgpool-II heeft geen ondersteuning voor meerdere clusters. |
| Verbindingsbeheer | PgBouncer staat het beperken van verbindingen per pool, per database, per gebruiker of per client toe. Winnaar! | Pgpool-II staat alleen het beperken van het totale aantal verbindingen toe. |
| Verbindingswachtrij | PgBouncer ondersteunt wachtrijen op applicatieniveau (d.w.z. PgBouncer onderhoudt de wachtrij). Winnaar! | Pgpool-II ondersteunt wachtrijen op kernelniveau - hierdoor kan pg_bench op CentOS 6 vastlopen. |
| Verificatie | Pass-through authenticatie wordt ondersteund via PgBouncer. Winnaar! | Pgpool-II ondersteunt geen pass-through-authenticatie - gebruikers en hun met md5 versleutelde wachtwoorden moeten in een bestand worden vermeld en handmatig worden bijgewerkt telkens wanneer een gebruiker een update uitvoert hun wachtwoord. Pgpool-II ondersteunt wachtwoordloze authenticatie via PAM of SSL-certificaten. Deze moeten echter buiten het PostgreSQL-systeem worden ingesteld, terwijl PgBouncer dit kan offloaden naar de PostgreSQL-server. |
| Beheer | PgBouncer biedt een virtuele database die verschillende nuttige statistieken rapporteert. | Pgpool-II biedt een gedetailleerde beheerinterface, inclusief een GUI. Winnaar! |
| Hostgebaseerde authenticatie | Ondersteund. Gebonden! | Ondersteund. Gebonden! |
| SSL-ondersteuning | Volledige ondersteuning. Gebonden! | Volledige ondersteuning. Gebonden! |
| Logische replicatie | Niet ondersteund via PgBouncer. Gebonden! | Ondersteund via Pgpool-II, maar dit wordt gedaan door de schrijfquery's naar alle nodes te sturen en wordt over het algemeen niet aanbevolen. Gebonden! |
| Licentie | ISC – zeer tolerant, staat in principe alle gebruik toe. Gebonden! | Aangepaste licentie – even tolerant. Gebonden! |
Waar het op neerkomt:Pgpool-II is een geweldige tool als je load-balancing en hoge beschikbaarheid nodig hebt. Verbindingspooling is bijna een bonus die u erbij krijgt. PgBouncer doet maar één ding, maar doet het echt goed. Als het doel is om het aantal verbindingen te beperken en het verbruik van bronnen te verminderen, wint PgBouncer zonder twijfel.
Het is ook prima om zowel PgBouncer als Pgpool-II in een keten te gebruiken - je kunt een PgBouncer hebben om verbinding te poolen, die praat met een Pgpool-II-instantie die hoge beschikbaarheid en taakverdeling biedt. Dit geeft je het beste van twee werelden!
Prestatietesten
Hoewel PgBouncer in theorie misschien de betere optie lijkt, kan theorie vaak misleidend zijn. Dus hebben we de twee verbindingspoolers tegen elkaar uitgezet, met behulp van de standaard pgbench-tool, om te zien welke betere transacties per seconde doorvoer biedt via een benchmarktest. Voor de goede orde hebben we dezelfde tests ook zonder verbindingspooler uitgevoerd.
Testvoorwaarden
Alle PostgreSQL-benchmarktests zijn uitgevoerd onder de volgende voorwaarden:
- Pgbench geïnitialiseerd met een schaalfactor van 100.
- Auto-vacuüm uitgeschakeld op de PostgreSQL-instantie om interferentie te voorkomen.
- Er was op dat moment geen andere werklast.
- Het standaard pgbench-script gebruikt om de tests uit te voeren.
- Standaardinstellingen gebruikt voor zowel PgBouncer als Pgpool-II, behalve max_children *. Alle PostgreSQL-limieten waren ook ingesteld op hun standaardwaarden.
- Alle tests werden uitgevoerd als een enkele thread, op een computer met één CPU en twee kernen, gedurende 5 minuten.
- Gedwongen pgbench om een nieuwe verbinding te maken voor elke transactie met behulp van de -C optie. Dit emuleert moderne webapplicatie-workloads en is de hele reden om een pooler te gebruiken!
We hebben elke iteratie 5 minuten uitgevoerd om ervoor te zorgen dat alle ruis gemiddeld werd. Hier is hoe de middleware is geïnstalleerd:
- Voor PgBouncer hebben we het op dezelfde box geïnstalleerd als de PostgreSQL-server(s). Dit is de configuratie die we gebruiken in onze beheerde PostgreSQL-clusters. Omdat PgBouncer een zeer lichtgewicht proces is, heeft het installeren op de box geen invloed op de algehele prestaties.
- Voor Pgpool-II hebben we zowel getest wanneer de Pgpool-II-instantie op dezelfde machine was geïnstalleerd als PostgreSQL (in vakkolom), als wanneer deze op een andere computer was geïnstalleerd (uit vak kolom). Zoals verwacht zijn de prestaties veel beter wanneer Pgpool-II standaard is, omdat het niet hoeft te concurreren met de PostgreSQL-server voor bronnen.
Doorvoerbenchmark
Dit zijn de transacties per seconde (TPS)-resultaten voor elk scenario voor een bereik van het aantal klanten:
| Aantal klanten | Zonder pooling | PgBouncer | Pgpool-II (op doos) | Pgpool-II (uit vak) |
|---|---|---|---|---|
| 10 | 16.96 | 26.86 | 15.52 | 18.22 |
| 20 | 16.97 | 27.19 | 15,67 | 18.28 |
| 40 | 16.73 | 26.77 | 15.33 | 18.3 |
| 80 | 16.75 | 26.64 | 15.53 | 18.13 |
| 100 | 16.51 | 26.73 | 15.66 | 18.45 |
| 200 | Verbindingen afgebroken. | 26.93 | Verbindingen afgebroken wanneer max-children> 200, pgbench blijft hangen bij max-children waarde als <=100. | Verbindingen afgebroken wanneer max-children> 200, pgbench blijft hangen bij max-children waarde als <=100. |
Pgpool-II loopt vast wanneer pg_bench wordt uitgevoerd met meer clients dan max_children. Daarom hebben we de max_children verhoogd om overeen te komen met het aantal clients voor elke testrun.
Als we de procentuele toename in TPS berekenen bij gebruik van een pooler voor verbindingen, krijgen we het volgende:
| Aantal klanten | PgBouncer | Pgpool-II (op doos) | Pgpool-II (off box) |
|---|---|---|---|
| 10 | 58,37% | -8,49% | 7.43% |
| 20 | 60,22% | -7,66% | 7,72% |
| 40 | 60,01% | -8,37% | 9.38% |
| 80 | 59,04% | -7,28% | 8.24% |
| 100 | 61,90% | -5,15% | 11,75% |
* Verbeteringsalgoritme =(met pooler – zonder)/zonder
Laatste woorden
Zoals je kunt zien aan de hand van de prestatietestresultaten, kan een goed geconfigureerde verbinding en een goed geschikte pooler voor verbindingen de transactiedoorvoer drastisch verhogen, zelfs met een vrij klein aantal klanten. Verbindingspoolers zijn vooral handig voor hun wachtrijondersteuning - wanneer het aantal clients het maximale aantal clients overschrijdt dat door de PostgreSQL-server wordt ondersteund, kan PgBouncer nog steeds de transactiesnelheid handhaven, terwijl directe verbindingen met PostgreSQL worden afgebroken.
Een slecht geconfigureerde pooler voor verbindingen kan echter verminderen de prestaties zoals we zagen met de Pgpool-II-opstelling hier. Een deel van het probleem is het gebruik van Pgpool-II doubles het aantal processen dat op dezelfde server draait - we moeten draai Pgpool-II op een aparte server om goede prestaties te krijgen. Maar zelfs dan slaagt PgBouncer erin om betere prestaties te leveren voor deze relatief kleine aantallen klanten.
De test hier was eigenlijk perfect gemaakt voor Pgpool-II - sinds toen N> 32, waren het aantal clients en het aantal onderliggende processen hetzelfde, en daarom, bij elke herverbinding werd gegarandeerd een proces in de cache gevonden. Zelfs toen was PgBouncer het snellere alternatief.
Onze tests geven dus aan dat PgBouncer de veel betere keuze is voor het poolen van verbindingen. Maar het is belangrijk om te onthouden dat hoewel een pooler voor verbindingen absoluut verplicht is voor de meeste realistische workloads, of u meer krijgt door een client-side pool of middleware zoals PgBouncer te gebruiken, afhangt van uw toepassing. Patronen van gegevenstoegang zouden een rol spelen, evenals de latenties op basis van uw architectuur. We raden u aan uw werklast aan beide te toetsen en vervolgens te beslissen wat u het beste kunt doen - er is geen beter alternatief voor experimenteren!
