En la primera parte de este artículo, aprendimos cómo mejorar el rendimiento de nuestras aplicaciones, reemplazando Tomcat por Undertow, que es un servidor web de alto rendimiento, además de habilitar y configurar la compresión de datos, para reducir el tamaño de las respuestas HTTP que viajan por la red.

Ahora hablaremos sobre cómo mejorar el rendimiento de la aplicación Spring Boot en la parte de persistencia, pero primero debemos entender qué son JPA, Hibernate y Hikari. ].

APP

JPA o Java Persistence API, que luego pasó a llamarse Jakarta Persistence, es un estándar del lenguaje Java que describe un interfaz para marcos de persistencia de datos

La especificación

JPA define el mapeo relacional de objetos internamente, en lugar de depender de implementaciones de mapeo específicas del proveedor.

Hibernar

Hibernate es uno de los marcos ORM que realiza la implementación concreta de la especificación JPA. es decir, si esta especificación describe la necesidad de métodos para persist, eliminar, actualizar y obtener datos, la persona que realmente creará estos comportamientos es Hibernate, así como EclipseLink , que es otro ORM.

Hikari

Hikari es un framework de agrupación de conexiones, que se encarga de gestionar las conexiones a la base de datos, manteniéndolas abiertas para que puedan ser reutilizadas, es decir, es un caché de conexiones para futuras solicitudes, agilizando el acceso a la base de datos y reduciendo el número de nuevas conexiones a crear.

Configurando Hikari, JPA e Hibernate

Una configuración que podemos estar realizando para mejorar el rendimiento es la siguiente:

Usando application.yml:

primavera: Hikari: confirmación automática: falso tiempo de espera de conexión: 250 vida útil máxima: 600000 tamaño máximo de la piscina: 20 mínimo-inactivo: 10 nombre-grupo: maestro jpa: abierto a la vista: falso mostrar-sql: verdadero hibernar: ddl-auto: ninguno propiedades: hibernate.connection.provider_disables_autocommit: verdadero hibernate.generate_statistics: verdadero

spring:
  hikari:
    auto-commit: false
    connection-timeout: 250
    max-lifetime: 600000
    maximum-pool-size: 20
    minimum-idle: 10
    pool-name: master

  jpa:
    open-in-view: false
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate.connection.provider_disables_autocommit: true
      hibernate.generate_statistics: true

Usando propiedades.de.aplicación:

spring.datasource.hikari.auto-commit=false spring.datasource.hikari.connection-timeout=50 spring.datasource.hikari.max-lifetime=600000 spring.datasource.hikari.maximum-pool-size=20 primavera.datasource.hikari.minimum-idle=10 spring.datasource.hikari.pool-name=maestro spring.datasource.jpa.open-in-view=falso spring.datasource.jpa.show-sql = verdadero spring.datasource.jpa.hibernate.ddl-auto=ninguno spring.jpa.properties.hibernate.generate_statistics=true spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true

spring:
  hikari:
    auto-commit: false
    connection-timeout: 250
    max-lifetime: 600000
    maximum-pool-size: 20
    minimum-idle: 10
    pool-name: master

  jpa:
    open-in-view: false
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate.connection.provider_disables_autocommit: true
      hibernate.generate_statistics: true

Ahora hagamos un breve resumen de las opciones:

Hikari

• spring.datasource.hikari.auto-commit: si es falso, cada conexión devuelta por

  grupo de conexiones vendrá con auto-commit deshabilitado.

• spring.datasource.hikari.connection-timeout: tiempo, en milisegundos, que el cliente esperará una conexión desde

  pool. Es preferible establecer un tiempo de espera corto para fallar rápidamente y devolver un mensaje de error, en lugar de mantener al cliente esperando indefinidamente.

• spring.datasource.hikari.max-lifetime: tiempo máximo que una conexión puede permanecer activa. Configurar este parámetro es crucial para evitar fallos por conexiones problemáticas y aumentar la seguridad, ya que las conexiones que llevan mucho tiempo activas son más vulnerables a ataques.

