Además de ahorrar la sobrecarga de conexión y desconexión donde esto se hace en cada solicitud, un agrupador de conexiones puede canalizar una gran cantidad de conexiones de clientes a una pequeña cantidad de conexiones de bases de datos reales. En PostgreSQL, la cantidad óptima de conexiones de bases de datos activas suele estar alrededor de ((2 * core_count) + efectiva_spindle_count) . Por encima de este número, tanto el rendimiento como la latencia empeoran.
A veces, la gente dirá "Quiero admitir 2000 usuarios, con un tiempo de respuesta rápido". Está bastante garantizado que si intenta hacer eso con 2000 conexiones de base de datos reales, el rendimiento será horrible. Si tiene una máquina con cuatro procesadores de cuatro núcleos y el conjunto de datos activo está completamente almacenado en caché, verá un rendimiento mucho mejor para esos 2000 usuarios al canalizar las solicitudes a través de unas 35 conexiones de base de datos.
Para entender por qué eso es cierto, este experimento mental debería ayudar. Considere una máquina de servidor de base de datos hipotética con un solo recurso para compartir:un solo núcleo. Este núcleo dividirá el tiempo por igual entre todas las solicitudes simultáneas sin sobrecarga. Digamos que llegan 100 solicitudes al mismo tiempo, cada una de las cuales necesita un segundo de tiempo de CPU. El núcleo funciona en todos ellos, dividiendo el tiempo entre ellos hasta que todos terminan 100 segundos después. Ahora considere lo que sucede si coloca un grupo de conexiones al frente que aceptará 100 conexiones de clientes pero realiza solo una solicitud a la vez al servidor de la base de datos, colocando en una cola cualquier solicitud que llegue mientras la conexión está ocupada. Ahora, cuando llegan 100 solicitudes al mismo tiempo, un cliente obtiene una respuesta en 1 segundo; otro recibe una respuesta en 2 segundos y el último cliente obtiene una respuesta en 100 segundos. Nadie tuvo que esperar más para obtener una respuesta, el rendimiento es el mismo, pero la latencia promedio es de 50,5 segundos en lugar de 100 segundos.
Un servidor de base de datos real tiene más recursos que se pueden usar en paralelo, pero se aplica el mismo principio, una vez que están saturados, solo daña las cosas al agregar más solicitudes de base de datos simultáneas. En realidad, es peor que el ejemplo, porque con más tareas, tiene más cambios de tareas, mayor contención de bloqueos y caché, contención de línea de caché L2 y L3, y muchos otros problemas que reducen tanto el rendimiento como la latencia. Además de eso, mientras que un alto work_mem La configuración puede ayudar a una consulta de varias maneras, esa configuración es el límite por nodo del plan para cada conexión , por lo que con una gran cantidad de conexiones, debe dejar esto muy pequeño para evitar vaciar la caché o incluso provocar un intercambio, lo que conduce a planes más lentos o cosas como tablas hash que se derraman en el disco.
Algunos productos de bases de datos construyen efectivamente un conjunto de conexiones en el servidor, pero la comunidad de PostgreSQL ha tomado la posición de que dado que el mejor conjunto de conexiones se realiza más cerca del software del cliente, dejarán que los usuarios administren esto. La mayoría de los agrupadores tendrán alguna forma de limitar las conexiones de la base de datos a un número fijo, mientras permiten más solicitudes de clientes concurrentes que eso, poniéndolas en cola según sea necesario. Esto es lo que quiere, y debe hacerse en un transaccional base, no por declaración o conexión.
