Usando un “connection pool”

2 comentarios

Cuando la cantidad de usuarios es grande y los recursos del Servidor son pocos puedes utilizar un “connection pool” para que todos esos usuarios puedan estar conectados a pesar de los pocos recursos disponibles.

Esta es una técnica que hace años se utilizó bastante pero que está decayendo porque la memoria y las redes son relativamente baratas entonces suele ser más sencillo y más rápido invertir en hardware para aumentar los recursos del Servidor y de esa manera solucionar el problema.

Aunque claro, eso no siempre es posible, hay muchos casos en que usar un “connection pool” es la mejor alternativa. Por ejemplo si los usuarios que se conectan son miles o millones y lo hacen a través de Internet. Allí, tener un Servidor que pueda manejar esas miles o millones de conexiones puede ser demasiado costoso. Y entonces, un “connection pool” es la solución a los tres problemas típicos:

  1. La cantidad de conexiones que puede manejar el Servidor siempre es finita, es limitada
  2. Cada conexión demora en abrirse y en cerrarse, no es instantánea
  3. Cada conexión consume recursos (memoria) de la computadora donde se encuentra el Servidor

¿Qué es un “connection pool”?

Es una técnica para que un Servidor con pocos recursos pueda manejar muchísimas conexiones. De esta manera se solucionarían los tres problemas ennumerados arriba.

¿Cómo funciona?

Las aplicaciones (Contabilidad, Facturación, Sueldos, Ventas, etc.) envían sus solicitudes al “connection pool” y éste las envía al Servidor.

Lo normal es que las aplicaciones envíen sus solicitudes al Servidor. Pues aquí no ocurre así, sino que ocurre esto:

CONNECTION1

Diagrama 1. Si haces clic en la imagen la verás más grande

El “connection pool” mantiene varias conexiones abiertas permanentemente a la Base de Datos. Cuando una aplicación realiza una solicitud el programa verifica si alguna de esas conexiones está libre. Si lo está, la utiliza. Si no hay conexiones libres entonces realiza una nueva conexión.

Cuando una conexión ha estado inactiva mucho tiempo (digamos, 10 minutos) y es mayor que el número mínimo de conexiones entonces la cierra.

Ejemplo:

Una empresa tiene 1.000 usuarios que se conectan diariamente a su Base de Datos. En promedio cada día 950 de esos usuarios realizan 120 transacciones cada uno, cada una de esas transacciones demorando 100 milisegundos. Los restantes 50 usuarios realizan 40 transacciones diarias, cada una de esas transacciones demorando 900 milisegundos.

Entonces tenemos que:

950 * 120 * 100 / 1000 / 60 / 60 = 3 horas + 0,166666667 * 60= 3 horas y 10 minutos

50 * 40 * 900 / 1000 / 60 / 60 = 0, 50 * 60 = 30 minutos

Tiempo total = 3 horas y 10 minutos más 30 minutos = 3 horas y 40 minutos

El Servidor estuvo encendido durante 8 horas pero solamente estuvo activo 3 horas y 40 minutos.

El “connection pool” se configuró para mantener 50 conexiones abiertas. Si se necesitan más las abre pero cuando esas conexiones adicionales están inactivas durante más de 10 minutos, las cierra.

Entonces, cuando una aplicación envía una solicitud el “connection pool” verifica si hay alguna conexión inactiva. Si la hay, la utiliza. Si no la hay, abre una nueva conexión.

Después que el “connection pool” entregó el resultado de la solicitud a la aplicación no cierra la conexión sino que la deja libre para que pueda ser usada por otra solicitud.

De esta manera hay 50 conexiones abiertas permanentemente y quizás algunas más abiertas temporalmente. Cuando una aplicación realiza una solicitud el “connection pool” verifica si alguna de esas conexiones está inactiva. Si es así la utiliza, ahorrando tiempo y memoria, porque como ya estaba abierta no es necesario abrirla.

¿Cómo conectarse a la Base de Datos?

En este artículo habíamos visto tres formas de establecer conexión a la Base de Datos:

https://firebird21.wordpress.com/2013/12/23/sobre-conexiones-y-desconexiones/

