Nei nostri post precedenti di questa serie, abbiamo parlato a lungo dell'utilizzo di PgBouncer e Pgpool-II, dell'architettura del pool di connessioni e dei pro e contro di sfruttarne uno per la tua distribuzione PostgreSQL. Nel nostro post finale, li metteremo testa a testa in un confronto dettagliato delle funzionalità e confronteremo i risultati delle prestazioni di PgBouncer e Pgpool-II per il tuo hosting PostgreSQL!
Come si accumulano le funzionalità?
Iniziamo confrontando le funzionalità di PgBouncer e di Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Consumo di risorse | Utilizza un solo processo che lo rende molto leggero. PgBouncer garantisce un footprint di memoria ridotto, anche quando si tratta di set di dati di grandi dimensioni. Vincitore! | Se abbiamo bisogno di N connessioni parallele, questo fork N processi figlio. Per impostazione predefinita, ci sono 32 processi figlio che vengono biforcati. |
| Quando vengono riutilizzate le connessioni? | PgBouncer definisce un pool per combinazione utente+database. Questo è condiviso tra tutti i client, quindi una connessione in pool è disponibile per tutti i client. Vincitore! | Pgpool-II definisce un processo per processo figlio. Non possiamo controllare a quale processo figlio si connette un client. Un client beneficia di una connessione in pool solo se si connette a un figlio che ha precedentemente servito una connessione per questa combinazione database+utente. |
| Modalità di raggruppamento | PgBouncer supporta tre diverse modalità:sessione (connessione restituita al pool quando il client si disconnette), transazione (restituita al pool quando il client esegue il commit o il rollback) o istruzione ( connessione restituita al pool dopo l'esecuzione di ogni istruzione). Vincitore! | Pgpool-II supporta solo la modalità di pooling delle sessioni:l'efficacia del pooling dipende dal buon comportamento dei clienti. |
| Alta disponibilità | Non supportato. | L'elevata disponibilità di PostgreSQL è supportata tramite i processi di watcher integrati di Pgpool-II. Vincitore! |
| Bilanciamento del carico | Non supportato:PgBouncer consiglia l'uso di HAProxy per l'elevata disponibilità e il bilanciamento del carico. | Supporta il bilanciamento del carico automatico - è persino abbastanza intelligente da reindirizzare le richieste di lettura in standby e scrive ai master. Vincitore! |
| Supporto multi-cluster | Un'istanza di PgBouncer può gestire diversi cluster PostgreSQL (un nodo o set di repliche). Ciò può ridurre il costo del middleware quando si utilizzano più cluster PostgreSQL. Vincitore! (Nota:questo vantaggio è solo per scenari specifici) | Pgpool-II non ha il supporto multi-cluster. |
| Controllo della connessione | PgBouncer consente di limitare le connessioni per pool, per database, per utente o per client. Vincitore! | Pgpool-II consente di limitare solo il numero complessivo di connessioni. |
| Coda di connessione | PgBouncer supporta l'accodamento a livello di applicazione (ovvero PgBouncer mantiene la coda). Vincitore! | Pgpool-II supporta l'accodamento a livello di kernel:ciò può causare il blocco di pg_bench su CentOS 6. |
| Autenticazione | L'autenticazione pass-through è supportata tramite PgBouncer. Vincitore! | Pgpool-II non supporta l'autenticazione pass-through:gli utenti e le loro password crittografate md5 devono essere elencate in un file e aggiornate manualmente ogni volta che un utente aggiorna la loro password.Pgpool-II supporta l'autenticazione senza password tramite certificati PAM o SSL. Tuttavia, questi devono essere impostati al di fuori del sistema PostgreSQL, mentre PgBouncer può scaricarlo sul server PostgreSQL. |
| Amministrazione | PgBouncer fornisce un database virtuale che riporta varie statistiche utili. | Pgpool-II fornisce un'interfaccia di amministrazione dettagliata, inclusa una GUI. Vincitore! |
| Autenticazione basata sull'host | Supportato. Legato! | Supportato. Legato! |
| Supporto SSL | Supporto completo. Legato! | Supporto completo. Legato! |
| Replica logica | Non supportato tramite PgBouncer. Legato! | Supportato tramite Pgpool-II, ma ciò avviene inviando le query di scrittura a tutti i nodi e generalmente non è consigliato. Legato! |
| Licenza | ISC – molto permissivo, sostanzialmente consente qualsiasi utilizzo. Legato! | Licenza personalizzata – ugualmente permissiva. Legato! |
In conclusione:Pgpool-II è un ottimo strumento se hai bisogno di bilanciamento del carico e disponibilità elevata. Il pool di connessioni è quasi un bonus che ottieni insieme. PgBouncer fa solo una cosa, ma lo fa davvero bene. Se l'obiettivo è limitare il numero di connessioni e ridurre il consumo di risorse, PgBouncer vince senza dubbio.
Va benissimo anche usare sia PgBouncer che Pgpool-II in una catena:puoi avere un PgBouncer per fornire un pool di connessioni, che parla con un Istanza Pgpool-II che fornisce disponibilità elevata e bilanciamento del carico. Questo ti dà il meglio di entrambi i mondi!
Test delle prestazioni
Sebbene PgBouncer possa sembrare l'opzione migliore in teoria, la teoria può spesso essere fuorviante. Quindi, abbiamo confrontato i due pool di connessioni testa a testa, utilizzando lo strumento standard pgbench, per vedere quale fornisce una migliore velocità effettiva di transazioni al secondo attraverso un test di benchmark. Per buona misura, abbiamo eseguito gli stessi test anche senza un pool di connessioni.
Condizioni di test
Tutti i test di benchmark di PostgreSQL sono stati eseguiti nelle seguenti condizioni:
- Pgbench inizializzato utilizzando un fattore di scala di 100.
- Disattivato l'auto-vacuum nell'istanza PostgreSQL per prevenire interferenze.
- Nessun altro carico di lavoro funzionava in quel momento.
- Utilizzato lo script pgbench predefinito per eseguire i test.
- Impostazioni predefinite utilizzate sia per PgBouncer che per Pgpool-II, tranne max_children *. Anche tutti i limiti di PostgreSQL sono stati impostati sui valori predefiniti.
- Tutti i test sono stati eseguiti come thread singolo, su una macchina a 2 core con CPU singola, per una durata di 5 minuti.
- Pgbench forzato a creare una nuova connessione per ogni transazione utilizzando l'opzione -C. Questo emula i moderni carichi di lavoro delle applicazioni web ed è l'unico motivo per usare un pooler!
Abbiamo eseguito ogni iterazione per 5 minuti per garantire una media del rumore. Ecco come è stato installato il middleware:
- Per PgBouncer, l'abbiamo installato sulla stessa scatola dei server PostgreSQL. Questa è la configurazione che utilizziamo nei nostri cluster PostgreSQL gestiti. Poiché PgBouncer è un processo molto leggero, installarlo sulla scatola non ha alcun impatto sulle prestazioni complessive.
- Per Pgpool-II, abbiamo testato sia quando l'istanza Pgpool-II è stata installata sulla stessa macchina di PostgreSQL (sulla colonna box), sia quando è stata installata su una macchina diversa (colonna fuori casella). Come previsto, le prestazioni sono molto migliori quando Pgpool-II è pronto all'uso in quanto non deve competere con il server PostgreSQL per le risorse.
Parametro di throughput
Ecco i risultati delle transazioni al secondo (TPS) per ogni scenario in un intervallo di numero di clienti:
| Numero di clienti | Senza pool | PgBouncer | Pgpool-II (sulla scatola) | Pgpool-II (fuori scatola) |
|---|---|---|---|---|
| 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 | Connessioni interrotte. | 26.93 | Connessioni interrotte quando max-children> 200, pgbench si blocca al valore max-children se <=100. | Connessioni interrotte quando max-children> 200, pgbench si blocca al valore max-children se <=100. |
Pgpool-II si blocca quando pg_bench viene eseguito con più client di max_children. Quindi, abbiamo aumentato max_children in modo che corrisponda al numero di client per ogni esecuzione di test.
Se calcoliamo l'aumento percentuale di TPS quando utilizziamo un pool di connessioni, ecco cosa otteniamo:
| Numero di clienti | PgBouncer | Pgpool-II (sulla scatola) | 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 di miglioramento =(con pooler – senza)/senza
Le ultime parole
Come puoi vedere dai risultati del test delle prestazioni, una connessione ben configurata e un pool di connessioni adatto possono aumentare drasticamente il throughput delle transazioni, anche con un numero piuttosto ridotto di client. I pool di connessioni sono particolarmente utili per il supporto delle code:quando il numero di client supera il numero massimo di client supportati dal server PostgreSQL, PgBouncer è ancora in grado di mantenere la velocità di transazione, mentre le connessioni dirette a PostgreSQL vengono interrotte.
Tuttavia, un pool di connessioni mal configurato può effettivamente ridurre le prestazioni come abbiamo visto con la configurazione Pgpool-II qui. Parte del problema è che l'utilizzo di Pgpool-II doppio il numero di processi in esecuzione sullo stesso server - dobbiamo eseguire Pgpool-II su un server separato per ottenere una buona prestazione. Ma anche in questo caso, PgBouncer riesce a fornire prestazioni migliori per questo numero relativamente piccolo di clienti.
Inoltre, nota che il test qui è stato effettivamente realizzato perfettamente per Pgpool-II, poiché quando N> 32, il numero di client e il numero di processi figlio erano gli stessi e, quindi, ogni riconnessione era garantita per trovare un processo memorizzato nella cache. Anche allora, PgBouncer era l'alternativa più veloce.
Quindi, i nostri test indicano che PgBouncer è la scelta migliore per il pool di connessioni. Tuttavia, è importante ricordare che mentre un pool di connessioni è assolutamente obbligatorio per i carichi di lavoro più realistici, se guadagni di più utilizzando un pool lato client o un middleware come PgBouncer dipende dalla tua applicazione. I modelli di accesso ai dati avrebbero un ruolo, così come le latenze coinvolte in base alla tua architettura. Ti consigliamo di testare il tuo carico di lavoro con entrambi, quindi decidere la migliore linea d'azione:non c'è alternativa migliore alla sperimentazione!
