High Load

Quand la base de données ralentit et que le serveur est surchargé

Avec l'augmentation du trafic sur le site ou du volume de la base de données atteignant des millions d'enregistrements, les méthodes de développement standard ne suffisent plus. Les pages commencent à charger pendant plusieurs secondes, le processeur du serveur est à 100 %, la base de données verrouille les tables et les utilisateurs voient des erreurs 504 Gateway Timeout.

Le simple achat d'un serveur plus cher ne résout le problème que temporairement — les requêtes non optimales s'échelonnent très mal. Nous abordons l'optimisation des systèmes à haute charge (Highload) au niveau de l'architecture et du code. Nous analysons les journaux de requêtes lentes (Slow Query Log), construisons des bases d'index efficaces, réécrivons les requêtes SQL lourdes et déployons la mise en cache en mémoire vive (Redis, Memcached).

Pour les projets contenant des téraoctets de données, nous déployons des architectures distribuées : réplication de base de données (Master-Slave) pour séparer les flux de lecture et d'écriture, ainsi que le dimensionnement horizontal (sharding).

  • Audit de performance des bases de données (MySQL, PostgreSQL, MongoDB, ClickHouse)
  • Optimisation de la structure des bases de données, normalisation/dénormalisation et index
  • Mise en cache des données « lourdes » en mémoire vive à l'aide de Redis
  • Configuration de la réplication de bases de données (séparation des flux Read/Write au niveau du code)
  • Profilage du code serveur backend (PHP, Node.js, Python, Go)

100x

Accélération du temps d'exécution des requêtes SQL lentes après optimisation des index

10K+

RPS (requêtes par seconde) — performance cible de la base de données optimisée

<50 ms

Temps de réponse de l'API sur le backend sous charge maximale en mode mis en cache

10 millions routine

Lignes de données — le volume minimal de tables avec lesquelles nous travaillons dans le cadre de l'optimisation

N'augmentez pas le matériel — optimisez les algorithmes

Une requête SQL non optimale avec des boucles imbriquées commence à s'exécuter exponentiellement plus lentement à mesure que la base de données grandit. Nous écrivons un code backend propre et rapide et configurons les index corrects, vous permettant d'économiser sur la location de serveurs.

Notre méthode

Trois étapes pour un backend rapide

Nous menons une étude détaillée des métriques système et optimisons les goulots d'étranglement.

Profilage du code backend

En utilisant des profileurs spécialisés (Blackfire, Xdebug, V8 Profiler), nous décomposons le fonctionnement des scripts serveur en millisecondes. Nous trouvons les fonctions « lourdes », les fuites de mémoire vive et les boucles superflues.

L'optimisation du code serveur lui-même permet de réduire la charge processeur (CPU) plusieurs fois.

Mise en cache en mémoire vive

Les requêtes envoyées aux disques durs classiques et aux SGBD prennent relativement du temps. Nous configurons Redis/Memcached — des bases de données en mémoire vive. Les données « chaudes » et rarement modifiées sont servies en une fraction de milliseconde.

Le serveur renvoie instantanément la page ou le bloc mis en cache, sans solliciter la base de données principale.

Réplication et séparation des flux

Lors d'opérations simultanées d'écriture et de lecture, la base de données peut verrouiller des tables (Database locks). Nous configurons la réplication : le serveur principal (Master) accepte les données en écriture, et un pool de serveurs de copie (Slaves) fournit les données en lecture.

Cela exclut les blocages mutuels et répartit la charge de lecture entre les machines.

Étapes

Comment se déroule l'optimisation Highload

Processus cohérent de collecte de logs, de débogage des requêtes, de configuration de cache et de tests de charge.

01

Collecte de journaux et analyse Slow Query

Nous activons la surveillance des requêtes SQL lentes. Nous identifions les requêtes dont le temps d'exécution dépasse 100 ms. Nous établissons une carte de charge de la base de données.

02

Optimisation des index et de la structure

Nous analysons les plans d'exécution des requêtes (EXPLAIN). Nous ajoutons des index composés, éliminons le balayage complet des tables (Full Table Scan), optimisons les jonctions JOIN.

03

Profilage du code serveur

Nous lançons le profilage du code backend. Nous recherchons les fuites de mémoire, les algorithmes de traitement de données inefficaces, nous optimisons les boucles internes.

04

Intégration du cache Redis

Nous concevons le schéma de mise en cache : cache-aside pour les blocs statiques du site, les listes de produits, les menus. Nous configurons la durée de vie (TTL) et l'invalidation du cache.

05

Optimisation de la configuration SGBD

Nous configurons finement les fichiers de configuration du SGBD (my.cnf, postgresql.conf) : répartition du pool tampon de mémoire, cache de connexion et paramètres d'écriture sur disque.

06

Test de stress de charge

Via les outils k6/wrk, nous simulons une affluence de pointe de milliers d'utilisateurs. Nous mesurons la stabilité du temps de réponse, la consommation CPU et prouvons les résultats par des chiffres.

Notre stack

Stack d'outils de développement Highload

Nous utilisons des logiciels avancés de profilage et de mise en cache de bases de données.

Blackfire.io & Xdebug

Principaux profileurs de code. Ils fournissent des « cartes d'appels » (Call Graphs) interactives, permettant de visualiser quelle ligne PHP ou Node.js consomme les ressources du processeur.

