Tamaño máximo de grupo predeterminado para HikariCP

¿Cuál es el tamaño del grupo de conexiones predeterminado que Spring Boot HikariCP proporciona cuando se carga el contenedor?

Por supuesto, estoy usando las siguientes propiedades para configurar el tamaño máximo de CP, pero me preguntaba cuál es el tamaño de CP predeterminado si no proporcionamos ningún número en el archivo application.properties.

spring.datasource.hikari.minimumIdle=5
spring.datasource.hikari.maximumPoolSize=20
spring.datasource.hikari.idleTimeout=30000
spring.datasource.hikari.poolName=SpringBootJPAHikariCP
spring.datasource.hikari.maxLifetime=2000000
spring.datasource.hikari.connectionTimeout=30000

Y si doy un tamaño máximo de grupo en application.properties como 100 y uso solo 20, ¿eso afectará el rendimiento de mi aplicación?

tamaño máximo de grupo

Predeterminado: 10

La documentación de HicariCP contiene propiedades predeterminadas:
https://github.com/brettwooldridge/HikariCP

Lea sobre el tamaño de la piscina aquí:
Tamaño máximo del grupo de conexiones

Con respecto al tamaño máximo del grupo, por ejemplo, postgresql recomienda la siguiente fórmula:

pool_size = ((core_count * 2) + effective_spindle_count)

• core_count es la cantidad de núcleos de CPU
• effective_spindle_count es la cantidad de discos en un RAID

Pero de acuerdo con esos documentos:

pero creemos que será ampliamente aplicable en todas las bases de datos.

Eso significa que esta fórmula generalmente puede aplicarse a otras bases de datos.

También, por ejemplo, sobre Oracle puedes leer este artículo y ver el video

La fórmula que se ha mantenido bastante bien en muchos puntos de referencia durante años es que para un rendimiento óptimo, la cantidad de conexiones activas debe estar cerca de

conexiones = ((core_count * 2) + efectiva_spindle_count).

El recuento de núcleos no debe incluir subprocesos HT, incluso si Hyperthreading está habilitado. El recuento efectivo de ejes es cero si el conjunto de datos activo se almacena en caché por completo y se acerca al número real de ejes a medida que cae la tasa de aciertos de caché. … No ha habido ningún análisis hasta ahora sobre qué tan bien funciona la fórmula con SSD.

El cálculo del tamaño del grupo para evitar el punto muerto es una fórmula de asignación de recursos bastante simple:

pool size = Tn x (Cm - 1) + 1

Dónde,

• Tn es el número máximo de hilos
• Cm es el número máximo de conexiones simultáneas mantenidas por un solo hilo.

Por ejemplo, imagine tres hilos (Tn=3), cada uno de los cuales requiere cuatro conexiones para realizar alguna tarea (Cm=4). El tamaño del grupo requerido para garantizar que nunca sea posible un interbloqueo es:

pool size = 3 x (4 - 1) + 1 = 10

Otro ejemplo, tiene un máximo de ocho subprocesos (Tn=8), cada uno de los cuales requiere tres conexiones para realizar alguna tarea (Cm=3). El tamaño del grupo requerido para garantizar que nunca sea posible un interbloqueo es:

pool size = 8 x (3 - 1) + 1 = 17

Este no es necesariamente el tamaño de grupo óptimo, sino el mínimo requerido para evitar interbloqueos.

En algunos entornos, el uso de un JTA (Java Transaction Manager) puede reducir drásticamente la cantidad de conexiones requeridas al devolver la misma conexión de getConnection() a un subproceso que ya contiene una conexión en la transacción actual.

Nunca dejamos de sorprendernos con las aplicaciones web internas que hemos encontrado, con unas pocas docenas de usuarios front-end que realizan actividades periódicas y un grupo de conexiones de 100 conexiones. No aprovisione en exceso su base de datos.