Optimisation de la requête de navires sous charte

[VincentAntoine]

Linked issues

• Resolve Optimisation des requêtes #3434

[VincentAntoine]

En prod après une nuit de collecte de stats (donc peu d'utilisation, surtout des actions de la pipeline) :

A ajuster ce soir après une journée d'utilisation plus intensive, mais on voit déjà qu'il y a un problème avec la requête

SELECT under_charter FROM last_positions [...]

qui est exécutée plus de 26 000 fois par heure (7 fois par seconde) et qui consomme au total 11 minutes de "temps de travail" de la BDD par heure.

Cette requête est appelée par le use case GetAllCurrentReportings qui boucle sur tous les reportings et fait un appel de cette requête à chaque fois.

De plus ou voit que la table last_positions est celle qui subit le plus de sequential scans et que le nombre de sequential scans correspond au nombre d'exécutions de cette requête :

Le repository contenant la requête incriminée est :

interface DBLastPositionRepository : JpaRepository<LastPositionEntity, Int> {

    // [...]

    @Query(
        value = """
        SELECT under_charter
        FROM last_positions
        WHERE
            CASE
                WHEN :vesselIdentifier = 'INTERNAL_REFERENCE_NUMBER' THEN cfr
                WHEN :vesselIdentifier = 'IRCS' THEN ircs
                WHEN :vesselIdentifier = 'EXTERNAL_REFERENCE_NUMBER' THEN external_immatriculation
            END = :value
        """,
        nativeQuery = true,
    )
    fun findUnderCharterByVesselIdentifierEquals(vesselIdentifier: String, value: String): Boolean
}

• Passer cette requête sur vessels plutôt que sur last_positions (permet de plus d'avoir des données sur les navires < 12m qui ne figurent pas dans last_positions
• Modifier la requête pour assurer qu'elle exploite les index
• Mettre un cache avec une expiration de ~1h sur le repository

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[VincentAntoine]

Update après un peu moins de 24h de stats d'usage des requêtes :

En journée l'utilisation accrue de l'appli entraîne une augmentation de la charge sur cette requête qui occupe la BDD quasiment 100% du temps!

[ivangabriele]

LGTM mais on aurait pu même directement utiliser JpaVesselRepository.findVessel().

[VincentAntoine]

@louptheron je vois qu'il y avait un ticket lié aux perfs de cette requête #2362

Tu penses que ça reste nécessaire de remplacer la logique du use case pour faire un join plutôt qu'un forEach malgré l'optimisation faite dans ce ticket (passage sur la table vessels + optimisation de la requête pour exploiter les index + ajout d'un cache backend) ?

[louptheron]

@louptheron je vois qu'il y avait un ticket lié aux perfs de cette requête #2362

Tu penses que ça reste nécessaire de remplacer la logique du use case pour faire un join plutôt qu'un forEach malgré l'optimisation faite dans ce ticket (passage sur la table vessels + optimisation de la requête pour exploiter les index + ajout d'un cache backend) ?

@VincentAntoine Bien joué pour l'optimisation, perso ça me semble suffisant : il y aura pas mal de requêtes toutes les 30 minutes, avec l'utilisation du cache, mais comme les index sont utilisés c'est OK.
On attend un nouveau rapport d'usage de la DB après la MEP et on avise ?