V našich předchozích příspěvcích v této sérii jsme dlouze mluvili o používání PgBouncer a Pgpool-II, architektuře fondu připojení a výhodách a nevýhodách jejich využití pro vaše nasazení PostgreSQL. V našem závěrečném příspěvku je uvedeme do přímého srovnání v podrobném srovnání funkcí a porovnáme výsledky výkonu PgBouncer vs. Pgpool-II pro váš hosting PostgreSQL!
Jak se jednotlivé funkce skládají?
Začněme porovnáním funkcí PgBouncer vs. Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Spotřeba zdrojů | Používá pouze jeden proces, díky čemuž je velmi lehký. PgBouncer zaručuje malou paměťovou náročnost i při práci s velkými datovými sadami. Vítěz! | Pokud požadujeme N paralelních připojení, rozdělí to N podřízených procesů. Ve výchozím nastavení existuje 32 podřízených procesů, které jsou rozvětvené. |
| Kdy jsou připojení znovu použita? | PgBouncer definuje jeden fond na kombinaci uživatele a databáze. Toto je sdíleno mezi všemi klienty, takže sdružené připojení je dostupné všem klientům. Vítěz! | Pgpool-II definuje jeden proces na podřízený proces. Nemůžeme řídit, ke kterému podřízenému procesu se klient připojuje. Klient těží ze sdruženého připojení pouze v případě, že se připojí k potomkovi, který dříve obsluhoval připojení pro tuto kombinaci databáze a uživatele. |
| Režimy sdružování | PgBouncer podporuje tři různé režimy:relace (připojení se vrátí do fondu, když se klient odpojí), transakce (vrácení do fondu, když se klient zaváže nebo vrátí zpět) nebo příkaz ( připojení se vrátilo do fondu po provedení každého příkazu). Vítěz! | Pgpool-II podporuje pouze režim sdružování relací – účinnost sdružování závisí na dobrém chování klientů. |
| Vysoká dostupnost | Nepodporováno. | Vysoká dostupnost PostgreSQL je podporována prostřednictvím vestavěných sledovacích procesů Pgpool-II. Vítěz! |
| Vyvážení zátěže | Nepodporováno – PgBouncer doporučuje použití HAProxy pro vysokou dostupnost a vyrovnávání zátěže. | Podporuje automatické vyrovnávání zátěže – je dokonce dostatečně inteligentní, aby přesměroval požadavky na čtení do pohotovostních režimů a zapsal na master. Vítěz! |
| Podpora více clusterů | Jedna instance PgBouncer může čelit několika clusterům PostgreSQL (jeden uzel nebo sady replik). To může snížit náklady na middleware při použití více clusterů PostgreSQL. Vítěz! (Poznámka – tato výhoda je pouze pro konkrétní scénáře) | Pgpool-II nemá podporu více clusterů. |
| Ovládání připojení | PgBouncer umožňuje omezit připojení na fond, na databázi, na uživatele nebo klienta. Vítěz! | Pgpool-II umožňuje omezit pouze celkový počet připojení. |
| Fronta připojení | PgBouncer podporuje řazení do front na úrovni aplikace (tj. PgBouncer udržuje frontu). Vítěz! | Pgpool-II podporuje řazení do front na úrovni jádra – to může způsobit zamrznutí pg_bench na CentOS 6. |
| Ověření | Přechodové ověřování je podporováno prostřednictvím PgBouncer. Vítěz! | Pgpool-II nepodporuje průchozí ověřování – uživatelé a jejich šifrovaná hesla md5 musí být uvedeni v souboru a ručně aktualizovat pokaždé, když uživatel aktualizuje jejich heslo. Pgpool-II podporuje autentizaci bez hesla prostřednictvím certifikátů PAM nebo SSL. Ty však musí být nastaveny mimo systém PostgreSQL, zatímco PgBouncer to může přenést na server PostgreSQL. |
| Administrace | PgBouncer poskytuje virtuální databázi, která hlásí různé užitečné statistiky. | Pgpool-II poskytuje podrobné administrační rozhraní, včetně GUI. Vítěz! |
| Ověřování založené na hostiteli | Podporováno. Nerozhodně! | Podporováno. Nerozhodně! |
| Podpora SSL | Plná podpora. Nerozhodně! | Plná podpora. Nerozhodně! |
| Logická replikace | Není podporováno prostřednictvím PgBouncer. Nerozhodně! | Podporováno prostřednictvím Pgpool-II, ale to se provádí odesíláním dotazů na zápis všem uzlům a obecně se to nedoporučuje. Nerozhodně! |
| Licence | ISC – velmi tolerantní, v podstatě umožňuje veškeré použití. Nerozhodně! | Vlastní licence – stejně tolerantní. Nerozhodně! |
Sečteno a podtrženo – Pgpool-II je skvělý nástroj, pokud potřebujete vyvažování zátěže a vysokou dostupnost. Sdružování připojení je téměř bonus, který získáte. PgBouncer dělá jen jednu věc, ale dělá to opravdu dobře. Pokud je cílem omezit počet připojení a snížit spotřebu zdrojů, PgBouncer vyhrává.
Je také naprosto v pořádku používat PgBouncer i Pgpool-II v řetězci – můžete mít PgBouncer, který poskytuje sdružování připojení, které komunikuje s Instance Pgpool-II, která poskytuje vysokou dostupnost a vyrovnávání zátěže. To vám dává to nejlepší z obou světů!
Testování výkonu
I když se PgBouncer může zdát teoreticky lepší volbou, teorie může být často zavádějící. Proto jsme pomocí standardního nástroje pgbench postavili dva sdružovací fondy připojení proti sobě, abychom zjistili, který z nich poskytuje lepší propustnost transakcí za sekundu prostřednictvím benchmarkového testu. Pro dobrou míru jsme provedli stejné testy i bez sdružování připojení.
Podmínky testování
Všechny srovnávací testy PostgreSQL byly spuštěny za následujících podmínek:
- Inicializováno pgbench pomocí měřítka 100.
- Zakázalo automatické vysávání na instanci PostgreSQL, aby se zabránilo rušení.
- Žádná jiná pracovní zátěž v tu dobu nefungovala.
- Ke spuštění testů byl použit výchozí skript pgbench.
- Použito výchozí nastavení pro PgBouncer i Pgpool-II, kromě max_children *. Všechny limity PostgreSQL byly také nastaveny na výchozí hodnoty.
- Všechny testy probíhaly jako jedno vlákno na dvoujádrovém počítači s jedním CPU po dobu 5 minut.
- Vynucený pgbench k vytvoření nového připojení pro každou transakci pomocí volby -C. To emuluje úlohy moderních webových aplikací a je to celý důvod, proč používat pooler!
Každou iteraci jsme provedli po dobu 5 minut, abychom zajistili zprůměrování hluku. Zde je návod, jak byl middleware nainstalován:
- Pro PgBouncer jsme jej nainstalovali do stejného boxu jako server(y) PostgreSQL. Toto je konfigurace, kterou používáme v našich spravovaných clusterech PostgreSQL. Protože PgBouncer je velmi lehký proces, jeho instalace na krabici nemá žádný vliv na celkový výkon.
- Pro Pgpool-II jsme testovali, když byla instance Pgpool-II nainstalována na stejném počítači jako PostgreSQL (ve sloupci pole), a když byla nainstalována na jiném počítači (sloupec mimo rámeček). Jak se očekávalo, výkon je mnohem lepší, když je Pgpool-II vybalený, protože nemusí soupeřit se serverem PostgreSQL o zdroje.
Srovnání propustnosti
Zde jsou výsledky transakcí za sekundu (TPS) pro každý scénář v rámci rozsahu počtu klientů:
| Počet klientů | Bez sdružování | PgBouncer | Pgpool-II (na krabici) | Pgpool-II (mimo krabici) |
|---|---|---|---|---|
| 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 | Připojení byla přerušena. | 26,93 | Spojení přerušena, když max-children> 200, pgbench visí na hodnotě max-children, pokud <=100. | Spojení přerušena, když max-children> 200, pgbench visí na hodnotě max-children, pokud <=100. |
Pgpool-II se zablokuje, když je pg_bench spuštěn s více klienty než max_children. Zvýšili jsme tedy max_children, aby odpovídal počtu klientů pro každý testovací běh.
Pokud vypočítáme procentuální nárůst TPS při použití sdružování připojení, získáme toto:
| Počet klientů | PgBouncer | Pgpool-II (na krabici) | Pgpool-II (vypnuto) |
|---|---|---|---|
| 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 % |
* Algoritmus vylepšení =(s poolerem – bez)/bez
Poslední slova
Jak můžete vidět z výsledků testů výkonu, dobře nakonfigurované připojení a vhodný fond připojení mohou drasticky zvýšit propustnost transakcí, a to i u poměrně malého počtu klientů. Sdružení připojení jsou zvláště užitečné pro jejich podporu front – když počet klientů překročí maximální počet klientů podporovaných serverem PostgreSQL, PgBouncer je stále schopen udržovat rychlost transakcí, zatímco přímá připojení k PostgreSQL jsou přerušena.
Špatně nakonfigurovaný fond připojení může ve skutečnosti snížit výkon, jaký jsme viděli u nastavení Pgpool-II zde. Část problému spočívá v použití Pgpool-II doubles počet procesů běžících na stejném serveru – musíme spusťte Pgpool-II na samostatném serveru, abyste dosáhli dobrého výkonu. Ale i tak PgBouncer dokáže poskytovat lepší výkon pro tento relativně malý počet klientů.
Všimněte si také, že tento test byl ve skutečnosti dokonale vytvořen pro Pgpool-II – od doby N> 32 byl počet klientů a počet podřízených procesů stejný, a proto, bylo zaručeno, že každé opětovné připojení najde proces uložený v mezipaměti. Dokonce i tehdy byl PgBouncer rychlejší alternativou.
Naše testování tedy ukazuje, že PgBouncer je mnohem lepší volbou pro sdružování připojení. Je však důležité si pamatovat, že i když je fond připojení naprosto povinný pro nejrealističtější úlohy, to, zda získáte více použitím fondu na straně klienta nebo middlewaru, jako je PgBouncer, závisí na vaší aplikaci. Roli by hrály vzorce přístupu k datům, stejně jako latence na základě vaší architektury. Doporučujeme otestovat svou pracovní zátěž na obou a poté se rozhodnout pro nejlepší postup – neexistuje lepší alternativa k experimentování!
