Dans la première partie de cet article, nous avons appris comment améliorer les performances de nos applications, en remplaçant Tomcat par Undertow, qui est un serveur Web hautes performances, en plus d'activer et de configurer la compression des données, pour réduire la taille des réponses HTTP qui transitent sur le réseau.

Maintenant, nous allons parler de la façon d'améliorer les performances de l'application Spring Boot dans la partie persistance, mais nous devons d'abord comprendre ce que JPA, Hibernate et Hikari.

JPA

JPA ou Java Persistence API, qui a ensuite été renommé Jakarta Persistence, est un standard de langage Java qui décrit un langage commun interface pour les frameworks de persistance des données

La spécification

JPA définit le mappage relationnel d'objet en interne, plutôt que de s'appuyer sur des implémentations de mappage spécifiques au fournisseur.

Hiberner

Hibernate est l'un des frameworks ORM qui réalise l'implémentation concrète de la spécification JPA. c'est-à-dire que si cette spécification décrit la nécessité de méthodes pour persist, remove, mettre à jour et récupérer des données, la personne qui créera réellement ces comportements est Hibernate, ainsi que EclipseLink , qui est un autre ORM.

Hikari

Hikari est un framework de regroupement de connexions, qui est chargé de gérer les connexions à la base de données, en les gardant ouvertes afin qu'elles puissent être réutilisées, c'est-à-dire il s'agit d'un cache de connexions pour les requêtes futures, rendant l'accès à la base de données plus rapide et réduisant le nombre de nouvelles connexions à créer.

Configuration de Hikari, JPA et Hibernate

Une configuration que nous pouvons effectuer pour améliorer les performances est la suivante :

Utilisation d'application.yml :

printemps: Hikari : validation automatique : faux délai d'attente de connexion : 250 durée de vie maximale : 600 000 taille maximale du pool : 20 minimum d'inactivité : 10 nom du pool : maître jpa : ouvert en vue : faux show-sql : vrai hiberner: ddl-auto : aucun propriétés: hibernate.connection.provider_disables_autocommit : vrai hibernate.generate_statistics : vrai

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

Utilisation de application.properties :

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 spring.datasource.hikari.minimum-idle=10 spring.datasource.hikari.pool-name=maître spring.datasource.jpa.open-in-view=false spring.datasource.jpa.show-sql=true spring.datasource.jpa.hibernate.ddl-auto=aucun 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

Donnons maintenant un bref résumé des options :

Hikari

• spring.datasource.hikari.auto-commit : si faux, chaque connexion renvoyée par

  pool de connexions sera accompagnée de auto-commit désactivé.

• spring.datasource.hikari.connection-timeout : durée, en millisecondes, pendant laquelle le client attendra une connexion depuis

  pool. Il est préférable de définir un délai d'attente court pour échouer rapidement et renvoyer un message d'erreur, plutôt que de faire attendre le client indéfiniment.

• spring.datasource.hikari.max-lifetime : durée maximale pendant laquelle une connexion peut rester active. La configuration de ce paramètre est cruciale pour éviter les échecs dus à des connexions problématiques et augmenter la sécurité, car les connexions actives depuis longtemps sont plus vulnérables aux attaques.

• spring.datasource.hikari.maximum-pool-size : taille maximale du

  pool, y compris les connexions inactives et en cours d'utilisation, déterminant le nombre maximum de connexions actives à la base de données. Si le pool atteint cette limite et qu'il n'y a aucune connexion inactive, les appels à getConnection() seront bloqués jusqu'à connectionTimeout millisecondes avant d'échouer.

  Trouver une valeur appropriée est important, car beaucoup de gens pensent qu'ils obtiendront d'excellentes performances en la définissant sur 50, 70 ou même 100. L'idéal est d'avoir un maximum de 20, qui est le nombre de
  • threads en parallèle à l'aide de connexions.
  Plus la valeur est élevée, plus il sera difficile pour la base de données de gérer ces connexions et nous ne pourrons probablement pas avoir suffisamment de
  • débit pour utiliser toutes ces connexions.
  Il est important de comprendre que du point de vue du
  • SGBDR (Système de gestion de bases de données relationnelles), il est difficile de maintenir une connexion ouverte avec lui-même, imaginez n nombre de connexions .
• spring.datasource.hikari.minimum-idle : nombre minimum de connexions que le pool maintient lorsque la demande est faible. Le pool peut réduire les connexions jusqu'à 10 et les recréer selon les besoins. Cependant, pour des performances maximales et une meilleure réponse aux pics de demande, il est recommandé de ne pas définir cette valeur, permettant ainsi à Hikari de fonctionner comme un pool de taille fixe. Par défaut : identique à spring.datasource.hikari.maximum-pool-size.

• spring.datasource.hikari.pool-name : nom défini par l'utilisateur pour la connexion

  pool et apparaît principalement dans les consoles de gestion de registre et JMX pour identifier pools et leurs configurations.

JPA

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

  OSIV (Ouvrir la session en vue) est activé, une session est maintenue tout au long de la requête, même sans l'annotation @Transactional. Cela peut entraîner des problèmes de performances, tels qu'un manque de réponses de l'application, car la session maintient la connexion à la base de données jusqu'à la fin de la requête.

• spring.datasource.jpa.show-sql : affiche le journal SQL en cours d'exécution dans notre application. Nous le laissons généralement activé en développement, mais désactivé en production.

• spring.datasource.jpa.hibernate.ddl-auto : configure le comportement de

  Hibernate par rapport au schéma de la base de données. Il peut avoir les valeurs suivantes :

  none : ne fait rien. Nous gérons manuellement le schéma de la banque.
  validate : valide le
  • schéma de la base de données, mais n'apporte aucune modification. Ceci est utile pour garantir que le schéma actuel est conforme aux entités que nous avons cartographiées.
  update : met à jour le
  • schéma de la base de données pour refléter les modifications apportées aux entités.
  create : Crée le
  • schéma de la base de données. Si le schéma existe déjà, il sera supprimé et créé à nouveau.
  create-drop : crée le
  • schéma à partir de la base de données et, lorsque l'application se termine, supprime le schéma. Utile pour les tests, où nous voulons une base de données propre pour chaque test.
• spring.jpa.properties.hibernate.generate_statistics : sert à collecter des informations détaillées sur Hibernate, telles que les temps d'exécution des requêtes, le nombre de requêtes exécutées et d'autres mesures.

• spring.jpa.properties.hibernate.connection.provider_disables_autocommit : informe

  Hibernate que nous avons désactivé la auto-commit des fournisseurs (PostgreSQL, MySQL, etc.). Cela a un impact sur les performances, car Hibernate devra obtenir une connexion du pool pour savoir si la auto-commit est activée ou non. , pour chaque transaction qu'il effectue.

C'est ainsi que nous clôturons la deuxième partie de l'article. Tous les paramètres présents ne concernaient pas les performances, mais ceux qui ont réellement un impact sont les paramètres

Hikari tels que commit automatique et taille du pool , ceux de JPA et Hibernate comme OSIV (Ouvrir la session en vue) et informer que nous avons désactivé la la validation automatique des fournisseurs.

Dans la partie suivante, nous parlerons des exceptions et de la manière dont elles peuvent être configurées, pour économiser les ressources de la

JVM (Machine virtuelle Java).

Références :

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