cuando se usa un “connection pool” lo correcto es usar la opción número 3. es decir: abrir_la_conexión, realizar_la_tarea, cerrar_la_conexión

Conclusión:

Cuando los usuarios son muchos y los recursos del Servidor son pocos se puede invertir en hardware para aumentar esos recursos o utilizar un “connection pool”. Este es un programa que se encarga de administrar las conexiones a la Base de Datos. Mantiene siempre una cierta cantidad de conexiones abiertas y así cuando alguna aplicación envía una solicitud trata de usar una de esas conexiones abiertas. Si no es posible porque todas están ocupadas entonces abre una nueva conexión. Cuando una conexión ha estado inactiva durante mucho tiempo, la cierra.

Las aplicaciones no se conectan a la Base de Datos sino que se conectan al “connection pool”, el cual se encarga de enviar las solicitudes al Servidor y de recibir los resultados.

Para que esta técnica funcione las aplicaciones siempre deben abrir_la_conexión, realizar_la_tarea, cerrar_la_conexión porque si mantienen las conexiones abiertas esta técnica no funcionará.

Artículos relacionados:

Sobre conexiones y desconexiones

El índice del blog Firebird21

 

Anuncios

Sobre conexiones y desconexiones

7 comentarios

¿Cuándo conectarse y cuándo desconectarse de la Base de Datos?

Aquí tenemos varias posibilidades, analizaremos lo que implica cada una de ellas:

  1. Conectarse cuando la aplicación (Contabilidad, Facturación, Ventas, Sueldos, etc.) inicia y desconectarse cuando la aplicación finaliza
  2. Conectarse cuando el formulario se inicia y desconectarse cuando finaliza
  3. Conectarse para realizar una tarea y desconectarse cuando la tarea finaliza

¿Cuál elegir?

En general y en casi todos los casos la mejor opción es la número 1. ¿Por qué? porque tener una conexión abierta no puede causarle daño a la Base de Datos y eso de estar abriendo y cerrando conexiones sin necesidad solamente acarreará pérdida de tiempo. Abrir una conexión o cerrar una conexión no es instantáneo, toma unos cuantos milisegundos hacerlo. Puede parecer muy poco pero si lo multiplicas por la cantidad de veces que un usuario lo hace en un día y a ese resultado lo multiplicas por la cantidad de usuarios y a ese resultado lo multiplicas por la cantidad de días laborables del mes puedes encontrarte con muchos minutos o inclusive muchas horas desperdiciadas por estar abriendo y cerrando conexiones sin necesidad.

Pero hay casos en los que sí es conveniente abrir_conexión, realizar_tarea, cerrar_conexión ¿cuáles son esos casos? cuando la señal es débil o es mala o siempre se realiza por Internet. Por ejemplo si alguien está viajando y se conecta al Servidor de la empresa desde su notebook (también llamada laptop) y sufre frecuentes cortes de Internet. O cuando la conexión siempre es a través de Internet (el caso de las aplicaciones “en la nube”).

Pero cuando se trata de una red local que funciona bien no tiene sentido eso de abrir_conexión, realizar_tarea, cerrar_conexión porque ningún beneficio se obtiene de ello y sí perjuicios: por un lado pérdida de tiempo como ya habíamos visto y por el otro que no se podrían usar tablas GTT de conexión, solamente se podrían usar tablas GTT de transacción.

Conclusión:

Si la conexión a la Base de Datos es a través de una red local entonces siempre lo más conveniente es usar la opción 1.

La opción 3 suele ser la más conveniente cuando los cortes de conexión son frecuentes, eso podría suceder cuando alguien está viajando y usando una notebook para conectarse a la Base de Datos que se encuentra en el local de la empresa.

También habría que usar la opción 3. cuando los usuarios siempre o mayormente se conectan por Internet a la Base de Datos.

Lo mejor técnica entonces es que desde tu aplicación el usuario pueda elegir el método de conexión. Aquellos usuarios que lo hacen a través de una red local deberían tener habilitada la opción 1. y aquellos que lo hacen a través de Internet deberían tener habilitada la opción 3. Y siempre deberían tener la posibilidad de cambiarse de la una a la otra.

Artículo relacionado:

El índice del blog Firebird21