Table of Contents
Significado de la agrupación de conexiones
Un grupo de conexiones es una memoria caché de las conexiones de la base de datos que se mantiene para que las conexiones se puedan reutilizar cuando se requieran futuras solicitudes a la base de datos. Los grupos de conexiones se utilizan para mejorar el rendimiento de la ejecución de comandos en una base de datos. Abrir y mantener una conexión de base de datos para cada usuario, especialmente las solicitudes realizadas a una aplicación basada en base de datos dinámica, es costoso y desperdicia recursos. En la agrupación de conexiones, después de que se crea una conexión, se coloca en la agrupación y se vuelve a utilizar para que no sea necesario establecer una nueva conexión.
También puedes definir un número máximo de conexiones que creará un pool, y esto puede ser muy interesante para reducir el número de licencias de base de datos que se necesitan. En un caso como ese, cuando el grupo alcanza el límite y llega una nueva solicitud, esta solicitud no se procesará si una conexión vacante no está disponible antes de un cierto tiempo de espera previamente definido.
La clave para un grupo de conexiones con conexiones de base de datos limitadas es definir el número ideal para este grupo en función del número final de usuarios y la arquitectura de la aplicación. Más sobre esto en el ejemplo a continuación.
El mecanismo de agrupación de conexiones FireDAC
El mecanismo de agrupación de conexiones de FireDAC es bastante fácil de usar y se puede activar configurando solo una propiedad de conexión adicional desde su conexión (Pooled=True).
Por supuesto, la función de agrupación brilla en aplicaciones de subprocesos múltiples, donde se ejecutan múltiples tareas cortas simultáneamente (o casi), y cada una de estas tareas requiere establecer una conexión. Al utilizar la función de sondeo, la conexión ya estará establecida y esperando la tarea, lo que dará como resultado un tiempo de procesamiento mucho más rápido y un menor consumo de recursos.
Para escenarios avanzados, además del parámetro “Pooled”, existen otros tres parámetros que se pueden considerar:
| Parámetro | Parámetro | Ejemplo |
|---|---|---|
| POOL_CleanupTimeout | El tiempo (ms) hasta que FireDAC elimina las conexiones que no se han utilizado durante más tiempo que el tiempo de espera de POOL_ExpireTimeout. El valor predeterminado es 30000 ms (30 segundos). | 3600000 |
| POOL_ExpireTimeout | El tiempo (ms) después del cual la conexión inactiva puede eliminarse del grupo y destruirse. El valor predeterminado es 90000 ms (90 segundos). | 600000 |
| POOL_MaximumItems | El número máximo de conexiones en el grupo. Cuando la aplicación requiere más conexiones, se genera una excepción. El valor predeterminado es 50. | 100 |
FireDAC le permite usar conexiones “persistentes” (almacenadas en el archivo .ini de FireDAC), conexiones “privadas” (disponibles en la memoria para una aplicación) y “temporales” (no almacenadas, no nombradas ni administradas por FDManager). Puede leer más sobre cómo definir y establecer una conexión (con o sin un grupo) siguiendo la documentación a continuación:
- https://docwiki.embarcadero.com/RADStudio/en/Multithreading_(FireDAC)
- https://docwiki.embarcadero.com/RADStudio/en/Defining_Connection_(FireDAC)
Agrupación de conexiones con servidor RAD (EMS)
Para cualquier aplicación back-end seria, incluido RAD Server, es casi obligatorio tener algún mecanismo de agrupación a medida que crece la cantidad de llamadas a su aplicación. Nuestro ejemplo demostrará que usar una conexión “Privada” definida a través de FDManager. Por supuesto, también puede reutilizar las conexiones ya definidas en el archivo .ini de FireDAC, o incluso cargar el archivo .ini a través de FDManager y modificarlo agregando los parámetros de agrupación de conexiones que son específicos para su aplicación de servidor, pero no tan útiles en una aplicación de escritorio.
Nuestra aplicación de demostración se creó con el Asistente del servidor RAD ( https://docwiki.embarcadero.com/RADStudio/en/Creating_a_RAD_Server_Package ) y utilizando el EMSDataSetResource recientemente agregado ( https://docwiki.embarcadero.com/RADStudio/en/ Using_RAD_Server_Components y https://blogs.embarcadero.com/using-emsdatasetresource-component-with-rad-server/ ), pero lo mismo se aplica a los extremos del servidor RAD definidos explícitamente.
Es importante tener en cuenta que solo puede existir una instancia de FDManager por instancia de aplicación, por lo que notará que FDManager se crea en la sección de inicialización de nuestro recurso EMS, así:
Ejecutando una prueba de esfuerzo con nuestro proyecto de demostración
El siguiente video muestra el mecanismo de agrupación que se está probando con JMeter con una carga total de 100 usuarios:
Como sugerencia adicional, si su aplicación RAD Server está compuesta por varios paquetes, aún puede usar el mecanismo de agrupación. Todo lo que necesita hacer es crear un recurso de servidor RAD que solo defina la configuración de agrupación de conexiones mediante FDManager y asegúrese de cargar este recurso como el primero en su entorno de implementación.
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
