Número óptimo de conexiones en el grupo de conexiones

Question

Actualmente estamos usando 4 cpu windows box con 8gb RAM con MySQL 5.x instalado en la misma caja. Estamos utilizando el servidor de aplicaciones Weblogic para nuestra aplicación. Estamos apuntando a 200 usuarios concurrentes para nuestra aplicación (obviamente no para el mismo módulo / pantalla). Entonces, ¿cuál es el número óptimo de conexiones que debemos configurar en el grupo de conexiones (número mínimo y máximo) (Estamos utilizando el mecanismo de agrupación de conexiones de weblogic AS)?

Answer 1

Hay una respuesta muy simple a esta pregunta:

El número de conexiones en el grupo de conexiones debe ser igual al número de hilos de ejecución configurados en WebLogic .

La razón es muy simple: si el número de conexiones es menor que el número de subprocesos, parte del subproceso puede estar esperando una conexión, lo que hace que el grupo de conexiones sea un cuello de botella. Por lo tanto, debe ser igual al menos al número de subprocesos del ejecutivo (tamaño del grupo de subprocesos).

Answer 2

¿Realmente quisiste decir 200 usuarios concurrentes o solo 200 usuarios conectados? En la mayoría de los casos, un usuario del navegador no podrá hacer más de 1 solicitud de página por segundo. Entonces, 200 usuarios se traducen en 200 transacciones por segundo. Ese es un número bastante alto para la mayoría de las aplicaciones.

Independientemente, como ejemplo, vamos con 200 transacciones por segundo. Digamos que cada front-end (navegador) tx tarda 0.5 segundos en completarse y de los 0.5 segundos, 0.25 se gastan en la base de datos. Por lo tanto, necesitaría 0.5 * 200, o 100 conexiones en el grupo de anuncios de WebLogic y 0.25 * 200 = 50 conexiones en el grupo de conexiones de base de datos.

Para estar seguro, establecería el tamaño máximo del grupo de subprocesos en al menos un 25% más grande de lo que espera permitir picos en la carga. Los mínimos pueden ser una pequeña fracción del máximo, pero la desventaja es que podría tomar más tiempo para algunos usuarios porque habría que crear una nueva conexión. En este caso, 50 a 100 conexiones no son tantas para un DB, por lo que probablemente sea un buen número inicial.

Tenga en cuenta que para determinar cuáles son los tiempos promedio de respuesta de las transacciones, junto con el tiempo promedio de consulta de la base de datos, tendrá que hacer una prueba de rendimiento porque sus tiempos de carga probablemente no sean los tiempos que ve. con un solo usuario.

Answer 3

El tamaño del grupo de conexiones no es algo trivial. Básicamente necesitas:

• métricas para investigar el uso de la conexión
• mecanismos de conmutación por error para cuando no hay conexión disponible

FlexyPool tiene como objetivo ayudarlo a calcular el tamaño correcto del grupo de conexiones.

Puede consultar los siguientes artículos:

• FlexyPool, agrupación de conexiones reactivas

• Tamaño del grupo de conexiones profesionales

• La ecuación de escalabilidad simple

Answer 4

Debe averiguar los diferentes flujos de trabajo esperados para averiguarlo. Idealmente, su grupo de conexiones también ajustará dinámicamente el número de conexiones en vivo en función del uso reciente, ya que es bastante común que la carga sea una función de la hora actual del día en su área geográfica de destino.

Comience con un número pequeño e intente llegar a un número razonable de usuarios concurrentes, luego aumente. Creo que es probable que descubra que su mecanismo de agrupación de conexiones no es tan instrumental en su escalabilidad como el resto del software.

Answer 5

El grupo de conexiones debería poder crecer y reducirse según las necesidades reales. Registre los números necesarios para hacer análisis en el sistema en ejecución, ya sea a través de declaraciones de registro o mediante vigilancia JMX. Considere configurar alertas para escenarios como " pico detectado: más de X nuevas entradas tuvieron que asignarse en Y segundos " ;, " la conexión estuvo fuera del grupo durante más de X segundos " lo que le permitirá prestar atención a los problemas de rendimiento antes de que tengan problemas reales.

Answer 6

Esto es algo que necesita ser probado y determinado de forma individual: es casi imposible dar una respuesta precisa para sus circunstancias sin estar íntimamente familiarizado con ellos.

Answer 7

Es difícil obtener datos duros para esto. También depende de una serie de factores que no menciona:

• 200 usuarios concurrentes, pero ¿qué parte de su actividad generará consultas en la base de datos? 10 consultas por carga de página? 1 consulta solo al iniciar sesión? etc. etc.

• Tamaño de las consultas y la base de datos obviamente. Algunas consultas se ejecutan en milisegundos, algunas en minutos.

Puede monitorear mysql para ver las consultas activas actuales con " show processlist " ;. Esto podría darle una mejor idea de cuánta actividad realmente está ocurriendo en la base de datos bajo carga máxima.

Answer 8

Según mi experiencia en sistemas financieros de alta transacción, si desea manejar, por ejemplo, 1K solicitudes por segundo , y tiene CPU 32 , debe tener < code> 1000/32 abrir encuestas de conexión a su base de datos.

Aquí está mi fórmula:

  

RPS / CPU_COUNT

Si la mayoría de los casos, su motor de base de datos podrá manejar sus solicitudes incluso en números mucho más bajos, pero sus conexiones estarán en modo de espera si el número es bajo.

Creo que es muy importante mencionar que su base de datos debería poder manejar esas transacciones (en función de la velocidad de su disco, la configuración de la base de datos y la potencia del servidor).

Buena suerte.