В предишните ни публикации от тази серия говорихме подробно за използването на PgBouncer и Pgpool-II, архитектурата на пула за връзки и плюсовете и минусите на използването на един за вашето внедряване на PostgreSQL. В нашата последна публикация ще ги поставим един до друг в подробно сравнение на функциите и ще сравним резултатите от производителността на PgBouncer срещу Pgpool-II за вашия PostgreSQL хостинг!
Как се подреждат функциите?
Нека започнем със сравняване на функциите на PgBouncer и Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Разход на ресурси | Използва само един процес, което го прави много лек. PgBouncer гарантира малък отпечатък на паметта, дори когато работите с големи набори от данни. Победител! | Ако имаме нужда от N паралелни връзки, това се разклонява N дъщерни процеса. По подразбиране има 32 дъщерни процеса, които са разклонени. |
| Кога връзките се използват повторно? | PgBouncer дефинира един пул за комбинация потребител+база данни. Това се споделя между всички клиенти, така че обединената връзка е достъпна за всички клиенти. Победител! | Pgpool-II дефинира един процес за дъщерен процес. Не можем да контролираме към кой дъщерен процес се свързва клиентът. Клиентът се възползва от обединена връзка само ако се свърже с дъщерно, което преди това е обслужвало връзка за тази комбинация база данни+потребител. |
| Режими на обединяване | PgBouncer поддържа три различни режима:сесия (връзката се връща към пула, когато клиентът прекъсне връзката), транзакция (връща се към пула, когато клиентът извършва ангажименти или връщане назад) или изявление ( връзката се връща към пула след изпълнението на всеки израз). Победител! | Pgpool-II поддържа само режим на обединяване на сесии – ефективността на обединяването зависи от доброто поведение на клиентите. |
| Висока наличност | Не се поддържа. | Високата наличност на PostgreSQL се поддържа чрез вградени процеси за наблюдение на Pgpool-II. Победител! |
| Балансиране на натоварването | Не се поддържа – PgBouncer препоръчва използването на HAProxy за висока наличност и балансиране на натоварването. | Поддържа автоматично балансиране на натоварването – дори е достатъчно интелигентен, за да пренасочва заявките за четене към режим на готовност и записва към главните. Победител! |
| Поддръжка на множество клъстери | Един екземпляр на PgBouncer може да предства няколко PostgreSQL клъстера (един възел или набори от реплики). Това може да намали разходите за междинен софтуер при използване на множество PostgreSQL клъстери. Победител! (Забележка – това предимство е само за конкретни сценарии) | Pgpool-II няма поддръжка за множество клъстери. |
| Контрол на връзката | PgBouncer позволява ограничаване на връзките за пул, за база данни, за потребител или за клиент. Победител! | Pgpool-II позволява ограничаване само на общия брой връзки. |
| Опашка за свързване | PgBouncer поддържа опашка на ниво приложение (т.е. PgBouncer поддържа опашката). Победител! | Pgpool-II поддържа опашка на ниво ядро – това може да доведе до замръзване на pg_bench на CentOS 6. |
| Удостоверяване | Пропускането на удостоверяване се поддържа чрез PgBouncer. Победител! | Pgpool-II не поддържа удостоверяване чрез преминаване – потребителите и техните md5 криптирани пароли трябва да бъдат изброени във файл и ръчно актуализирани всеки път, когато потребителят актуализира тяхната парола. Pgpool-II поддържа удостоверяване без парола чрез PAM или SSL-сертификати. Те обаче трябва да бъдат настроени извън системата PostgreSQL, докато PgBouncer може да разтовари това на сървъра на PostgreSQL. |
| Администриране | PgBouncer предоставя виртуална база данни, която отчита различни полезни статистически данни. | Pgpool-II предоставя подробен административен интерфейс, включително GUI. Победител! |
| Удостоверяване, базирано на хост | Поддържа се. Изравнено! | Поддържа се. Изравнено! |
| Поддръжка на SSL | Пълна поддръжка. Изравнено! | Пълна поддръжка. Изравнено! |
| Логическа репликация | Не се поддържа от PgBouncer. Изравнено! | Поддържа се чрез Pgpool-II, но това се прави чрез изпращане на заявките за запис до всички възли и обикновено не се препоръчва. Изравнено! |
| Лиценз | ISC – много разрешително, основно позволява всякаква употреба. Изравнено! | Персонализиран лиценз – също толкова разрешително. Изравнено! |
В крайна сметка – Pgpool-II е чудесен инструмент, ако имате нужда от балансиране на натоварването и висока наличност. Обединяването на връзки е почти бонус, който получавате заедно. PgBouncer прави само едно нещо, но го прави наистина добре. Ако целта е да се ограничи броят на връзките и да се намали консумацията на ресурси, PgBouncer печели ръцете.
Също така е напълно добре да използвате както PgBouncer, така и Pgpool-II във верига – можете да имате PgBouncer, за да осигурите обединяване на връзки, което говори с Pgpool-II екземпляр, който осигурява висока наличност и балансиране на натоварването. Това ви дава най-доброто от двата свята!
Тестване на производителността
Докато PgBouncer може да изглежда по-добрият вариант на теория, теорията често може да бъде подвеждаща. И така, сблъскахме двата пулера за връзки един до друг, използвайки стандартния инструмент pgbench, за да видим кой от тях осигурява по-добра пропускателна способност на транзакции в секунда чрез сравнителен тест. За добра мярка проведохме същите тестове и без пул за връзка.
Условия на тестване
Всички тестове за сравнение на PostgreSQL бяха проведени при следните условия:
- Инициализиран pgbench с коефициент на мащабиране 100.
- Автоматичното вакуумиране на екземпляра на PostgreSQL за предотвратяване на смущения е деактивирано.
- Няма друго работно натоварване по това време.
- Използва скрипта pgbench по подразбиране за стартиране на тестовете.
- Използвани настройки по подразбиране както за PgBouncer, така и за Pgpool-II, с изключение на max_children *. Всички ограничения на PostgreSQL също бяха зададени по подразбиране.
- Всички тестове се изпълняваха като една нишка, на еднопроцесорна, 2-ядрена машина за продължителност от 5 минути.
- Принуден pgbench да създаде нова връзка за всяка транзакция с помощта на опцията -C. Това емулира натоварванията на съвременните уеб приложения и е цялата причина да използвате пулър!
Изпълнявахме всяка итерация в продължение на 5 минути, за да осигурим осреднения шум. Ето как е инсталиран междинният софтуер:
- За PgBouncer го инсталирахме на същото поле като сървъра(ите) на PostgreSQL. Това е конфигурацията, която използваме в нашите управлявани PostgreSQL клъстери. Тъй като PgBouncer е много лек процес, инсталирането му на кутията няма влияние върху цялостната производителност.
- За Pgpool-II тествахме и когато екземплярът на Pgpool-II беше инсталиран на същата машина като PostgreSQL (в колона на кутия), и когато беше инсталиран на друга машина (колона извън кутията). Както се очакваше, производителността е много по-добра, когато Pgpool-II е готов, тъй като не е нужно да се конкурира със сървъра на PostgreSQL за ресурси.
Сравнение на пропускателната способност
Ето резултатите за транзакциите в секунда (TPS) за всеки сценарий в обхват от брой клиенти:
| Брой клиенти | Без обединяване | PgBouncer | Pgpool-II (на кутия) | Pgpool-II (извън кутията) |
|---|---|---|---|---|
| 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 | Връзките са прекратени. | 26,93 | Връзките са прекратени, когато max-children> 200, pgbench увисва при стойност max-children, ако <=100. | Връзките са прекратени, когато max-children> 200, pgbench увисва при стойност max-children, ако <=100. |
Pgpool-II увисва, когато pg_bench се изпълнява с повече клиенти от max_children. Така че увеличихме max_children, за да съответства на броя на клиентите за всяко тестово изпълнение.
Ако изчислим процентното увеличение на TPS, когато използваме пул за връзки, ето какво получаваме:
| Брой клиенти | PgBouncer | Pgpool-II (в кутия) | Pgpool-II (изключено поле) |
|---|---|---|---|
| 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% |
* Алгоритъм за подобрение =(с пулър – без)/без
Последни думи
Както можете да видите от резултатите от теста за производителност, добре конфигурираната връзка и добре пригоденият пул за връзки могат драстично да увеличат пропускателната способност на транзакциите, дори при сравнително малък брой клиенти. Пуловите за връзки са особено полезни за тяхната поддръжка на опашка – когато броят на клиентите надвишава максималния брой клиенти, поддържан от PostgreSQL сървъра, PgBouncer все още може да поддържа скоростта на транзакциите, докато директните връзки към PostgreSQL се прекратяват.
Въпреки това, лошо конфигуриран пул за връзки може всъщност намали производителността, както видяхме с настройката на Pgpool-II тук. Част от проблема е използването на Pgpool-II doubles броят на процесите, изпълнявани на същия сървър - трябва стартирайте Pgpool-II на отделен сървър, за да получите добра производителност. Но дори и тогава PgBouncer успява да осигури по-добра производителност за този сравнително малък брой клиенти.
Освен това, имайте предвид, че тестът тук всъщност беше перфектно изработен за Pgpool-II – тъй като когато N> 32, броят на клиентите и броят на дъщерните процеси бяха еднакви и следователно, всяко повторно свързване е гарантирано за намиране на кеширан процес. Дори тогава PgBouncer беше по-бързата алтернатива.
И така, нашето тестване показва, че PgBouncer е далеч по-добрият избор за обединяване на връзки. Но е важно да запомните, че докато пулърът за връзки е абсолютно задължителен за повечето реалистични работни натоварвания, дали ще спечелите повече чрез използване на пул от страна на клиента или междинен софтуер като PgBouncer зависи от вашето приложение. Моделите на достъп до данни биха играли роля, както и свързаните латентности въз основа на вашата архитектура. Препоръчваме да тествате работното си натоварване и срещу двете и след това да вземете решение за най-добрия начин на действие – няма по-добра алтернатива за експериментирането!
