I vores tidligere indlæg i denne serie talte vi længe om brugen af PgBouncer og Pgpool-II, forbindelsespoolarkitekturen og fordele og ulemper ved at udnytte en til din PostgreSQL-implementering. I vores sidste indlæg vil vi sætte dem head-to-head i en detaljeret funktionssammenligning og sammenligne resultaterne af PgBouncer vs. Pgpool-II ydeevne for din PostgreSQL-hosting!
Hvordan hænger funktionerne sammen?
Lad os starte med at sammenligne PgBouncer vs. Pgpool-II funktioner:
PgBouncer | Pgpool-II | |
|---|---|---|
| Ressourceforbrug | Den bruger kun én proces, hvilket gør den meget let. PgBouncer garanterer et lille hukommelsesfodaftryk, selv når der er tale om store datasæt. Vinder! | Hvis vi kræver N parallelle forbindelser, fordeler dette N underordnede processer. Som standard er der 32 underordnede processer, der er splittet. |
| Hvornår genbruges forbindelser? | PgBouncer definerer én pulje pr. bruger+databasekombination. Dette deles mellem alle klienter, så en samlet forbindelse er tilgængelig for alle klienter. Vinder! | Pgpool-II definerer én proces pr. underordnet proces. Vi kan ikke kontrollere, hvilken underordnet proces en klient forbinder til. En klient drager kun fordel af en samlet forbindelse, hvis den opretter forbindelse til et barn, som tidligere har tjent en forbindelse for denne database+brugerkombination. |
| Pool-tilstande | PgBouncer understøtter tre forskellige tilstande:session (forbindelse returneres til puljen, når klienten afbrydes), transaktion (returneres til puljen, når klienten forpligter sig eller ruller tilbage) eller erklæring ( forbindelse returneret til pool efter udførelse af hver sætning). Vinder! | Pgpool-II understøtter kun sessionspooling-tilstand – effektiviteten af pooling afhænger af god adfærd fra klienter. |
| Høj tilgængelighed | Ikke understøttet. | PostgreSQL høj tilgængelighed understøttes gennem Pgpool-II indbyggede overvågerprocesser. Vinder! |
| Belastningsbalancering | Ikke understøttet – PgBouncer anbefaler brug af HAProxy for høj tilgængelighed og belastningsbalancering. | Understøtter automatisk belastningsbalancering – er endda intelligent nok til at omdirigere læseanmodninger til standby og skriver til mastere. Vinder! |
| Multi-cluster support | Én PgBouncer-instans kan fronte flere PostgreSQL-klynger (én-node eller replika-sæt). Dette kan reducere omkostningerne til middleware, når du bruger flere PostgreSQL-klynger. Vinder! (Bemærk – denne fordel er kun for specifikke scenarier) | Pgpool-II har ikke multi-cluster-understøttelse. |
| Forbindelseskontrol | PgBouncer tillader begrænsning af forbindelser pr. pulje, pr. database, pr. bruger eller pr. klient. Vinder! | Pgpool-II tillader kun at begrænse det samlede antal forbindelser. |
| Forbindelseskø | PgBouncer understøtter kødannelse på applikationsniveau (dvs. PgBouncer vedligeholder køen). Vinder! | Pgpool-II understøtter kødannelse på kerneniveau – dette kan få pg_bench på CentOS 6 til at fryse. |
| Godkendelse | Pass-through-godkendelse understøttes gennem PgBouncer. Vinder! | Pgpool-II understøtter ikke pass-through-godkendelse – brugere og deres md5-krypterede adgangskoder skal angives i en fil og opdateres manuelt, hver gang en bruger opdaterer deres adgangskode. Pgpool-II understøtter adgangskodefri godkendelse gennem PAM eller SSL-certifikater. Disse skal dog sættes op uden for PostgreSQL-systemet, mens PgBouncer kan overføre dette til PostgreSQL-serveren. |
| Administration | PgBouncer leverer en virtuel database, der rapporterer forskellige nyttige statistikker. | Pgpool-II giver en detaljeret administrationsgrænseflade, inklusive en GUI. Vinder! |
| Værtsbaseret godkendelse | Understøttet. Uafgjort! | Understøttet. Uafgjort! |
| SSL-understøttelse | Fuld understøttelse. Uafgjort! | Fuld understøttelse. Uafgjort! |
| Logisk replikering | Ikke understøttet af PgBouncer. Uafgjort! | Understøttet gennem Pgpool-II, men dette gøres ved at sende skriveforespørgslerne til alle noder, og anbefales generelt ikke. Uafgjort! |
| Licens | ISC – meget eftergivende, tillader grundlæggende al brug. Uafgjort! | Tilpasset licens – lige så tilladende. Uafgjort! |
Bundlinjen – Pgpool-II er et fantastisk værktøj, hvis du har brug for belastningsbalancering og høj tilgængelighed. Connection pooling er næsten en bonus, du får ved siden af. PgBouncer gør kun én ting, men gør det rigtig godt. Hvis målet er at begrænse antallet af forbindelser og reducere ressourceforbruget, vinder PgBouncer hænderne ned.
Det er også helt fint at bruge både PgBouncer og Pgpool-II i en kæde – du kan have en PgBouncer til at give forbindelsespooling, som taler til en Pgpool-II instans, der giver høj tilgængelighed og belastningsbalancering. Dette giver dig det bedste fra begge verdener!
Ydeevnetest
Mens PgBouncer kan synes at være den bedre mulighed i teorien, kan teori ofte være vildledende. Så vi satte de to forbindelsespoolere ind mod hinanden ved at bruge standardpgbench-værktøjet for at se, hvilken der giver bedre transaktioner pr. sekund gennem en benchmark-test. For god ordens skyld kørte vi også de samme test uden en forbindelsespooler.
Testbetingelser
Alle PostgreSQL-benchmark-testene blev kørt under følgende betingelser:
- Initialiseret pgbench med en skalafaktor på 100.
- Deaktiveret automatisk støvsugning på PostgreSQL-instansen for at forhindre interferens.
- Ingen anden arbejdsbyrde virkede på det tidspunkt.
- Brugte standard pgbench-scriptet til at køre testene.
- Brugte standardindstillinger for både PgBouncer og Pgpool-II, undtagen max_children *. Alle PostgreSQL-grænser blev også sat til deres standardindstillinger.
- Alle test kørte som en enkelt tråd på en enkelt-CPU, 2-kernet maskine, i en varighed på 5 minutter.
- Tvang pgbench til at oprette en ny forbindelse for hver transaktion ved hjælp af -C-indstillingen. Dette emulerer moderne webapplikationsarbejdsbelastninger og er hele grunden til at bruge en pooler!
Vi kørte hver iteration i 5 minutter for at sikre, at al støj udlignes i gennemsnit. Sådan blev middlewaren installeret:
- For PgBouncer installerede vi det på samme boks som PostgreSQL-serveren(e). Dette er den konfiguration, vi bruger i vores administrerede PostgreSQL-klynger. Da PgBouncer er en meget let proces, har installationen på boksen ingen indflydelse på den samlede ydeevne.
- For Pgpool-II testede vi både når Pgpool-II-forekomsten blev installeret på den samme maskine som PostgreSQL (på bokskolonnen), og når den blev installeret på en anden maskine (off box kolonne). Som forventet er ydeevnen meget bedre, når Pgpool-II er ude af boksen, da den ikke behøver at konkurrere med PostgreSQL-serveren om ressourcer.
Throughput Benchmark
Her er resultaterne for transaktioner pr. sekund (TPS) for hvert scenarie på tværs af et interval af antal klienter:
| Antal klienter | Uden pooling | PgBouncer | Pgpool-II (på æsken) | Pgpool-II (off box) |
|---|---|---|---|---|
| 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 | Forbindelser afbrudt. | 26.93 | Forbindelser afbrudt, når max-children> 200, pgbench hænger ved max-children-værdien, hvis <=100. | Forbindelser afbrudt, når max-children> 200, pgbench hænger ved max-children-værdien, hvis <=100. |
Pgpool-II hænger, når pg_bench køres med flere klienter end max_children. Så vi øgede max_children for at matche antallet af klienter for hver testkørsel.
Hvis vi beregner den procentvise stigning i TPS ved brug af en forbindelsespooler, får vi her:
| Antal klienter | PgBouncer | Pgpool-II (på boks) | 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 % |
* Forbedringsalgoritme =(med pooler – uden)/uden
Sidste ord
Som du kan se fra resultaterne fra præstationstesten, kan en velkonfigureret forbindelse og velegnet forbindelsespooler øge transaktionsgennemstrømningen drastisk, selv med et ret lille antal klienter. Forbindelsespoolere er især nyttige til deres kø-understøttelse – når antallet af klienter overstiger max-klienter understøttet af PostgreSQL-serveren, er PgBouncer stadig i stand til at opretholde transaktionshastigheden, hvorimod direkte forbindelser til PostgreSQL afbrydes.
Men en dårligt konfigureret forbindelsespooler kan faktisk reducere ydeevnen, som vi så med Pgpool-II-opsætningen her. En del af problemet er at bruge Pgpool-II doubles antallet af processer, der kører på den samme server - vi skal kør Pgpool-II på en separat server for at få en god ydeevne. Men selv da formår PgBouncer at levere bedre ydeevne til disse relativt små antal kunder.
Bemærk også, at testen her faktisk var perfekt udformet til Pgpool-II – siden når N> 32, var antallet af klienter og antallet af børneprocesser det samme, og derfor, hver genforbindelse var garanteret at finde en cachelagret proces. Selv dengang var PgBouncer det hurtigere alternativ.
Så vores test indikerer, at PgBouncer er det langt bedre valg til forbindelsespooling. Men det er vigtigt at huske, at selvom en forbindelsespooler er absolut obligatorisk for de fleste realistiske arbejdsbelastninger, afhænger om du får mere ved at bruge en klient-side pool eller middleware såsom PgBouncer af din applikation. Mønstre for dataadgang vil spille en rolle, ligesom de involverede latenser baseret på din arkitektur. Vi anbefaler, at du tester din arbejdsbyrde mod begge, og derefter beslutter dig for den bedste fremgangsmåde – der er ikke noget bedre alternativ til at eksperimentere!