Redis & Sentinel / Cluster

Cache ultra-rapide en RAM. Utilisé pour stocker les résultats de requêtes lourdes, les sessions utilisateur et les jetons, répondant aux requêtes en quelques microsecondes.

k6.io & wrk

Logiciel moderne pour effectuer des tests de charge. Génère des requêtes HTTP asynchrones en milliers de flux, permettant d'évaluer les limites de résistance du backend avant le lancement.

Tarifs

Tarifs de l'optimisation des bases de données et du backend

Le prix dépend de la taille de la base de données, de la complexité de la logique serveur et du taux de RPS requis.

Possibilités Optimisation SQL et des index Nettoyage de la base de données et accélération des requêtes lentes 60 000 ₽ Délai : jusqu'à 7 jours Commander Populaire Mise en cache et code Intégration de Redis, profilage du code backend 95 000 ₽ Délai : jusqu'à 14 jours Commander Architecture Highload Réplication de base de données, mise à l'échelle horizontale clé en main à partir de 180 000 ₽ Délai : à partir de 20 jours Discuter
Nombre de requêtes SQL à optimiser jusqu'à 30 requêtes lourdes jusqu'à 70 requêtes + mise en cache Refonte complète de la structure de la base de données et des requêtes
Intégration de la mise en cache Redis Mise en cache de base des blocs Cache distribué Redis Sentinel
Profilage du code backend (Blackfire / Node) Profilage de base Refactoring approfondi des goulots d'étranglement
Configuration de la réplication (Master-Slave) Séparation des flux Read/Write
Tests de stress (k6 / wrk) Test jusqu'à 1 000 RPS Tests jusqu'à 10 000+ RPS avec rapport
Optimisation des configurations serveurs et SGBD Configuration de my.cnf/postgresql.conf Optimisation des tampons RAM Optimisation complète du noyau du système d'exploitation, de Nginx et de la base de données
FAQ

Questions fréquentes sur l'optimisation Highload

Votre serveur est constamment surchargé et les utilisateurs se plaignent de la lenteur du site ? Écrivez-nous — nous effectuerons un profilage de la charge et vous montrerons où se perdent les millisecondes.

  • Comment savoir si notre projet a vraiment besoin d'une optimisation de la base de données ?

    Signes principaux de problèmes de base de données : 1) les pages du site (en particulier l'espace client ou le catalogue produits avec filtres) s'ouvrent en plus de 1 à 2 secondes ; 2) avec l'augmentation du nombre d'utilisateurs en ligne, le site commence à « ralentir » fortement ou à afficher une erreur 504 Gateway Timeout ; 3) dans le panneau de surveillance de l'hébergement, le graphique de charge processeur (CPU) du serveur atteint 100 %, et le processus SGBD (mysqld ou postgres) consomme un maximum de ressources ; 4) la taille de la base de données dépasse 5 à 10 Go. Dans tous ces cas, le profilage des requêtes permet de réduire considérablement la charge.
  • L'achat simple d'un serveur plus puissant aidera-t-il au lieu d'optimiser le backend ?

    Le plus souvent, non. Si vous avez une requête SQL qui effectue une recherche sans index sur une table de 1 million de lignes, le processeur du serveur est obligé de lire toutes les données du disque à chaque clic. Acheter un serveur avec 32 cœurs au lieu de 8 permettra simplement d'exécuter davantage de ces requêtes inefficaces en même temps, mais cela n'accélérera pas le chargement des pages pour un utilisateur spécifique. De plus, lorsque la base de données atteindra 10 millions de lignes, le site finira par se bloquer. Des index corrects accélèrent la recherche par milliers, rendant l'achat de matériel coûteux inutile.
  • Qu'est-ce que le sharding de bases de données et dans quels cas est-il appliqué ?

    Le sharding (partitionnement horizontal) est une méthode de division d'une énorme table de base de données en parties et de leur répartition sur différents serveurs physiques. Par exemple, la table des commandes d'une boutique en ligne peut être divisée : les commandes des utilisateurs de Moscou sont stockées sur le serveur n°1, et celles de Saint-Pétersbourg sur le serveur n°2. Le sharding est appliqué dans les projets à l'échelle Enterprise, lorsque le volume de données dépasse la capacité des disques durs ou de la RAM d'un seul serveur, et que la réplication classique ne suffit plus à gérer la charge.
  • Comment effectuez-vous les tests de charge et est-ce sans danger pour un site en production ?

    Nous n'effectuons jamais de tests de charge sur un site de production en ligne, car cela pourrait entraîner sa panne et la perte de clients. Nous déployons une copie isolée complète du projet (serveur Staging), identique au serveur de production en termes de puissance. Ensuite, à l'aide de l'outil k6.io, nous générons des utilisateurs virtuels qui effectuent des actions types (recherche, ajout au panier, consultation d'articles). Nous augmentons progressivement la charge de 10 à 1000+ requêtes par seconde (RPS), en observant à partir de quels chiffres le serveur commence à faiblir.
Charges élevées

Vous préparez une campagne publicitaire d'envergure ou des soldes ?

Faites une demande — nos architectes Highload prépareront votre site à l'afflux de centaines de milliers de visiteurs, optimiseront les requêtes, configureront la mise en cache et garantiront un fonctionnement stable sous charge.

Optimiser le backend sous charge