W naszych poprzednich postach z tej serii obszernie mówiliśmy o używaniu PgBouncer i Pgpool-II, architekturze puli połączeń oraz zaletach i wadach korzystania z nich dla twojego wdrożenia PostgreSQL. W naszym ostatnim poście przedstawimy je łeb w łeb w szczegółowym porównaniu funkcji i porównamy wyniki wydajności PgBouncer i Pgpool-II dla twojego hostingu PostgreSQL!
Jak układają się funkcje?
Zacznijmy od porównania funkcji PgBouncer i Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Zużycie zasobów | Wykorzystuje tylko jeden proces, co czyni go bardzo lekkim. PgBouncer gwarantuje niewielkie zużycie pamięci, nawet w przypadku dużych zbiorów danych. Zwycięzca! | Jeśli potrzebujemy N równoległych połączeń, to rozwidla N procesów potomnych. Domyślnie są 32 procesy potomne, które są rozwidlane. |
| Kiedy połączenia są ponownie używane? | PgBouncer definiuje jedną pulę na kombinację użytkownika + baza danych. Jest to wspólne dla wszystkich klientów, więc połączenie w puli jest dostępne dla wszystkich klientów. Zwycięzca! | Pgpool-II definiuje jeden proces na proces podrzędny. Nie możemy kontrolować, z którym procesem podrzędnym łączy się klient. Klient korzysta z połączenia w puli tylko wtedy, gdy łączy się z dzieckiem, które wcześniej obsługiwało połączenie dla tej kombinacji baza danych + użytkownik. |
| Tryby łączenia | PgBouncer obsługuje trzy różne tryby:sesja (połączenie zwracane do puli po rozłączeniu klienta), transakcja (powracane do puli po zatwierdzeniu lub wycofaniu przez klienta) lub oświadczenie ( połączenie zwrócone do puli po wykonaniu każdej instrukcji). Zwycięzca! | Pgpool-II obsługuje tylko tryb puli sesji – skuteczność puli zależy od dobrego zachowania klientów. |
| Wysoka dostępność | Nieobsługiwane. | Wysoka dostępność PostgreSQL jest obsługiwana przez wbudowane procesy monitorujące Pgpool-II. Zwycięzca! |
| Równoważenie obciążenia | Nieobsługiwane – PgBouncer zaleca użycie HAProxy w celu zapewnienia wysokiej dostępności i równoważenia obciążenia. | Obsługuje automatyczne równoważenie obciążenia — jest nawet wystarczająco inteligentny, aby przekierowywać żądania odczytu do stanu gotowości i zapisu do masterów. Zwycięzca! |
| Obsługa wielu klastrów | Jedna instancja PgBouncer może obsługiwać kilka klastrów PostgreSQL (jednowęzłowych lub zestawów replik). Może to obniżyć koszt oprogramowania pośredniczącego w przypadku korzystania z wielu klastrów PostgreSQL. Zwycięzca! (Uwaga – ta zaleta dotyczy tylko określonych scenariuszy) | Pgpool-II nie obsługuje wielu klastrów. |
| Kontrola połączenia | PgBouncer umożliwia ograniczenie połączeń na pulę, na bazę danych, na użytkownika lub na klienta. Zwycięzca! | Pgpool-II pozwala tylko na ograniczenie ogólnej liczby połączeń. |
| Kolejka połączeń | PgBouncer obsługuje kolejkowanie na poziomie aplikacji (tj. PgBouncer utrzymuje kolejkę). Zwycięzca! | Pgpool-II obsługuje kolejkowanie na poziomie jądra – może to spowodować zawieszenie się pg_bench w CentOS 6. |
| Uwierzytelnianie | Uwierzytelnianie przekazywane jest obsługiwane przez PgBouncer. Zwycięzca! | Pgpool-II nie obsługuje uwierzytelniania przekazywanego — użytkownicy i ich hasła zaszyfrowane md5 muszą być wymienione w pliku i aktualizowane ręcznie przy każdej aktualizacji użytkownika ich hasło. Pgpool-II obsługuje uwierzytelnianie bez hasła za pomocą certyfikatów PAM lub SSL. Jednak muszą one być skonfigurowane poza systemem PostgreSQL, podczas gdy PgBouncer może przenieść to na serwer PostgreSQL. |
| Administracja | PgBouncer zapewnia wirtualną bazę danych, która raportuje różne przydatne statystyki. | Pgpool-II zapewnia szczegółowy interfejs administracyjny, w tym GUI. Zwycięzca! |
| Uwierzytelnianie oparte na hoście | Obsługiwane. Związana! | Obsługiwane. Związana! |
| Obsługa SSL | Pełna obsługa. Związana! | Pełna obsługa. Związana! |
| Replikacja logiczna | Nieobsługiwane przez PgBouncer. Związana! | Obsługiwane przez Pgpool-II, ale odbywa się to poprzez wysyłanie zapytań zapisu do wszystkich węzłów i generalnie nie jest to zalecane. Związana! |
| Licencja | ISC – bardzo liberalny, w zasadzie pozwala na dowolne użycie. Związana! | Licencja niestandardowa – równie liberalna. Związana! |
Dolna linia – Pgpool-II to świetne narzędzie, jeśli potrzebujesz równoważenia obciążenia i wysokiej dostępności. Pule połączeń to prawie bonus, który otrzymujesz. PgBouncer robi tylko jedną rzecz, ale robi to naprawdę dobrze. Jeśli celem jest ograniczenie liczby połączeń i zmniejszenie zużycia zasobów, PgBouncer wygrywa.
Dobrze jest również używać zarówno PgBouncera, jak i Pgpool-II w łańcuchu – możesz mieć PgBouncer, aby zapewnić pulę połączeń, która komunikuje się z Instancja Pgpool-II zapewniająca wysoką dostępność i równoważenie obciążenia. To daje to, co najlepsze z obu światów!
Testowanie wydajności
Podczas gdy teoretycznie PgBouncer może wydawać się lepszą opcją, teoria często może wprowadzać w błąd. Zmierzyliśmy się więc z dwoma grupami połączeń, używając standardowego narzędzia pgbench, aby sprawdzić, który z nich zapewnia lepszą przepustowość transakcji na sekundę w teście porównawczym. Na wszelki wypadek przeprowadziliśmy te same testy bez puli połączeń.
Warunki testowania
Wszystkie testy porównawcze PostgreSQL zostały przeprowadzone w następujących warunkach:
- Zainicjowano pgbench przy użyciu współczynnika skali 100.
- Wyłączone automatyczne odkurzanie w instancji PostgreSQL, aby zapobiec zakłóceniom.
- Żadne inne obciążenie nie działało w tym czasie.
- Użył domyślnego skryptu pgbench do uruchomienia testów.
- Użyto ustawień domyślnych zarówno dla PgBouncera, jak i Pgpool-II, z wyjątkiem max_children *. Wszystkie limity PostgreSQL zostały również ustawione na wartości domyślne.
- Wszystkie testy przebiegały jako pojedynczy wątek na jednoprocesorowej, dwurdzeniowej maszynie przez 5 minut.
- Zmusił pgbench do utworzenia nowego połączenia dla każdej transakcji przy użyciu opcji -C. To emuluje obciążenia nowoczesnych aplikacji internetowych i jest głównym powodem, dla którego warto korzystać z poolera!
Przeprowadzaliśmy każdą iterację przez 5 minut, aby zapewnić uśrednienie wszelkich szumów. Oto jak zainstalowano oprogramowanie pośredniczące:
- W przypadku PgBouncera zainstalowaliśmy go na tym samym polu, co serwer(y) PostgreSQL. Jest to konfiguracja, której używamy w naszych zarządzanych klastrach PostgreSQL. Ponieważ PgBouncer jest bardzo lekkim procesem, zainstalowanie go na pudełku nie ma wpływu na ogólną wydajność.
- W przypadku Pgpool-II przetestowaliśmy zarówno, gdy instancja Pgpool-II była zainstalowana na tej samej maszynie, co PostgreSQL (w kolumnie box), jak i wtedy, gdy została zainstalowana na innej maszynie (kolumna poza polem). Zgodnie z oczekiwaniami wydajność jest znacznie lepsza, gdy Pgpool-II jest gotowy do użycia, ponieważ nie musi konkurować z serwerem PostgreSQL o zasoby.
Wzorzec przepustowości
Oto wyniki transakcji na sekundę (TPS) dla każdego scenariusza w zakresie liczby klientów:
| Liczba klientów | Bez łączenia | PgBouncer | Pgpool-II (na pudełku) | Pgpool-II (wyłączony z pudełka) |
|---|---|---|---|---|
| 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 | Połączenia przerwane. | 26,93 | Połączenia przerwane, gdy max-children> 200, pgbench zawiesza się na wartości max-children, jeśli <=100. | Połączenia przerwane, gdy max-children> 200, pgbench zawiesza się na wartości max-children, jeśli <=100. |
Pgpool-II zawiesza się, gdy pg_bench jest uruchamiany z większą liczbą klientów niż max_children. Dlatego zwiększyliśmy max_children, aby dopasować liczbę klientów do każdego uruchomienia testu.
Jeśli obliczymy procentowy wzrost TPS podczas korzystania z puli połączeń, oto, co otrzymujemy:
| Liczba klientów | PgBouncer | Pgpool-II (na pudełku) | 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% |
* Algorytm poprawy =(z poolerem – bez)/bez
Końcowe słowa
Jak widać z wyników testów wydajności, dobrze skonfigurowane połączenie i dobrze dopasowany pooler połączeń może drastycznie zwiększyć przepustowość transakcji, nawet przy dość małej liczbie klientów. Pule połączeń są szczególnie przydatne do obsługi kolejkowania – gdy liczba klientów przekracza maksymalną liczbę klientów obsługiwanych przez serwer PostgreSQL, PgBouncer nadal jest w stanie utrzymać szybkość transakcji, podczas gdy bezpośrednie połączenia z PostgreSQL są przerywane.
Jednak źle skonfigurowany pooler połączeń może w rzeczywistości zredukować wydajność, jaką widzieliśmy z konfiguracją Pgpool-II tutaj. Częścią problemu jest użycie Pgpool-II podwaja się liczba procesów działających na tym samym serwerze — musimy uruchom Pgpool-II na osobnym serwerze, aby uzyskać dobrą wydajność. Ale nawet wtedy PgBouncer zapewnia lepszą wydajność dla tych stosunkowo niewielkiej liczby klientów.
Zauważ również, że test tutaj był w rzeczywistości doskonale przygotowany dla Pgpool-II – od kiedy N> 32, liczba klientów i liczba procesów potomnych były takie same, a co za tym idzie, każde ponowne połączenie gwarantowało znalezienie procesu w pamięci podręcznej. Nawet wtedy PgBouncer był szybszą alternatywą.
Tak więc nasze testy wskazują, że PgBouncer jest znacznie lepszym wyborem do puli połączeń. Należy jednak pamiętać, że chociaż pula połączeń jest absolutnie obowiązkowa w przypadku najbardziej realistycznych obciążeń, to, czy zyskasz więcej, korzystając z puli po stronie klienta, czy oprogramowania pośredniczącego, takiego jak PgBouncer, zależy od Twojej aplikacji. Pewną rolę odgrywałyby wzorce dostępu do danych, podobnie jak związane z tym opóźnienia w oparciu o Twoją architekturę. Zalecamy przetestowanie obciążenia pracą pod kątem obu, a następnie podjęcie decyzji o najlepszym sposobie działania – nie ma lepszej alternatywy dla eksperymentowania!