• spring.datasource.hikari.maximum-pool-size: Tamaño máximo del

  pool, incluidas las conexiones inactivas y en uso, que determina el número máximo de conexiones activas a la base de datos. Si el grupo alcanza este límite y no hay conexiones inactivas, las llamadas a getConnection() se bloquearán durante hasta connectionTimeout milisegundos antes de fallar.

  Encontrar un valor adecuado es importante, ya que muchas personas piensan que obtendrán un gran rendimiento estableciéndolo en 50, 70 o incluso 100. Lo ideal es tener un máximo de 20, que es el número de
  • hilos en paralelo usando conexiones.
  Cuanto mayor sea el valor, más difícil será para la base de datos administrar estas conexiones y lo más probable es que no podamos tener suficiente
  • rendimiento para usar todas estas conexiones.
  Es importante entender que desde el punto de vista de
  • RDBMS (Sistema de gestión de bases de datos relacionales) es difícil mantener una conexión abierta consigo mismo, imagine n número de conexiones .
• spring.datasource.hikari.minimum-idle: número mínimo de conexiones que mantiene el grupo cuando la demanda es baja. El grupo puede reducir las conexiones hasta 10 y recrearlas según sea necesario. Sin embargo, para obtener el máximo rendimiento y una mejor respuesta a los picos de demanda, se recomienda no establecer este valor, lo que permite a Hikari funcionar como un grupo de tamaño fijo. Valor predeterminado: igual que spring.datasource.hikari.maximum-pool-size.

• spring.datasource.hikari.pool-name: nombre definido por el usuario para la conexión

  pool y aparece principalmente en las consolas de administración de registro y JMX para identificar a piscinas y sus configuraciones.

APP

• spring.datasource.jpa.open-in-view: cuando

  OSIV (Abrir sesión en vista) está habilitado, se mantiene una sesión durante toda la solicitud, incluso sin la anotación @Transactional. Esto puede causar problemas de rendimiento, como falta de respuestas de la aplicación, ya que la sesión mantiene la conexión a la base de datos hasta el final de la solicitud.

• spring.datasource.jpa.show-sql: Muestra el log SQL que se está ejecutando en nuestra aplicación. Generalmente lo dejamos habilitado en desarrollo, pero deshabilitado en producción.

• spring.datasource.jpa.hibernate.ddl-auto: Configura el comportamiento de

  Hibernate en relación con el esquema de la base de datos. Puede tener los siguientes valores:

  ninguno: no hace nada. Gestionamos manualmente el esquema del banco.
  validar: Valida el
  • esquema de la base de datos, pero no realiza cambios. Esto es útil para garantizar que el esquema actual coincida con las entidades que hemos asignado.
  actualización: actualiza el
  • esquema de la base de datos para reflejar los cambios en las entidades.
  crear: Crea el
  • esquema de la base de datos. Si el esquema ya existe, lo eliminará y lo creará nuevamente.
  create-drop: Crea el
  • esquema de la base de datos y, cuando finaliza la aplicación, elimina el esquema. Útil para pruebas, donde queremos una base de datos limpia para cada prueba.
• spring.jpa.properties.hibernate.generate_statistics: Sirve para recopilar información detallada sobre Hibernate, como tiempos de ejecución de consultas, número de consultas ejecutadas y otras métricas.

• spring.jpa.properties.hibernate.connection.provider_disables_autocommit: Informa a

  Hibernate que hemos deshabilitado la confirmación automática de proveedores (PostgreSQL, MySQL, etc.). Esto afecta el rendimiento porque Hibernar necesitará obtener una conexión del grupo para saber si auto-commit está habilitado o no. , por cada transacción que realiza.

Con esto cerramos la segunda parte del artículo. No todas las configuraciones presentes se referían al rendimiento, pero las que realmente impactan son las configuraciones de

Hikari como confirmación automática y tamaño del grupo , los de JPA y Hibernate como OSIV (Abrir sesión en vista) e informar que hemos deshabilitado la confirmación automática de proveedores.

En la siguiente parte hablaremos sobre las excepciones y cómo se pueden configurar para ahorrar recursos de la

JVM (Java Virtual Machine).

Referencias:

https://en.wikipedia.org/wiki/Jakarta_Persistence
https://www.ibm.com/docs/pt-br/was/8.5.5?topic=SSEQTP_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/cejb_persistence.htm
https://github.com/brettwooldridge/HikariCP
https://github.com/corona-warn-app/cwa-server/issues/556
https://medium.com/@rafaelralf90/open-session-in-view-is-evil-fd9a21645f8e