Em nossas postagens anteriores desta série, falamos longamente sobre o uso do PgBouncer e do Pgpool-II, a arquitetura do pool de conexões e os prós e contras de aproveitar um para sua implantação do PostgreSQL. Em nosso post final, vamos colocá-los frente a frente em uma comparação detalhada de recursos e comparar os resultados do desempenho do PgBouncer vs. Pgpool-II para sua hospedagem PostgreSQL!
Como os recursos se agrupam?
Vamos começar comparando os recursos do PgBouncer com o do Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Consumo de recursos | Ele usa apenas um processo o que o torna muito leve. O PgBouncer garante um pequeno consumo de memória, mesmo ao lidar com grandes conjuntos de dados. Vencedor! | Se precisarmos de N conexões paralelas, isso bifurca N processos filhos. Por padrão, existem 32 processos filhos que são bifurcados. |
| Quando as conexões são reutilizadas? | PgBouncer define um pool por combinação de usuário+banco de dados. Isso é compartilhado entre todos os clientes, portanto, uma conexão em pool está disponível para todos os clientes. Vencedor! | Pgpool-II define um processo por processo filho. Não podemos controlar a qual processo filho um cliente se conecta. Um cliente se beneficia de uma conexão em pool somente se se conectar a um filho que já serviu uma conexão para esta combinação de banco de dados+usuário. |
| Modos de agrupamento | PgBouncer suporta três modos diferentes:sessão (conexão retornada ao pool quando o cliente se desconecta), transação (retornada ao pool quando o cliente confirma ou reverte) ou instrução ( conexão retornada ao pool após a execução de cada instrução). Vencedor! | Pgpool-II suporta apenas o modo de pool de sessão – a eficácia do pooling depende do bom comportamento dos clientes. |
| Alta disponibilidade | Não suportado. | A alta disponibilidade do PostgreSQL é suportada por meio de processos watcher integrados ao Pgpool-II. Vencedor! |
| Balanceamento de carga | Não suportado – PgBouncer recomenda o uso de HAProxy para alta disponibilidade e balanceamento de carga. | Suporta balanceamento de carga automático – é inteligente o suficiente para redirecionar solicitações de leitura para standbys e gravações para masters. Vencedor! |
| Suporte a vários clusters | Uma instância do PgBouncer pode fazer frente a vários clusters PostgreSQL (um nó ou conjuntos de réplicas). Isso pode reduzir o custo do middleware ao usar vários clusters PostgreSQL. Vencedor! (Observação:essa vantagem é apenas para cenários específicos) | Pgpool-II não tem suporte para vários clusters. |
| Controle de conexão | PgBouncer permite limitar conexões por pool, por banco de dados, por usuário ou por cliente. Vencedor! | Pgpool-II permite limitar apenas o número total de conexões. |
| Fila de conexão | PgBouncer suporta enfileiramento no nível do aplicativo (ou seja, o PgBouncer mantém a fila). Vencedor! | Pgpool-II suporta enfileiramento no nível do kernel – isso pode fazer com que o pg_bench no CentOS 6 congele. |
| Autenticação | A autenticação de passagem é suportada pelo PgBouncer. Vencedor! | O Pgpool-II não oferece suporte à autenticação de passagem. Os usuários e suas senhas criptografadas em md5 devem ser listados em um arquivo e atualizados manualmente sempre que um usuário atualizar sua senha. O Pgpool-II suporta autenticação sem senha por meio de certificados PAM ou SSL. No entanto, eles devem ser configurados fora do sistema PostgreSQL, enquanto o PgBouncer pode descarregar isso para o servidor PostgreSQL. |
| Administração | PgBouncer fornece um banco de dados virtual que relata várias estatísticas úteis. | Pgpool-II fornece uma interface de administração detalhada, incluindo uma GUI. Vencedor! |
| Autenticação baseada em host | Suportado. Empatado! | Suportado. Empatado! |
| Suporte SSL | Suporte total. Empatado! | Suporte total. Empatado! |
| Replicação lógica | Não suportado pelo PgBouncer. Empatado! | Suportado pelo Pgpool-II, mas isso é feito enviando as consultas de gravação para todos os nós e geralmente não é recomendado. Empatado! |
| Licença | ISC – muito permissivo, basicamente permite todo o uso. Empatado! | Licença personalizada – igualmente permissiva. Empatado! |
O resultado final – o Pgpool-II é uma ótima ferramenta se você precisar de balanceamento de carga e alta disponibilidade. O pool de conexões é quase um bônus que você recebe ao lado. O PgBouncer faz apenas uma coisa, mas faz muito bem. Se o objetivo é limitar o número de conexões e reduzir o consumo de recursos, o PgBouncer vence.
Também é perfeitamente aceitável usar o PgBouncer e o Pgpool-II em uma cadeia – você pode ter um PgBouncer para fornecer pool de conexões, que se comunica com um Instância Pgpool-II que fornece alta disponibilidade e balanceamento de carga. Isso lhe dá o melhor dos dois mundos!
Pool de conexões do PostgreSQL:Parte 4 – PgBouncer vs. Pgpool-IIClick To Tweet
Teste de desempenho
Embora o PgBouncer possa parecer a melhor opção em teoria, a teoria muitas vezes pode ser enganosa. Assim, colocamos os dois poolers de conexão frente a frente, usando a ferramenta pgbench padrão, para ver qual deles fornece melhores transações por segundo através de um teste de benchmark. Para uma boa medida, também executamos os mesmos testes sem um pool de conexões.
Condições de teste
Todos os testes de benchmark do PostgreSQL foram executados nas seguintes condições:
- Pgbench inicializado usando um fator de escala de 100.
- Desativação da auto-aspiração na instância do PostgreSQL para evitar interferências.
- Nenhuma outra carga de trabalho estava funcionando no momento.
- Usou o script pgbench padrão para executar os testes.
- Configurações padrão usadas para PgBouncer e Pgpool-II, exceto max_children *. Todos os limites do PostgreSQL também foram definidos para seus padrões.
- Todos os testes foram executados como um único thread, em uma máquina de CPU única e 2 núcleos, por uma duração de 5 minutos.
- Forçou o pgbench a criar uma nova conexão para cada transação usando a opção -C. Isso emula cargas de trabalho de aplicativos da Web modernos e é o motivo para usar um pooler!
Executamos cada iteração por 5 minutos para garantir a média de qualquer ruído. Veja como o middleware foi instalado:
- Para o PgBouncer, nós o instalamos na mesma caixa do(s) servidor(es) PostgreSQL. Esta é a configuração que usamos em nossos clusters PostgreSQL gerenciados. Como o PgBouncer é um processo muito leve, instalá-lo na caixa não afeta o desempenho geral.
- Para o Pgpool-II, testamos tanto quando a instância do Pgpool-II foi instalada na mesma máquina que o PostgreSQL (na coluna box), quanto quando foi instalada em uma máquina diferente (coluna fora da caixa). Como esperado, o desempenho é muito melhor quando o Pgpool-II está pronto para uso, pois não precisa competir com o servidor PostgreSQL por recursos.
Padrão de comparação de rendimento
Aqui estão os resultados de transações por segundo (TPS) para cada cenário em um intervalo de número de clientes:
| Número de clientes | Sem agrupamento | PgBouncer | Pgpool-II (na caixa) | Pgpool-II (fora da caixa) |
|---|---|---|---|---|
| 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 | Conexões abortadas. | 26,93 | Conexões abortadas quando max-children> 200, pgbench trava no valor max-children se <=100. | Conexões abortadas quando max-children> 200, pgbench trava no valor max-children se <=100. |
Pgpool-II trava quando pg_bench é executado com mais clientes que max_children. Portanto, aumentamos o max_children para corresponder ao número de clientes para cada execução de teste.
Se calcularmos o aumento percentual no TPS ao usar um pool de conexões, eis o que obtemos:
| Número de clientes | PgBouncer | Pgpool-II (na caixa) | 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% |
* Algoritmo de melhoria =(com pooler – sem)/sem
Palavras Finais
Como você pode ver pelos resultados do teste de desempenho, uma conexão bem configurada e um pool de conexões adequado podem aumentar drasticamente o rendimento da transação, mesmo com um número bastante pequeno de clientes. Os pools de conexões são especialmente úteis para o suporte a filas – quando o número de clientes excede o número máximo de clientes suportados pelo servidor PostgreSQL, o PgBouncer ainda é capaz de manter a taxa de transação, enquanto as conexões diretas com o PostgreSQL são abortadas.
No entanto, um pool de conexões mal configurado pode reduzir o desempenho que vimos com a configuração do Pgpool-II aqui. Parte do problema é que usar Pgpool-II doubles o número de processos em execução no mesmo servidor - precisamos execute o Pgpool-II em um servidor separado para obter um bom desempenho. Mas mesmo assim, o PgBouncer consegue fornecer melhor desempenho para esses números relativamente pequenos de clientes.
Além disso, observe que o teste aqui foi realmente criado perfeitamente para o Pgpool-II - já que quando N> 32, o número de clientes e o número de processos filhos eram os mesmos e, portanto, cada reconexão foi garantida para encontrar um processo em cache. Mesmo assim, o PgBouncer era a alternativa mais rápida.
Então, nossos testes indicam que o PgBouncer é a escolha muito melhor para o pool de conexões. Mas é importante lembrar que, embora um pool de conexões seja absolutamente obrigatório para as cargas de trabalho mais realistas, se você ganha mais usando um pool do lado do cliente ou um middleware como o PgBouncer depende do seu aplicativo. Padrões de acesso a dados desempenhariam um papel, assim como as latências envolvidas com base em sua arquitetura. Recomendamos testar sua carga de trabalho em relação a ambos e, em seguida, decidir sobre o melhor curso de ação - não há alternativa melhor para experimentação!
