¿Cómo configura su grupo de conexiones?

Question

¿Cuál es la mejor manera de configurar su grupo con respecto a: -

1. ¿Cuándo creas conexiones?
2. ¿Cuándo cierras las conexiones y las cerrarías todas?
3. ¿Pruebas que las conexiones siguen siendo buenas? ¿Cuándo y cómo?
4. ¿Cómo calculas un buen número para la cantidad máxima de conexiones?
5. ¿Qué tipo de monitoreo tiene implementado para garantizar que los usuarios del grupo se comporten bien? ¿Puedes evitar que un código defectuoso elimine todo?
6. ¿Ha escrito su propio grupo o ha utilizado una biblioteca de terceros?

Creo que esta es una pregunta agnóstica, pero comenta acerca de las "características". de bases de datos / idiomas particulares son bienvenidos. Por ejemplo, puede ser más lento o más costoso conectarse en algunas bases de datos que en otras.

Para aclarar, no tengo la intención de escribir un grupo desde cero, esta pregunta es más acerca de cómo configurar una biblioteca existente que agrupa.

Answer 1

Escribí un grupo de conexiones para la base de datos en Java cuando era solo un patrón de diseño y no una biblioteca común. Ahora uso el integrado en Tomcat.

Utilicé un hilo para monitorear varios aspectos del grupo y varios parámetros para controlar su comportamiento ...

1. minimumInPool = " 3 " ... Estos tres primeros se crean en el lanzamiento. Nunca se permite que el grupo caiga por debajo de tres.
2. maximumIdleTimeBeforeRemoval = " 60 " ... Si una conexión está inactiva durante una hora, suéltela y cree una nueva. El tiempo de inactividad probablemente significa que solo hay un mínimo de tres en el grupo.
3. maximumInUseTimeBeforeRemoval = " 30 " ... Si una conexión determinada se ha desprotegido durante más de 30 minutos, es probable que algo esté mal. Recordarlo y eliminar la conexión.
4. maximumTimeBeforeRemoval = " 60 " ... Elimínelo si tiene más de 60 minutos.
5. maximumUsageBeforeRemoval = " 1000 " ... Elimínelo si se ha extraído más de 1000 veces.
6. monitorInterval = " 15 " ... Compruebe los parámetros anteriores cada 15 minutos.

Esto me sirvió muy bien durante un par de años. Lo más alto que vi en la piscina fue 151 conexiones durante un vistazo salvaje. Por lo general, la piscina era de aproximadamente una docena durante el uso intensivo y estaba inactiva al mínimo tres en las primeras horas de la mañana.

Utilicé los controladores delgados JDBC de Oracle y me conecté a una base de datos Oracle.

Answer 2

Aquí está la justificación que utilicé para una implementación reciente.

1. Tenga dos tipos de conexiones en su grupo de conexiones. El primero está listo, lo que significa abierto pero no en uso por un cliente. El segundo está activo, es decir, en uso por un cliente.

2. Haga que su agrupación de conexiones mantenga un pequeño número de conexiones listas, se puede ajustar un mínimo de N y un máximo de M. N dependiendo de la velocidad máxima a la que sus clientes soliciten conexiones. Si el número de conexiones listas alguna vez cae a cero, necesita un N. más grande. Si el número es constantemente alto (digamos por encima de 10), necesita un N. más bajo

3. Cuando un cliente quiera una conexión, dele una de las listas (haciéndola activa), luego abra inmediatamente una nueva si ahora hay menos de N lista (pero no haga que el cliente espere esto para completar, o perderá la ventaja de la agrupación). Esto asegura que siempre habrá al menos N conexiones listas. Si ninguno está listo cuando el cliente quiere uno, tendrá que esperar mientras crea uno nuevo.

4. Cuando el cliente termina con una conexión activa, devuélvala al estado preparado si hay menos de M conexiones listas. De lo contrario, ciérrelo. Esto evita que tenga más de M conexiones listas.

5. Recicle periódicamente las conexiones listas para evitar conexiones obsoletas. Si hay más de N conexiones listas, simplemente cierre la conexión más antigua. De lo contrario, ciérrelo y vuelva a abrir otro.

Esto tiene la ventaja de tener suficientes conexiones juveniles listas y disponibles en su grupo de conexiones sin sobrecargar el servidor.

Answer 3

Jakarta Commons DBCP ya hace todas las cosas que usted enumeró:

