En nuestras publicaciones anteriores de esta serie, hablamos extensamente sobre el uso de PgBouncer y Pgpool-II, la arquitectura del grupo de conexiones y las ventajas y desventajas de aprovechar una para su implementación de PostgreSQL. En nuestra publicación final, los pondremos cara a cara en una comparación detallada de funciones y compararemos los resultados del rendimiento de PgBouncer frente a Pgpool-II para su alojamiento PostgreSQL.
¿Cómo se comparan las características?
Empecemos comparando las funciones de PgBouncer con las de Pgpool-II:
PgBouncer | Pgpool-II | |
|---|---|---|
| Consumo de recursos | Utiliza un solo proceso que lo hace muy ligero. PgBouncer garantiza una pequeña huella de memoria, incluso cuando se trata de grandes conjuntos de datos. ¡Ganador! | Si requerimos N conexiones paralelas, esto bifurca N procesos secundarios. De forma predeterminada, hay 32 procesos secundarios que están bifurcados. |
| ¿Cuándo se reutilizan las conexiones? | PgBouncer define un grupo por combinación de usuario+base de datos. Esto se comparte entre todos los clientes, por lo que una conexión agrupada está disponible para todos los clientes. ¡Ganador! | Pgpool-II define un proceso por proceso secundario. No podemos controlar a qué proceso secundario se conecta un cliente. Un cliente se beneficia de una conexión agrupada solo si se conecta a un hijo que previamente sirvió una conexión para esta combinación de base de datos+usuario. |
| Modos de agrupación | PgBouncer admite tres modos diferentes:sesión (conexión devuelta al grupo cuando el cliente se desconecta), transacción (devuelta al grupo cuando el cliente confirma o revierte) o declaración ( la conexión volvió al grupo después de la ejecución de cada instrucción). ¡Ganador! | Pgpool-II solo admite el modo de agrupación de sesiones; la eficacia de la agrupación depende del buen comportamiento de los clientes. |
| Alta disponibilidad | No compatible. | La alta disponibilidad de PostgreSQL es compatible con los procesos de vigilancia integrados de Pgpool-II. ¡Ganador! |
| Equilibrio de carga | No compatible:PgBouncer recomienda el uso de HAProxy para alta disponibilidad y equilibrio de carga. | Admite balanceo de carga automático:es incluso lo suficientemente inteligente como para redirigir las solicitudes de lectura a los dispositivos de reserva y las escrituras a los maestros. ¡Ganador! |
| Compatibilidad con varios clústeres | Una instancia de PgBouncer puede enfrentar varios clústeres de PostgreSQL (un nodo o conjuntos de réplicas). Esto puede reducir el costo del middleware cuando se usan varios clústeres de PostgreSQL. ¡Ganador! (Nota:esta ventaja es solo para escenarios específicos) | Pgpool-II no es compatible con varios clústeres. |
| Control de conexión | PgBouncer permite limitar las conexiones por grupo, por base de datos, por usuario o por cliente. ¡Ganador! | Pgpool-II solo permite limitar el número total de conexiones. |
| Cola de conexión | PgBouncer admite la cola en el nivel de la aplicación (es decir, PgBouncer mantiene la cola). ¡Ganador! | Pgpool-II admite colas a nivel de kernel; esto puede hacer que pg_bench en CentOS 6 se congele. |
| Autenticación | La autenticación PassThrough es compatible con PgBouncer. ¡Ganador! | Pgpool-II no es compatible con la autenticación PassThrough:los usuarios y sus contraseñas encriptadas md5 deben incluirse en un archivo y actualizarse manualmente cada vez que un usuario actualiza su contraseña. Pgpool-II admite la autenticación sin contraseña a través de certificados PAM o SSL. Sin embargo, estos deben configurarse fuera del sistema PostgreSQL, mientras que PgBouncer puede descargar esto al servidor PostgreSQL. |
| Administración | PgBouncer proporciona una base de datos virtual que informa varias estadísticas útiles. | Pgpool-II proporciona una interfaz de administración detallada, incluida una GUI. ¡Ganador! |
| Autenticación basada en host | Compatible. ¡Atado! | Compatible. ¡Atado! |
| Compatibilidad con SSL | Soporte completo. ¡Atado! | Soporte completo. ¡Atado! |
| Replicación lógica | No compatible con PgBouncer. ¡Atado! | Soportado a través de Pgpool-II, pero esto se hace enviando consultas de escritura a todos los nodos, y generalmente no se recomienda. ¡Atado! |
| Licencia | ISC:muy permisivo, básicamente permite todo uso. ¡Atado! | Licencia personalizada:igualmente permisiva. ¡Atado! |
La conclusión:Pgpool-II es una gran herramienta si necesita equilibrio de carga y alta disponibilidad. La agrupación de conexiones es casi una bonificación que obtienes. PgBouncer solo hace una cosa, pero lo hace muy bien. Si el objetivo es limitar el número de conexiones y reducir el consumo de recursos, PgBouncer gana sin dudas.
También está perfectamente bien usar tanto PgBouncer como Pgpool-II en una cadena; puede tener un PgBouncer para proporcionar agrupación de conexiones, que se comunica con un Instancia de Pgpool-II que brinda alta disponibilidad y balanceo de carga. ¡Esto te da lo mejor de ambos mundos!
Pruebas de rendimiento
Si bien PgBouncer puede parecer la mejor opción en teoría, la teoría a menudo puede ser engañosa. Por lo tanto, enfrentamos a los dos agrupadores de conexiones cara a cara, utilizando la herramienta pgbench estándar, para ver cuál proporciona un mejor rendimiento de transacciones por segundo a través de una prueba comparativa. Por si acaso, también realizamos las mismas pruebas sin un agrupador de conexiones.
Condiciones de prueba
Todas las pruebas comparativas de PostgreSQL se ejecutaron bajo las siguientes condiciones:
- Pgbench inicializado usando un factor de escala de 100.
- Se deshabilitó el aspirado automático en la instancia de PostgreSQL para evitar interferencias.
- Ninguna otra carga de trabajo estaba funcionando en ese momento.
- Utilizó el script pgbench predeterminado para ejecutar las pruebas.
- Configuración predeterminada utilizada para PgBouncer y Pgpool-II, excepto max_children *. Todos los límites de PostgreSQL también se establecieron en sus valores predeterminados.
- Todas las pruebas se ejecutaron como un solo subproceso, en una máquina de 2 núcleos y una sola CPU, durante 5 minutos.
- Obligó a pgbench a crear una nueva conexión para cada transacción usando la opción -C. ¡Esto emula las cargas de trabajo de las aplicaciones web modernas y es la única razón para usar un agrupador!
Ejecutamos cada iteración durante 5 minutos para garantizar que se promediara cualquier ruido. Así es como se instaló el middleware:
- Para PgBouncer, lo instalamos en la misma caja que los servidores PostgreSQL. Esta es la configuración que usamos en nuestros clústeres de PostgreSQL administrados. Dado que PgBouncer es un proceso muy liviano, instalarlo en la caja no tiene impacto en el rendimiento general.
- Para Pgpool-II, probamos cuando la instancia de Pgpool-II se instaló en la misma máquina que PostgreSQL (en la columna del cuadro) y cuando se instaló en una máquina diferente (columna fuera de cuadro). Como era de esperar, el rendimiento es mucho mejor cuando Pgpool-II está listo para usar, ya que no tiene que competir con el servidor PostgreSQL por los recursos.
Referencia de rendimiento
Estos son los resultados de las transacciones por segundo (TPS) para cada escenario en un rango de cantidad de clientes:
| Número de clientes | Sin agrupación | PgBouncer | Pgpool-II (en la caja) | Pgpool-II (fuera de la caja) |
|---|---|---|---|---|
| 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 | Conexiones canceladas. | 26,93 | Conexiones abortadas cuando max-children> 200, pgbench se bloquea en el valor max-child si <=100. | Conexiones abortadas cuando max-children> 200, pgbench se bloquea en el valor max-child si <=100. |
Pgpool-II se cuelga cuando pg_bench se ejecuta con más clientes que max_children. Por lo tanto, aumentamos max_children para que coincida con la cantidad de clientes para cada ejecución de prueba.
Si calculamos el porcentaje de aumento en TPS cuando usamos un agrupador de conexiones, esto es lo que obtenemos:
| Número de clientes | PgBouncer | Pgpool-II (en caja) | Pgpool-II (fuera de caja) |
|---|---|---|---|
| 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 mejora =(con pooler – sin)/sin
Palabras finales
Como puede ver en los resultados de la prueba de rendimiento, una conexión bien configurada y un agrupador de conexiones adecuado pueden aumentar drásticamente el rendimiento de la transacción, incluso con una cantidad bastante pequeña de clientes. Los agrupadores de conexiones son especialmente útiles por su compatibilidad con las colas:cuando la cantidad de clientes excede el número máximo de clientes admitidos por el servidor PostgreSQL, PgBouncer aún puede mantener la tasa de transacciones, mientras que las conexiones directas a PostgreSQL se cancelan.
Sin embargo, un agrupador de conexiones mal configurado puede en realidad reducir el rendimiento como lo vimos con la configuración de Pgpool-II aquí. Parte del problema es usar Pgpool-II dobles la cantidad de procesos que se ejecutan en el mismo servidor; debemos ejecute Pgpool-II en un servidor separado para obtener un buen rendimiento. Pero incluso entonces, PgBouncer logra brindar un mejor rendimiento para este número relativamente pequeño de clientes.
Además, tenga en cuenta que la prueba aquí en realidad fue perfectamente diseñada para Pgpool-II, ya que cuando N> 32, la cantidad de clientes y la cantidad de procesos secundarios fue la misma y, por lo tanto, cada reconexión estaba garantizada para encontrar un proceso en caché. Incluso entonces, PgBouncer era la alternativa más rápida.
Por lo tanto, nuestras pruebas indican que PgBouncer es la mejor opción para la agrupación de conexiones. Sin embargo, es importante recordar que, si bien un agrupador de conexiones es absolutamente obligatorio para la mayoría de las cargas de trabajo realistas, si obtiene más usando un grupo del lado del cliente o un middleware como PgBouncer depende de su aplicación. Los patrones de acceso a los datos desempeñarían un papel, al igual que las latencias involucradas en función de su arquitectura. Recomendamos probar su carga de trabajo con ambos y luego decidir cuál es el mejor curso de acción:¡no hay mejor alternativa que la experimentación!
