3. Indexation B-Tree Équilibrée
L'arbre équilibré B-Tree permet d'atteindre n'importe quelle ligne en quelques sauts logarithmiques :
- Même sur 100 millions d'enregistrements, 3 à 4 lectures de pages suffisent !
4. Diagnostic SQL avec EXPLAIN
Comment prouver qu'une requête s'exécute de façon optimale en PostgreSQL :
1EXPLAIN (ANALYZE, BUFFERS)
2SELECT id, score FROM session_quiz_submissions
3WHERE session_id = '01a0a979-de6e-773a-b76c-e4f2efb9f7f0'
4 AND student_code = 'MUTEX';
ANALYZE: Exécute réellement la requête pour chronométrer la durée exacte.BUFFERS: Affiche le nombre de pages mémoires lues en cache et sur le disque physique.
5. Analyse des Buffers Mémoire
Interprétation des résultats métrologiques de la commande EXPLAIN :
Nombre de pages de 8 Ko trouvées directement dans la mémoire tampon (RAM).
Performance maximale : 0 lecture physique sur disque.
Nombre de blocs qui ont dû être extraits physiquement du SSD NVMe.
Signal d'alerte : Indique un goulot I/O ou un index manquant.
6. Pools de Connexions SQL
Ouvrir une nouvelle connexion à la base de données par requête HTTP détruit les performances :
- Coût d'ouverture : Négociation TCP + poignée de main TLS + création de processus PostgreSQL.
- Saturation mémoire : Chaque connexion PostgreSQL réserve plusieurs mégaoctets de mémoire tampon dédiée.
- La solution : Maintenir un bassin pré-établi de connexions ouvertes et persistantes (Connection Pool).
7. Formule de Dimensionnement Optimal
Pourquoi surdimensionner un pool de connexions ralentit le serveur au lieu de l'accélérer ?
Taille Maximale du Pool = (Cœurs CPU × 2) + Nombre de Disques NVMe
Un serveur à 8 cœurs n'a besoin que de 16 à 20 connexions SQL actives pour saturer son matériel !
- Au-delà de cette formule, les cœurs CPU passent leur temps en bascules de contexte et contention de verrous disque.
8. Paramètres Critiques du Pool
Configuration exemplaire d'un pool de connexions SQL en Go :
1db, _ := sql.Open("pgx", connectionString)
2
3// Nombre maximal de connexions actives simultanées
4db.SetMaxOpenConns(25)
5
6// Nombre de connexions maintenues au repos
7db.SetMaxIdleConns(25)
8
9// Durée de vie maximale avant renouvellement d'une socket
10db.SetConnMaxLifetime(15 * time.Minute)
11
12// Recyclage d'une connexion inactive
13db.SetConnMaxIdleTime(5 * time.Minute)
9. Hiérarchie de Caching Multi-Niveaux
La hiérarchie des temps d'accès pour soulager la base de données relationnelle :
10. Cache Local In-Memory (LRU)
Le niveau de cache le plus rapide et le plus économe en ressources :
- Accès direct en mémoire vive : Zéro transit réseau, zéro sérialisation de paquet.
- Politique LRU (Least Recently Used) : Éjecte automatiquement les éléments les moins récemment consultés quand la taille limite est atteinte.
- Protection anti-OOM : Fixer impérativement une limite stricte en nombre d'éléments ou en mégaoctets alloués.
11. Cache Distribué (Redis)
Quand et pourquoi recourir à un cache distribué partagé ?
Toutes les répliques backend partagent le même état de cache unifié.
Zéro divergence de données.Le redémarrage d'une instance backend ne vide pas la mémoire de cache applicative.
Cache chaud permanent.Invalidation automatique des clés basée sur le temps pour garantir la fraîcheur.
Nettoyage automatique.12. Structure du Rapport d'Audit
Les 4 chapitres obligatoires du livrable final d'audit de performance :
TP Fil Rouge (Séance 8) : Rainbow Table SQL, Index & Cache-Aside
Mission : Persister les correspondances de condensats dans PostgreSQL, optimiser les requêtes via des index B-Tree, ajouter un cache mémoire LRU en O(1) et dresser le bilan comparatif d'audit final.
1. Batch Insert PostgreSQL
Créer la table rainbow_table(hash, plaintext) et remplacer les insertions unitaires par des Batch Inserts (pgx.CopyFrom) via le pool de connexions SQL.
2. Audit EXPLAIN ANALYZE & Index
Constater le coût d'un Sequential Scan sur 1 million de lignes, puis créer un index B-Tree adapté pour faire chuter le temps de recherche sous la milliseconde.
3. Cache Mémoire LRU O(1)
Implémenter un cache-aside local en RAM : si la cible @kAl1 a déjà été résolue, renvoyer la réponse instantanément sans solliciter la base SQL.
4. Tableau Comparatif d'Audit
Générer le tableau de synthèse final de l'audit comparant la Baseline J1-AM à la Version Finale V8 (latence, allocations, bande passante, débit global).