• crea conexiones según sea necesario y las administra en un grupo
• puede cerrar conexiones si no se han utilizado durante un cierto período de tiempo
• puede ejecutar una consulta en una conexión antes de distribuirla, y si hay un error, la conexión se descarta y se crea una nueva. Las conexiones también se pueden probar periódicamente mientras está inactivo.
• puede establecer un límite en las conexiones que se crearán y también en el número mínimo de conexiones para tener listas. El límite, por supuesto, depende mucho de su aplicación.
• No sé cómo, pero DBCP sabe cuándo no se está cerrando una conexión y la cierra por usted, lanzando una excepción para que sepa lo que sucedió cuando vea su registro.
• DBCP tiene un parámetro de tiempo de espera que es muy útil. Si se están utilizando todas las conexiones en el grupo, esperará ese período de tiempo para que se devuelva una conexión al grupo y si no hay ninguna disponible cuando se alcanza el límite, obtendrá un error.

Puede ajustar su grupo jugando con el número mínimo de conexiones, el número máximo de conexiones que se crearán y el tiempo de espera. Un tiempo de espera más largo le permitirá tener un límite inferior de conexiones, mientras que un tiempo de espera más corto probablemente requerirá un número mayor. Esto depende en gran medida de lo que haga su aplicación y de cómo use las conexiones.

Answer 4

Estoy de acuerdo con matt b en que no debemos reinventar la rueda.

Sin embargo, el uso de Commons DBCP es discutible basado en las respuestas de esto y esto preguntas. Hay mejores alternativas mencionadas allí como c3po o proxool .

O puede usar un mecanismo de agrupación de conexiones dependiente de rdbms.

Answer 5

No estoy seguro de cuál es el contexto en el que está utilizando sus conexiones, pero puedo compartir lo que parece funcionar para mí.

Utilizo el servidor SQL como mi back-end y utilizo una combinación de almacenamiento en caché para obtener un mejor rendimiento. Mi práctica es mantener la conexión abierta solo si realmente la necesito y no agrupar las conexiones para que se limpien de inmediato y pueda ver en el Monitor de actividad de SQL exactamente qué está activo y qué no. Cada conexión ocupa memoria, por lo que es bueno mantenerla en un rugido sordo cuando no se necesitan.

Antes de responder la pregunta de abrir y cerrar la conexión, permítanme decir que el almacenamiento en caché es realmente importante. Sacar un objeto del caché te ahorrará un montón de tiempo. En algunas de mis aplicaciones asp.net cuando el almacenamiento en caché está activado en desarrollo, descubrí que apenas puedo medir la latencia, mientras que con una llamada de DB puede tomar de 15 ms a 45 ms para completar la llamada y esto ni siquiera está considerando otra latencia factores o carga. El otro método que utilizo es una buena estructura de objetos para mis datos, por lo que solo hago una actualización de la base de datos si algo cambia. He implementado algunos métodos en mi objeto o me aseguro de que estoy haciendo el menor IO posible.

Dicho esto, todos sabemos que necesitamos acceder y escribir en nuestra base de datos en algún momento, así que sigo dos principios:

1. Mantenga las puertas y ventanas cerradas para ahorrar energía. Una conexión abierta en un lugar significa que no está disponible en otro (o la memoria y otros recursos son más limitados). Hemos desactivado la agrupación porque ha resultado en un mejor rendimiento para nosotros.

2. Hago tanto por lote o de una vez como puedo cuando la conexión está abierta. Esto es un poco más complicado, así que déjame explicarte.

   • un método que he usado es pasar mis objetos de conexión por la tubería para que todos los objetos puedan usar un objeto de conexión. Esto da como resultado una conexión abierta y cerrada en lugar de tal vez 10 o más, dependiendo de su aplicación. Un buen ejemplo de esto es uno de nuestros modelos de compra que aprovecha el poder del servidor SQL para recopilar estadísticas y analizar patrones de pedidos complicados. No tiene sentido seguir abriendo y cerrando la conexión cuando realiza una búsqueda de 200K + DB o lo que sea para las aplicaciones. La otra parte de esto es que cuando uso el objeto trato de agrupar mis actualizaciones para reducir el tiempo que mantengo la conexión abierta. Por lo tanto, al realizar una identificación de ámbito en la llamada de inserción, me encargaré tanto de mi inserción como de la búsqueda de la ID única para agregar a mi objeto antes de almacenarlo en caché. En el día en que estaba desarrollando aplicaciones asp por primera vez, en realidad abría la conexión tan pronto como la página comenzaba a cargarse y luego la cerraba. Ya no recomiendo hacerlo. Hoy en día hay un gran beneficio para este tipo de abstracciones y capas que recomendaría que cualquier programador novato preste especial atención.

Mis dos centavos:

¡Guarda en caché tus datos! Caché tus datos! Caché tus datos! ¡Haga el menor acceso posible a la base de datos cuando no pueda almacenar en caché y luego guarde en caché sus datos!

Answer 6

¿Por qué reinventar la rueda?

Alguien probablemente ya haya resuelto el problema, y ??mejor.

Si estás en el mundo de Java, puedes usar Commons DBCP .