Sujet : performance
-
Le profilage continu en production : des profils par échantillonnage permanents et les questions auxquelles ils répondent
Le profilage continu recueille systématiquement des profils CPU et mémoire au fil du temps et les stocke sous forme de séries étiquetées, pour savoir quelle fonction a le plus consommé de CPU hier sur l'ensemble du parc ou ce qui a changé entre deux versions ; les profileurs par échantillonnage rendent cette collecte assez peu coûteuse pour rester active en permanence, et les points d'accès des environnements d'exécution, comme /debug/pprof/ de Go, ou les agents eBPF fournissent les profils.
-
Résumer le temps passé dans les appels système avec strace -c, son surcoût et perf trace comme alternative
strace -c comptabilise le temps, le nombre d'appels et les erreurs par appel système au lieu d'afficher chaque appel, mais le manuel de strace avertit qu'un processus tracé s'exécute plus lentement qu'un processus non tracé ; perf trace, décrit comme un outil inspiré de strace et reposant sur perf_events plutôt que sur ptrace, est l'alternative plus légère lorsque ce surcoût pose problème.
-
Mesurer les performances d'un changement : échauffement, répétitions, variance et résultats à présenter
Une comparaison de temps d'exécution ne constitue un résultat que si elle résiste au bruit : fixer la charge de travail, écarter les exécutions d'échauffement, alterner de nombreuses répétitions de chaque variante, choisir la statistique avant d'examiner les données et indiquer la dispersion et l'environnement à côté de chaque chiffre. Une différence inférieure à la dispersion entre exécutions n'est pas un résultat.
-
Premier regard sur les performances de Solaris : prstat, vmstat, mpstat, iostat et zpool iostat
prstat -a/-Z, vmstat, mpstat, iostat -xnz et zpool iostat : cinq commandes en lecture seule qui répondent à la plupart des premières questions de performance sous Solaris 11.4, avec une gestion des zones et un détail de latence disque que les outils Linux de même nom présentent différemment.
-
La méthode USE pour trouver les goulets d’étranglement
Pour chaque ressource (CPU, mémoire, disques, réseau, verrous), vérifier l’utilisation, la saturation et les erreurs ; la méthode USE est une liste de contrôle qui repère rapidement les goulets d’étranglement sans commencer par des suppositions sur la couche applicative.
-
Compression des réponses : où la faire et quoi en exclure
Compresser les réponses textuelles (HTML, JSON, Markdown) au niveau du proxy ou de l'application, ignorer le contenu déjà compressé et le contenu en streaming, garder des ETags honnêtes à travers les encodages, et définir Vary: Accept-Encoding.
-
Quelle part du contexte d'un agent est constituée de sortie d'outils dans des exécutions réelles, et son élagage change-t-il la réussite de la tâche ?
Question ouverte : la spécification MCP indique que les clients devraient valider les résultats d'outils avant de les transmettre au modèle, mais laisse la quantité à la discrétion du client ; dans des exécutions d'agents enregistrées, quelle proportion des jetons est constituée de sortie d'outils plutôt que d'instructions ou de raisonnement, et le fait de tronquer, résumer ou filtrer la sortie des outils change-t-il la réussite de la tâche, le coût et la latence ?
-
Images adaptatives avec srcset, sizes et picture
srcset avec des descripteurs de largeur, associé à un attribut sizes, permet au navigateur de choisir le fichier image le plus petit qui remplit l'emplacement pour le viewport et la densité de pixels actuels ; les descripteurs x servent des images de taille fixe à plusieurs densités ; picture avec des éléments source gère la direction artistique et le repli de format. Toujours conserver width et height pour que la mise en page ne bouge pas pendant le chargement de l'image.
-
Échantillonner les compteurs de performance de Windows Server avec Get-Counter et les exporter en CSV
Get-Counter échantillonne des chemins de compteurs nommés à intervalle choisi, en continu ou sur un nombre fixe d'échantillons. Export-Counter (Windows PowerShell 5.1 uniquement) conserve tous les champs au format natif BLG, et relog convertit ensuite une capture en CSV, même sans la commande Export-Counter d'origine.
-
Générer, critiquer, réviser : quand une boucle d'auto-vérification est rentable
Une boucle dans laquelle le modèle critique et révise sa propre sortie améliore les résultats lorsque la critique dispose d'un signal externe (tests, un validateur, une source) et d'une grille fixe ; sans cela, des résultats publiés montrent qu'elle peut dégrader les réponses, et chaque tour ajoute au moins deux appels dont l'entrée croît avec le brouillon.
-
VACUUM, autovacuum et le ballonnement des tables
Le MVCC de PostgreSQL laisse derrière lui des versions de lignes mortes après les mises à jour et les suppressions ; VACUUM les récupère et maintient les statistiques ainsi que la protection contre le rebouclage des identifiants de transaction. Autovacuum devrait rester activé et être ajusté pour les tables très sollicitées.
-
Chargement des polices web : font-display, préchargement, sous-ensembles unicode-range et solutions de repli calées sur les métriques
Afficher le texte dès le premier rendu et charger la police de marque sans saut de mise en page : sous-diviser les fontes avec unicode-range pour ne télécharger que les écritures utilisées, choisir font-display selon le rôle (optional pour le corps de texte, swap pour les titres), précharger les fichiers du premier rendu avec crossorigin, et déclarer une fonte de repli avec size-adjust et des overrides ascent/descent pour que les lignes s'enroulent de la même façon avant et après la bascule.
-
Les builds en modules ES avec effets de bord déclarés réduisent davantage les paquets des consommateurs que les builds CommonJS
Hypothèse : pour une bibliothèque composée de nombreuses fonctions indépendantes, un consommateur qui en importe quelques-unes obtient un paquet plus petit lorsque la bibliothèque distribue des modules ES avec une déclaration sideEffects que lorsqu'elle distribue du CommonJS, parce que le tree shaking dépend de la structure statique import/export ; une comparaison fondée sur des fixtures est proposée.
-
Quand asyncio aide, et quand ce n'est pas le cas
asyncio exécute de nombreuses tâches limitées par les entrées-sorties (I/O) sur un seul thread en se suspendant aux points await ; il n'accélère pas le code limité par le calcul (CPU), et les appels bloquants à l'intérieur des coroutines bloquent toute la boucle.
-
Web Vitals : ce que mesurent LCP, INP et CLS
Les Core Web Vitals sont trois métriques de terrain : Largest Contentful Paint (temps de rendu du plus grand élément visible, cible 2.5 s), Interaction to Next Paint (latence de la plus longue interaction, cible 200 ms) et Cumulative Layout Shift (mouvement inattendu, cible 0.1), chacune évaluée au 75e centile des chargements de page.
-
Quand le routage côté client reste-t-il rentable maintenant que les navigateurs offrent bfcache, le prérendu et les transitions de vue entre documents ?
Question ouverte : les routeurs internes à la page ont été adoptés pour éviter les rechargements complets de page, au prix de la desserte d'une coquille (shell), de la gestion des 404, de la restauration du défilement et du focus, et d'un paquet (bundle) qui doit arriver en premier ; le cache avant/arrière (back/forward cache), la Speculation Rules API et les transitions de vue entre documents répondent désormais aux motivations d'origine dans les sites multipages. Pour quels sites et quels schémas d'interaction un routeur interne à la page l'emporte-t-il encore de façon mesurable ?
-
Trouver une fuite de mémoire avec des instantanés tracemalloc
Démarrer le traçage tôt avec PYTHONTRACEMALLOC ou tracemalloc.start(nframe), prendre un instantané après la montée en charge puis un autre après N itérations, filtrer le bruit des imports, et lire compare_to(..., 'lineno') pour repérer les lignes dont la taille croît proportionnellement à N ; passer au regroupement 'traceback' pour voir les appelants.
-
Diagnostic de performance depuis le Terminal macOS : top, vm_stat, memory_pressure, fs_usage et powermetrics
macOS fournit des outils d'origine BSD ou propres à Apple qui recoupent ce que font top, vmstat, iostat et strace sous Linux, mais avec d'autres noms, d'autres unités et d'autres exigences de privilèges : top -o cpu, vm_stat, memory_pressure, iostat, fs_usage, powermetrics et sample <pid>.
-
CPU et E/S par processus avec pidstat et /proc/<pid>/io : identifier la cause de l'attente d'E/S
pidstat affiche le CPU, la mémoire et les E/S disque par tâche, sans avoir à filtrer un nom dans top. La lecture directe de /proc/<pid>/io distingue les E/S logiques (rchar/wchar, cache compris) des read_bytes/write_bytes, qui correspondent aux octets atteignant réellement le périphérique.
-
Choisir entre threads, processus et asyncio pour une charge de travail Python
Classer d'abord le chemin critique : l'attente d'E/S convient à asyncio (nombreuses connexions, bibliothèques asynchrones) ou à un pool de threads (peu d'appels bloquants) ; le calcul Python pur nécessite des processus ou une build sans GIL (free-threaded). Le code natif qui libère le GIL peut utiliser des threads. Borner chaque pool, choisir explicitement la méthode de démarrage des processus et écrire le chemin d'arrêt.
Lisible par machine : JSON