Accélérez vos applications cloud et améliorez l'expérience utilisateur
Améliorez les performances et la scalabilité de vos applications cloud.
Une application lente que l'on agrandit sans jamais la mesurer
La séquence est presque toujours la même. Les utilisateurs signalent des lenteurs en fin de matinée, l'équipe augmente la taille de l'instance, la situation s'améliore deux semaines, puis les lenteurs reviennent. On agrandit de nouveau, on ajoute un cache devant, on double la mémoire de la base. La facture progresse à chaque étape, les temps de réponse ne reviennent jamais à leur niveau initial, et personne ne sait dire quelle modification a produit quel effet, faute d'avoir mesuré avant.
Le second cas est celui de l'application qui tient parfaitement le lundi et s'effondre le jour d'une campagne ou d'une clôture mensuelle. Le dimensionnement a été fixé sur une moyenne et jamais sur un profil de charge observé. Le jour venu, ce n'est pas la puissance de calcul qui manque : c'est une requête sans index, un nombre de connexions plafonné, un traitement synchrone qui bloque la file, ou un stockage dont le débit était limité depuis sa création.
Ce que nous mesurons avant de toucher à une instance
Nous commençons par établir une référence chiffrée sur l'application réelle, et non sur une page d'accueil. Nous relevons la distribution des temps de réponse aux heures ouvrées, les requêtes les plus coûteuses de la base, les temps d'attente sur le stockage et le réseau, la saturation des files et le comportement du cache. Cette mesure change souvent la conclusion, parce qu'une instance jugée saturée se révèle largement dimensionnée pendant qu'un verrou de base de données absorbe l'essentiel du temps perdu.
Nous corrigeons ensuite dans l'ordre du gain et du risque, une modification à la fois, avec une mesure après chaque changement. Les corrections applicatives et de base de données passent avant les ajustements d'infrastructure, parce qu'elles règlent la cause au lieu d'en masquer l'effet. La mise à l'échelle automatique n'arrive qu'après le diagnostic, jamais comme rustine posée la veille d'une campagne. Nous validons enfin les gains sous une charge représentative et nous vous remettons la référence de départ à côté du résultat obtenu.
Ce que couvre une mission de performance
- Nous établissons une référence chiffrée sur les parcours qui comptent, mesurés en conditions réelles et non sur un environnement vide.
- Nous analysons les requêtes les plus coûteuses, les verrous et les plafonds de connexions de vos bases de données.
- Nous vérifions le débit du stockage, la latence entre composants et le placement des services les uns par rapport aux autres.
- Nous examinons la stratégie de cache, la diffusion des contenus statiques et le traitement asynchrone de ce qui bloque un parcours.
- Nous rejouons un test de charge représentatif avant et après chaque modification, une correction à la fois.
- Nous réglons la mise à l'échelle une fois le diagnostic établi, avec des seuils issus des mesures et non d'une estimation.
- Nous laissons les indicateurs branchés et documentés, afin qu'une régression se voie sans attendre le prochain signalement.
Les trois endroits où se perdent les temps de réponse
La base de données avant le processeur
Une requête sans index, un verrou tenu trop longtemps ou un plafond de connexions expliquent la majorité des lenteurs que nous instruisons. Agrandir la machine autour d'eux repousse l'échéance sans supprimer la cause.
Le stockage et le réseau, rarement suspectés
Un volume dont le débit était limité au moment de sa création bride tout ce qui tourne au dessus. Un aller-retour entre deux régions ajoute une latence que ni le cache ni la puissance ne compensent.
Le cache masque autant qu'il accélère
Bien posé, il absorbe les pics et rend l'application confortable. Mal posé, il cache une lenteur de fond qui réapparaît intacte dès que la donnée change ou que le cache se vide.
Plus rapide sans simplement surdimensionner
Nous mesurons latence et saturations, puis nous ajustons instances, cache et files. L'auto-scaling vient après le diagnostic, pas comme rustine posée la veille d'une campagne.
Outils et délai
Audit de perf 3 à 10 jours selon le nombre de services.
Comment se conduit un chantier de performance mesurable
Un chantier de performance commence par une définition écrite de ce que veut dire rapide pour votre activité. Une moyenne ne suffit pas : nous regardons la distribution, parce qu'une application dont une petite part des requêtes met plusieurs secondes est perçue comme lente par les utilisateurs qui tombent sur cette part. Nous fixons donc une cible sur les parcours qui comptent, par exemple l'ouverture d'un dossier client ou la validation d'une commande, et nous mesurons ces parcours aux heures ouvrées réelles plutôt que sur un environnement de test vide.
L'architecture décide ensuite d'une grande partie du résultat, et certaines décisions coûtent cher longtemps après avoir été prises. Placer la base de données dans une région différente de celle des serveurs applicatifs ajoute une latence à chaque aller-retour, multipliée par le nombre de requêtes d'une page. Choisir un type de volume au débit limité pour économiser à la création bride tout ce qui s'exécute au dessus. Traiter de façon synchrone un envoi de courriel ou une génération de document immobilise un processus qui manquera au parcours suivant. Ces choix ne se corrigent pas en agrandissant une machine.
Ce que nous mesurons ne se limite pas au temps de réponse. Nous suivons la saturation de chaque étage, c'est-à-dire le point où une file d'attente commence à s'allonger, parce que cette valeur annonce l'effondrement bien avant que la moyenne ne bouge. Nous suivons également le taux d'erreur sous charge, la durée des requêtes les plus lentes, le taux de réussite du cache et le comportement des dépendances externes, qui deviennent souvent le vrai plafond. Ces mesures restent branchées après le chantier, dans le cadre de notre offre de supervision de plateforme, afin qu'une régression se voie tout de suite.
Nous automatisons la mesure et le déploiement, pas la décision. Les tests de charge sont rejoués à l'identique avant et après chaque modification, et la configuration est décrite dans des fichiers pour qu'un environnement de recette soit réellement comparable à la production, méthode expliquée dans notre article sur Terraform et Ansible. Restent manuels l'arbitrage entre deux corrections possibles, la relecture des requêtes avec vos développeurs, et la décision d'activer une mise à l'échelle automatique, qui n'a de sens que si l'application sait démarrer vite et fonctionner à plusieurs exemplaires.
Il faut dire ce que ce chantier n'est pas. La performance et la maîtrise des coûts se rencontrent parfois, quand un mauvais dimensionnement disparaît, mais elles ne vont pas systématiquement dans le même sens : ajouter des réplicas ou une diffusion de contenu améliore l'expérience et augmente la dépense, sujet que nous traitons dans notre offre de gestion des coûts cloud. Nous disons aussi quand la réponse n'est pas dans l'infrastructure : un besoin de résistance à la panne se règle souvent avec deux machines derrière un répartiteur, sans introduire un orchestrateur que personne n'exploitera, arbitrage développé dans nos articles sur Kubernetes en PME et sur les conteneurs sans orchestrateur.
Les corrections qui déplacent le problème sans le régler
-
Agrandir l'instance à chaque plainte
La lenteur recule de quelques semaines et la dépense reste, mois après mois. Quand la cause est une requête ou un verrou, la puissance supplémentaire augmente seulement le coût du même problème.
-
Poser un cache devant une lenteur de fond
Le confort revient tant que les données ne changent pas, puis tout s'effondre au premier vidage de cache ou à la première mise à jour massive. Le diagnostic n'a pas été fait, il a été reporté.
-
Activer la mise à l'échelle sans l'avoir éprouvée
Une application qui met deux minutes à démarrer ou qui garde un état local ne se duplique pas utilement. Les nouveaux exemplaires arrivent après le pic et facturent pendant le reste de la journée.
De la mesure initiale à la mise en production
-
Profiling
sous 5 jours après la demande
-
Optimisation
1 à 2 semaines
-
Tests de charge
sous 7 jours
-
Mise en production
selon validation
Les applications pour lesquelles on nous appelle
Nous intervenons sur des applications métier, des portails clients et des plateformes de données dont la lenteur commence à se voir dans l'activité : commandes abandonnées, saisie ralentie, traitements de nuit qui débordent sur la matinée. Nous travaillons aussi bien avec une équipe de développement interne qu'avec l'éditeur de votre application, à qui nous transmettons des mesures exploitables plutôt qu'un ressenti.
Zone d'intervention
Applications servies à des clients du Bassin Genevois, hébergées sur le cloud public ou un OpenStack partenaire.
Ce que disent nos clients
Des PME et des indépendants du Bassin Genevois, suivis dans la durée.
« Mickael est super pro et très compétent. »
« Très professionnel, parfaitement parfait. »
« Très bon conseil, sympathique et réponse rapide. »
Questions fréquentes
Faut-il un test de charge pour chaque mission ?
Non, mais nous en réalisons un dès qu'il s'agit de valider un gain sous contrainte ou de préparer un pic connu. Le test est rejoué à l'identique avant et après les modifications, sur un environnement comparable à la production. Sans cette symétrie, une amélioration observée ne prouve rien.
Devez-vous modifier notre code applicatif ?
Souvent, car les corrections les plus rentables se trouvent dans les requêtes et dans la façon dont l'application dialogue avec la base. Nous pouvons travailler avec vos développeurs ou avec votre éditeur en leur transmettant des mesures précises. Quand aucune modification n'est possible, nous optimisons ce qui reste accessible.
L'optimisation fait-elle baisser la facture cloud ?
Parfois, quand un surdimensionnement disparaît, mais ce n'est pas automatique. Ajouter des réplicas, un cache distribué ou une diffusion de contenu améliore l'expérience et augmente la dépense. La maîtrise des coûts est un chantier distinct, que nous menons séparément pour que les résultats restent lisibles.
Et si notre sujet est un site WordPress lent ?
Le chantier n'a alors rien à voir avec une plateforme cloud, et le budget non plus. Le sujet relève de notre offre de maintenance WordPress, avec un travail sur les images, le cache et les extensions. Nous vous le disons dès le premier échange plutôt que d'ouvrir une mission d'expertise inutile.
Comment cette prestation est-elle facturée ?
Au taux journalier de 1000 HT. Nous chiffrons d'abord la phase de mesure, courte, puis le plan de corrections en journées à partir de ce que le diagnostic a révélé. Le suivi des indicateurs se poursuit ensuite dans un cadre de run.
Les autres prestations expertise cloud
Réalisations liées
Un projet, une panne, un rendez-vous.
Choisissez un créneau, ou décrivez votre besoin : nous répondons avec un périmètre clair, un prix hors taxes, et un interlocuteur nommé.