I våra tidigare inlägg i den här serien pratade vi länge om att använda PgBouncer och Pgpool-II, anslutningspoolarkitekturen och för- och nackdelar med att utnyttja en för din PostgreSQL-distribution. I vårt sista inlägg kommer vi att sätta dem head-to-head i en detaljerad funktionsjämförelse och jämföra resultaten av PgBouncer vs. Pgpool-II prestanda för ditt PostgreSQL-värd!
Hur fungerar funktionerna?
Låt oss börja med att jämföra funktionerna i PgBouncer och Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Resursförbrukning | Den använder bara en process vilket gör den väldigt lätt. PgBouncer garanterar ett litet minnesfotavtryck, även när det handlar om stora datamängder. Vinnare! | Om vi kräver N parallella anslutningar delar detta upp N underordnade processer. Som standard finns det 32 underordnade processer som är splittrade. |
| När återanvänds anslutningar? | PgBouncer definierar en pool per kombination av användare+databas. Detta delas mellan alla klienter, så en poolad anslutning är tillgänglig för alla klienter. Vinnare! | Pgpool-II definierar en process per underordnad process. Vi kan inte kontrollera vilken underordnad process en klient ansluter till. En klient drar nytta av en poolad anslutning endast om den ansluter till ett barn som tidigare har betjänat en anslutning för denna databas+användarkombination. |
| Pooling-lägen | PgBouncer stöder tre olika lägen:session (anslutning returneras till poolen när klienten kopplar ner), transaktion (återvänd till poolen när klienten begår eller återställer) eller uttalande ( anslutningen återvände till poolen efter körningen av varje sats). Vinnare! | Pgpool-II stöder endast sessionspoolningsläge – effektiviteten av pooling är beroende av bra beteende från klienter. |
| Hög tillgänglighet | Stöds inte. | PostgreSQL hög tillgänglighet stöds genom Pgpool-II inbyggda bevakningsprocesser. Vinnare! |
| Lastbalansering | Stöds inte – PgBouncer rekommenderar användning av HAProxy för hög tillgänglighet och lastbalansering. | Stöder automatisk lastbalansering – är till och med intelligent nog att omdirigera läsbegäranden till standbylägen och skriver till masters. Vinnare! |
| Stöd för flera kluster | En PgBouncer-instans kan fronta flera PostgreSQL-kluster (en-nods- eller replikuppsättningar). Detta kan minska kostnaden för mellanprogram när du använder flera PostgreSQL-kluster. Vinnare! (Obs – den här fördelen är endast för specifika scenarier) | Pgpool-II har inte stöd för flera kluster. |
| Anslutningskontroll | PgBouncer tillåter begränsning av anslutningar per pool, per databas, per användare eller per klient. Vinnare! | Pgpool-II tillåter endast att begränsa det totala antalet anslutningar. |
| Anslutningskö | PgBouncer stöder köbildning på applikationsnivå (dvs. PgBouncer underhåller kön). Vinnare! | Pgpool-II stöder köbildning på kärnnivå – detta kan göra att pg_bench på CentOS 6 fryser. |
| Autentisering | Pass-through-autentisering stöds genom PgBouncer. Vinnare! | Pgpool-II stöder inte pass-through-autentisering – användare och deras md5-krypterade lösenord måste listas i en fil och uppdateras manuellt varje gång en användare uppdaterar deras lösenord. Pgpool-II stöder lösenordslös autentisering genom PAM- eller SSL-certifikat. Dessa måste dock ställas in utanför PostgreSQL-systemet, medan PgBouncer kan ladda ner detta till PostgreSQL-servern. |
| Administration | PgBouncer tillhandahåller en virtuell databas som rapporterar olika användbar statistik. | Pgpool-II tillhandahåller ett detaljerat administrationsgränssnitt, inklusive ett GUI. Vinnare! |
| Värdbaserad autentisering | Stöds. Oavgjort! | Stöds. Oavgjort! |
| SSL-stöd | Fullt stöd. Oavgjort! | Fullt stöd. Oavgjort! |
| Logisk replikering | Stöds inte via PgBouncer. Oavgjort! | Stöds genom Pgpool-II, men detta görs genom att skicka skrivfrågorna till alla noder, och rekommenderas inte generellt. Oavgjort! |
| Licens | ISC – mycket tillåtande, tillåter i princip all användning. Oavgjort! | Anpassad licens – lika tillåtande. Oavgjort! |
Sammanfattning – Pgpool-II är ett utmärkt verktyg om du behöver belastningsbalansering och hög tillgänglighet. Connection pooling är nästan en bonus du får tillsammans med. PgBouncer gör bara en sak, men gör det riktigt bra. Om målet är att begränsa antalet anslutningar och minska resursförbrukningen, vinner PgBouncer helt klart.
Det går också alldeles utmärkt att använda både PgBouncer och Pgpool-II i en kedja – du kan ha en PgBouncer för att tillhandahålla anslutningspoolning, som talar med en Pgpool-II-instans som ger hög tillgänglighet och lastbalansering. Detta ger dig det bästa av två världar!
Prestandatest
Medan PgBouncer kan tyckas vara det bättre alternativet i teorin, kan teori ofta vara missvisande. Så, vi satte de två anslutningspoolarna head-to-head, med hjälp av standardverktyget pgbench, för att se vilken som ger bättre transaktioner per sekund genomströmning genom ett benchmarktest. För godo så körde vi samma test utan anslutningspooler också.
Testvillkor
Alla PostgreSQL benchmark-tester kördes under följande förhållanden:
- Initialiserad pgbench med en skalfaktor på 100.
- Inaktiverad automatisk dammsugning på PostgreSQL-instansen för att förhindra störningar.
- Ingen annan arbetsbelastning fungerade vid tillfället.
- Använde standardskriptet pgbench för att köra testen.
- Använde standardinställningar för både PgBouncer och Pgpool-II, förutom max_children *. Alla PostgreSQL-gränser var också inställda på sina standardinställningar.
- Alla tester kördes som en enda tråd, på en en-CPU, 2-kärnig maskin, under en varaktighet av 5 minuter.
- Tvingade pgbench att skapa en ny anslutning för varje transaktion med alternativet -C. Detta emulerar moderna webbapplikationers arbetsbelastningar och är hela anledningen till att använda en pooler!
Vi körde varje iteration i 5 minuter för att säkerställa ett genomsnitt av brus. Så här installerades mellanvaran:
- För PgBouncer installerade vi den på samma box som PostgreSQL-servern(arna). Det här är konfigurationen vi använder i våra hanterade PostgreSQL-kluster. Eftersom PgBouncer är en mycket lätt process, har installationen på lådan ingen inverkan på den totala prestandan.
- För Pgpool-II testade vi både när Pgpool-II-instansen installerades på samma maskin som PostgreSQL (på boxkolumnen) och när den installerades på en annan dator (off box kolumn). Som väntat är prestandan mycket bättre när Pgpool-II är off-box eftersom den inte behöver konkurrera med PostgreSQL-servern om resurser.
Benchmark för genomströmning
Här är resultaten för transaktioner per sekund (TPS) för varje scenario över ett antal kunder:
| Antal klienter | Utan pooling | PgBouncer | Pgpool-II (på kartongen) | 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 | Anslutningar avbröts. | 26.93 | Anslutningar avbröts när max-children> 200, pgbench hänger på max-children-värdet om <=100. | Anslutningar avbröts när max-children> 200, pgbench hänger på max-children-värdet om <=100. |
Pgpool-II hänger sig när pg_bench körs med fler klienter än max_children. Så vi ökade max_children för att matcha antalet klienter för varje testkörning.
Om vi beräknar den procentuella ökningen av TPS när vi använder en anslutningspooler får vi det här:
| Antal klienter | PgBouncer | Pgpool-II (på box) | 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 % |
* Förbättringsalgoritm =(med pooler – utan)/utan
Slutord
Som du kan se från prestandatestresultaten kan en välkonfigurerad anslutning och en väl lämpad anslutningspooler drastiskt öka transaktionsgenomströmningen, även med ett ganska litet antal klienter. Anslutningspoolare är särskilt användbara för deras köstöd – när antalet klienter överstiger max-klienter som stöds av PostgreSQL-servern kan PgBouncer fortfarande behålla transaktionshastigheten, medan direkta anslutningar till PostgreSQL avbryts.
Men en dåligt konfigurerad anslutningspoolare kan faktiskt minska prestandan som vi såg med Pgpool-II-installationen här. En del av problemet är att använda Pgpool-II dubbel antalet processer som körs på samma server - vi måste kör Pgpool-II på en separat server för att få bra prestanda. Men även då lyckas PgBouncer ge bättre prestanda för dessa relativt små antal kunder.
Observera också att testet här faktiskt var perfekt utformat för Pgpool-II – sedan när N> 32 var antalet klienter och antalet underordnade processer desamma, och därför, varje återanslutning hittade garanterat en cachad process. Redan då var PgBouncer det snabbare alternativet.
Så våra tester visar att PgBouncer är det mycket bättre valet för anslutningspoolning. Men det är viktigt att komma ihåg att även om en anslutningspoolare är absolut obligatorisk för de flesta realistiska arbetsbelastningar, beror om du vinner mer genom att använda en pool på klientsidan eller mellanprogram som PgBouncer på din applikation. Mönster för dataåtkomst skulle spela en roll, liksom latenserna som är involverade baserat på din arkitektur. Vi rekommenderar att du testar din arbetsbelastning mot båda och sedan bestämmer dig för det bästa tillvägagångssättet – det finns inget bättre alternativ till att experimentera!
