La mise à l’échelle commence par la charge nécessaire et la contrainte qui l’empêche.
La mise à l’échelle commence par la charge nécessaire et la contrainte qui l’empêche. Une réécriture complète change trop de variables avant d’identifier le goulot. Établissez une référence pour un parcours important, puis améliorez la capacité par des changements mesurables et réversibles.
Décrire la charge comme du travail
Relevez types de requêtes, simultanéité, volumes, tâches de fond et limites externes. Un pic bref diffère d’une croissance durable ; la navigation diffère d’un import massif. Fixez latence et taux d’échec acceptables pour le parcours plutôt qu’un nombre de visiteurs sans définition. Les données d’essai doivent refléter les distributions importantes.
Trouver le temps d’attente
Séparez calcul, attente de file, connexions et réponses du prestataire. Inspectez requêtes lentes, lectures répétées et résultats non bornés avant d’ajouter des serveurs. Davantage de workers peuvent aggraver une contention sur les mêmes verrous. Regardez les requêtes les plus lentes en plus de la moyenne et formulez une hypothèse réfutable pour chaque intervention.
Améliorer puis protéger le résultat
Un index, une pagination bornée ou une tâche déplacée hors du parcours interactif peut résoudre la contrainte. Un cache demande des règles de fraîcheur et d’invalidation. De nouvelles instances exigent une gestion adaptée des sessions et connexions. Répétez la charge et vérifiez autorisations, montants et traitement en plus de la vitesse. Documentez le prochain goulot et le déclencheur d’un investissement supplémentaire.
Un exemple à vérifier
Une liste peut devenir lente uniquement pour les grands comptes. Comparez plusieurs volumes avec la même requête et mesurez travail de base et taille de réponse. Vérifiez ensuite pagination et accès aux données. Une réponse plus rapide ne suffit pas si des éléments disparaissent entre pages ou échappent aux filtres d’autorisation. Rejouez aussi pendant un import concurrent pour confirmer que l’amélioration traite la contrainte réelle et non un cas isolé.
- Service associé
- Revue d’architecture cloud : relier fiabilité et coûts
- Audit de code ou test d’intrusion : choisir le bon périmètre
Questions fréquentes
Faut-il commencer par un cache ?
Seulement si les lectures répétées sont le goulot et si la fraîcheur est définie.
L’autoscaling suffit-il ?
Il ne supprime ni contention en base, ni limites externes, ni requêtes inefficaces.
Pourquoi regarder les latences extrêmes ?
La moyenne peut masquer une population très pénalisée.
Un petit jeu de données suffit-il ?
Pour certaines fonctions, mais pas pour tous les effets liés au volume.
Quand envisager une réécriture ?
Lorsque les changements bornés ne répondent pas aux contraintes démontrées et que la migration est comprise.
Transformons votre besoin en périmètre réalisable
Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.
Pour aller plus loin
Revue d’architecture cloud : relier fiabilité et coûts
Une revue cloud relie les dépenses au travail utile et la fiabilité à une reprise testée.
Audit de code ou test d’intrusion : choisir le bon périmètre
Un audit de code et un test d’intrusion répondent à des questions partiellement différentes.
Revue d’architecture logicielle : les preuves à réunir
Une revue d’architecture doit éclairer les prochaines décisions du produit.