L' ordonnanceur du noyau Linux vient de recevoir une proposition de mise à jour qui fait grimper les perfs de façon assez spectaculaire sur certaines charges. Hygon, le fondeur chinois qui fabrique des x86 sous licence de l'architecture Zen d'AMD, a envoyé une série de patches pour étendre le cache-aware scheduling, et les chiffres annoncés montent jusqu'à 360% de mieux en termes de transactions par seconde sur MySQL.

Pour comprendre le délire, faut revenir au cache-aware scheduling de base, le fameux CAS, conçu par les ingénieurs d'Intel (Tim Chen, Chen Yu et Peter Zijlstra) et tout juste mergé dans Linux 7.2. Sur un CPU moderne avec plusieurs caches de dernier niveau, le fameux LLC, l'ordonnanceur essaie de regrouper sur le même domaine de cache les tâches qui partagent des données. Du coup, moins de ratés de cache, moins de données qui font des allers-retours entre les caches, et donc de la perf en plus sans toucher au matos mais juste en plaçant mieux les tâches.

Le hic, c'est que ce CAS de base raisonne au niveau d'un seul LLC. Tant que votre charge tient dans un domaine de cache, nickel. Mais dès que la charge dépasse ce que peut contenir un seul cache partagé, l'ordonnanceur ne sait pas regrouper les tâches au niveau du dessus : elles se dispersent sur des cœurs qui ne partagent plus le même cache, et toute la localité s'évapore. Et ça tombe mal pour Hygon, dont les puces récentes ne sont pas un bloc unique mais un assemblage de chiplets (le C86-7490 en réunit quatre), avec plusieurs caches partagés éparpillés sur la galette.

D'où l'idée de développer ces patches, qui permettent un regroupement hiérarchique et offrent la possibilité de s'étendre ou de se contracter dynamiquement selon la taille de la charge et la topologie de la machine.

Hygon annonce donc jusqu'à +49% sur Hackbench , +20% sur Schbench (non, pas le rappeur), et ce fameux +360% sur MySQL !! C'est le feu !

Maintenant, avant de revendre votre PC pour en prendre un sous Hygon, attention ! Ces chiffres, ce sont des "jusqu'à", mesurés sur des topologies multi-domaines, donc typiquement de gros serveurs à plusieurs chiplets. Sur votre laptop avec un seul LLC, vous ne verrez donc sans doute rien passer.... Ouais, je sais, sniiiif. Le 360% n'est pas un gain universel, mais plutôt le pic sur la config qui souffrait le plus du problème.

Un fondeur chinois qui, parti d'une licence Zen d'AMD, en vient à pousser du code dans Linux pour faire tourner tout le monde plus vite, Intel et AMD compris, c'est chouette quand même. Si ça vous intéresse, les patches viennent d'être postés sur la mailing list du kernel , donc rien n'est encore intégré mais si ça passe la revue, c'est de la perf gratuite pour les machines qui en bavent le plus.

Source

WordPress, c’est bien. Mais WordPress qui injecte des scripts d’emojis, des styles Gutenberg, des shortlinks et 47 autres trucs dont vous n’avez pas besoin dans chaque page de votre site… c’est moins bien évidemment. Heureusement, Terence Eden, un dev qui en avait marre de voir son code source ressembler à un plat de spaghetti, a compilé une petite liste de tout ce qu’on peut virer .

Car WordPress a adopté une philosophie de type “Decisions, not options” (des décisions, pas des options) où en gros, au lieu de vous laisser choisir, ils décident pour vous de ce qui est bon pour vous. Un peu comme Macron ^^. Le problème c’est que leurs décisions incluent un tas de fonctionnalités dont la plupart des gens n’ont rien à faire 🥲.

Par exemple les emojis. J’sais pas si vous savez, mais WordPress charge un script de détection d’emojis et une feuille de style dédiée sur CHAQUE page de votre site. Pourquoi tant de haine ? Hé bien parce que si vous tapez :-) dans un article, WordPress veut le transformer en joli emoji. Sauf que si vous utilisez les vrais emojis Unicode (comme tout le monde en 2025), hé ce script ne sert à rien. Et il y a aussi le grand remplacement des emojis dans les flux RSS…. Bref, tout ça, ça dégage.

Ensuite y’a le formatage automatique avec wptexturize qui transforme vos guillemets droits en guillemets typographiques “comme ça”. Et mon préféré, capital_P_dangit qui remplace automatiquement “Wordpress” par “WordPress” avec le P majuscule. Oui, vous ne le saviez pas, mais WordPress corrige l’orthographe de son propre nom dans vos articles. Mais quelle bande de nazes ^^.

Gutenberg, l’éditeur de blocs que j’adore, injecte lui aussi ses styles globaux même si vous utilisez l’éditeur classique. Et c’est pareil pour les styles de la librairie de blocs et l’éditeur de widgets basé sur les blocs. Si vous êtes resté sur le Classic Editor comme beaucoup de gens, tout ça ne sert alors qu’à alourdir vos pages.

Côté métadonnées, WordPress ajoute aussi pleiiiiin de trucs dans le code de vos pages comme les shortlinks, le RSD (Real Simple Discovery, un truc d’il y a 20 ans), des liens vers les flux de commentaires, les liens JSON de l’API REST…

Aux chiottes toutes ces conneries !

Le script de Terence fait aussi sauter l’ajout automatique des tailles d’images (wp_img_tag_add_auto_sizes), les templates de pièces jointes, et les block hooks qui modifient votre contenu. L’idée c’est donc de reprendre le contrôle sur ce que WordPress génère, au lieu de le laisser décider tout seul.

Et grâce à son script, le site de Terence (sans Philippe) obtient d’excellents scores sur PageSpeed Insights , ce qui prouve que tout ce bloat n’est vraiment pas nécessaire. Son script PHP complet fait environ 190 lignes et il est dispo sur son GitLab , bien commenté pour que vous puissiez choisir ce que vous voulez garder ou virer.

Attention quand même, certaines de ces désactivations peuvent casser des fonctionnalités si vous les utilisez vraiment. Par exemple, si vous avez des plugins qui dépendent de l’API REST, la virer complètement serait une mauvaise idée. Même chose pour les blocks Gutenberg si vous utilisez cet éditeur. L’astuce c’est donc de tester chaque modification une par une et de voir ce qui se passe.

Amusez-vous bien et un grand merci à Terence !

Alors rien à voir avec le logiciel de streaming, mais sachez que Harry Roberts, le consultant en performance web derrière CSS Wizardry (et accessoirement un mec qui a bossé avec Google, la BBC et l’ONU), vient de sortir Obs.js .

L’idée de ce truc, c’est de transformer votre site web en véritable caméléon. Au lieu de servir la même expérience à tout le monde, la bibliothèque va détecter en temps réel les conditions de navigation de chaque visiteur. Batterie presque vide ? Connexion 2G pourrie ? Le site s’adapte automatiquement.

Pour cela, Roberts utilise des APIs natives du navigateur qui existent depuis des années mais que presque personne n’exploite vraiment. La Battery Status API et la Network Information API sont là, dans Chrome et consorts, à attendre qu’on leur trouve une utilité. Et voilà, Obs.js débarque et les combine de façon intelligente pour créer quelque chose de vraiment utile.

Mais alors concrètement, ça donne quoi ?

Et bien ce script ajoute des classes CSS directement sur votre balise <html>, comme ça…

<html class="has-latency-low
 has-bandwidth-high
 has-battery-charging
 has-connection-capability-strong
 has-conservation-preference-neutral
 has-delivery-mode-rich">

.has-battery-critical * {
 animation: none !important;
 transition: none !important;
}

body {
 background-image: url('banner-4k.jpg');
}

.has-delivery-mode-lite body {
 background-image: url('banner-optimized.jpg');
}

Si votre machine rame comme un vieil escargot devant une commission d’enquête au sujet de l’affaire Bétharram, alors j’ai un super outil pour vous. Ça s’appelle NeoHTop et ça permet de visualiser l’ensemble des processus qui tournent sur votre système ainsi que les ressources disponibles, tout ça au travers d’une interface moderne, jolie, et surtout super rapide puisque c’est codé en Rust !

Donc si vous en avez marre des interfaces en mode années 90 de top ou htop, ou si le Moniteur d’activité de macOS vous donne envie de pleurer à chaque fois que vous devez trouver quel processus bouffe toute votre RAM, NeoHtop va vous réconcilier avec le monitoring système.

Hello à tous,

Dans une précédente vidéo, nous avions découvert ensemble comment créer et configurer un site WordPress avec o2switch, cet hébergeur français qui propose des offres complètes et adaptées à tous les types de projets web.

Et aujourd’hui, nous allons aller encore plus loin en explorant les outils d’optimisation de performances proposés par o2switch pour transformer votre site en véritable fusée !

Car vous le savez, la vitesse de chargement d’un site web est cruciale, non seulement pour l’expérience utilisateur mais aussi pour le référencement. En effet, Google pénalise les sites lents et récompense ceux qui s’affichent rapidement, alors c’est pourquoi il est essentiel d’optimiser au maximum les performances de votre site, que ce soit un WordPress ou autre chose.

Vous en aviez marre des analyseurs de code Python plus lents qu’un escargot sous Xanax ? Et bien dites bonjour à pylyzer, la nouvelle star de l’analyse statique ! 🚀

Ce p’tit truc est écrit en Rust, ce qui lui permet d’être en moyenne 100 fois plus rapide que ses concurrents comme pytype ou pyright. En plus de la vitesse, pylyzer se distingue par son analyse ultra détaillée. On parle pas juste de type checking basique là, pylyzer est capable de détecter les accès hors limites à des listes ou les accès à des clés inexistantes dans des dictionnaires.

D’ailleurs, contrairement à ce qu’on pourrait penser, pylyzer n’est pas qu’un simple type checker. C’est un véritable couteau suisse de l’analyse statique ! Il fait aussi office de linter pour vous aider à garder un code propre et consistant.

Bon après, faut pas se leurrer, pylyzer a ses limites. Déjà, il suppose que votre code est potentiellement statiquement typé, donc oubliez les exec, setattr et compagnie. Ah et le typage de l’API standard de Python n’est pas complet donc vous risquez de voir des erreurs du genre « cette API n’existe pas », soyez prévenus ! Enfin, vu que le type checking de pylyzer est conservatif dans son approche, vous risquez de voir pas mal de faux positifs. Si ça vous saoule, désactivez les diagnostics, on ne vous en voudra pas (mais je vous le déconseille quand même) ! 😅

En parlant d’accès, vous n’aurez aucun mal à accéder aux rapports d’erreur de pylyzer car contrairement à certains, ils sont clairs comme de l’eau de roche ! Fini le charabia illisible, on vous montre exactement où se situe l’erreur et on vous explique le problème sans prise de tête. Et côté fonctionnalités, pylyzer ne fait pas les choses à moitié. Le support LSP est hyper riche, de la complétion au renommage en passant par plein d’autres features bien cool. Tout ça grâce à l’adaptation du serveur de langage de Erg. Et si vous voulez en profiter directement dans VSCode, pas de souci ! L’extension est dispo sur le Marketplace et hop, c’est réglé ! 😎

Maintenant vous allez me dire « OK c’est bien beau tout ça, mais pylyzer il sert à quoi comparé à Ruff par exemple ?« . Alors oui, Ruff est aussi un outil d’analyse statique pour Python écrit en Rust, mais lui se concentre uniquement sur le linting tandis que pylyzer fait du type checking et sert de serveur de langage. En gros, on ne mélange pas les torchons et les serviettes !

Si vous voulez savoir comment ça marche dans le détail, sachez que pylyzer utilise le type checker de Erg en interne, en plus de ses propres capacités de vérification de type. Il convertit l’AST Python en AST Erg avant de le passer au type checker, puis il adapte les résultats pour Python. Malin ! 😏 Par contre, Erg n’est pas un langage transpilé en Python comme on pourrait le croire, il peut tourner directement sur la machine cible.

Malgré ces petits défauts, pylyzer gère quand même un paquet de trucs : type checking sur les variables, opérateurs, fonctions, méthodes et classes, inférence de type, résolution des modules et packages, les types des collections (list, dict, tuple), une bonne partie de typing, les types génériques et variance, les type guards, le type narrowing (qui peut se faire avec is et isinstance mais pas que), les assertions de type (via typing.cast par exemple)… Bref, ça en fait des belles jambes dis donc ! 🦿

Alors vous attendez quoi pour tester ce petit bijou ?

Aujourd’hui, on va causer d’un sujet qui nous tient tous à cœur (du moins je l’espère 😅) : les outils de crise sous Linux ! Parce que quand ça part en sucette et que les serveurs rament, pas question de perdre un temps précieux. C’est que souvent, quand la caca-strophe pointe le bout de son nez, vous vous rendez compte que vous n’avez pas les bons outils installés. Et là, c’est le drame… SSH qui rame, les serveurs qui répondent plus, les paquets qui veulent pas s’installer, le firewall qui fait des siennes… Un vrai calvaire !

Alors, quels sont ces fameux outils qu’il est impératif d’avoir sous la main quand le caca touche le ventilo ? Je dirais que y a déjà les classiques comme ps, vmstat, top et compagnie pour avoir un aperçu rapide de ce qui cloche. Rien que ça, ça peut déjà vous sauver les miches.

Mais si vous voulez jouer dans la cour des grands, va falloir sortir l’artillerie lourde. Je parle bien sûr des outils de tracing comme perf, bpftrace, opensnoop, execsnoop et toute la clique. Ça vous permettra de tracer en live ce qui se passe sur votre système, de débusquer les coupables et de mettre fin au carnage. Le top du top !

Voici comment procéder à grand coups d’apt install…

Étape 1 : Installer les packages de base

• procps : fournit ps, vmstat, uptime, top pour les stats de base
• util-linux : dmesg, lsblk, lscpu pour les logs systèmes et infos matérielles
• sysstat : iostat, mpstat, pidstat, sar pour les stats disques/CPU
• iproute2 : ip, ss, nstat, tc, les outils réseau recommandés
• numactl : numastat pour les stats NUMA

Commande : sudo apt install procps util-linux sysstat iproute2 numactl

Étape 2 : Ajouter les outils réseaux

• tcpdump : sniffer réseau
• nicstat : stats interfaces réseau
• ethtool : infos interfaces

Commande : sudo apt install tcpdump nicstat ethtool

Étape 3 : Outils de profilage et de traçage

• linux-tools-common et linux-tools-$(uname -r) : perf, turbostat
• bpfcc-tools (ou bcc) : une suite d’outils eBPF puissants
• bpftrace : un outil de scripting eBPF dynamique
• trace-cmd : outil en ligne de commande pour ftrace

Commande : sudo apt install linux-tools-common linux-tools-$(uname -r) bpfcc-tools bpftrace trace-cmd

Étape 4 (optionnelle) : Outils spécifiques au matériel

Selon vos serveurs, installez les outils d’analyse pour :

• GPU Intel : intel-gpu-tools
• GPU NVIDIA : nvidia-smi
• Autres accélérateurs éventuels

Par contre, méfiez-vous, c’est pas donné à tout le monde de dompter ces bêtes-là. Ça demande un peu de bouteille et de la jugeote. Mais une fois que vous les maîtrisez, vous serez parés pour affronter les pires galères. Les plantages intempestifs, les I/O de l’enfer, les fuites mémoire vicieuses… plus rien ne vous résistera !

Bref, croyez-moi, le mieux c’est d’avoir tout ce bazar installé d’office sur vos machines. Comme ça, pas de mauvaise surprise le jour J. Évidemment, ça a un petit coût en espace disque. Mais franchement, c’est que dalle comparé au temps que vous allez perdre à galérer pour installer tout ça en pleine crise.

Sur ce, je vous laisse méditer là-dessus. Et n’oubliez pas, dans le monde merveilleux de l’informatique, il vaut mieux prévenir que guérir ! Allez, à plus les linuxiens et un grand merci à Brendan Gregg pour son article éclairant à ce sujet.

Aujourd’hui, je vous parle d’un truc vraiment cool nommé Jampack. En gros, c’est un outil qui prend votre site statique généré par votre générateur préféré (Hugo, Jekyll, Eleventy… y’en a pour tous les goûts !) et qui le transforme en une bête de course optimisée pour une expérience utilisateur de folie et des scores Core Web Vitals à faire pâlir les GAFAM.

Comment ça marche ce truc ? Eh bien, Jampack va scanner votre site et appliquer tout un tas d’optimisations automatiquement. Par exemple, il va :

• Rendre vos images responsive avec des dimensions et des formats modernes comme le WebP ou l’AVIF. Fini les images qui mettent trois plombes à charger !
• Mettre la priorité sur les assets importants au-dessus de la ligne de flottaison et lazy-loader le reste. Comme ça, votre site s’affiche direct pendant que le reste charge tranquillou en arrière-plan.
• Inliner le CSS critique et virer le Flash of Unstyled Content (FOUC). Votre site aura la classe dès les premières millisecondes.
• Prefetcher les liens pour accélérer la navigation. Vos visiteurs surferont à la vitesse de la lumière sur votre site !
• Minifier et compresser tout ce qui traîne : HTML, CSS, JS, SVG… Que du bonheur pour votre bande passante.

Et tout ça sans que vous ayez à lever le petit doigt ! Juste un petit

npm install -D @divriots/jampack

et hop, magie, votre site est optimisé de fou.

Bon, vous vous dites peut-être : « Ouais, ok, mais mon site il est déjà pas mal optimisé, hein« . Eh bah, sachez que même les experts de Keycloak.ch, BayJS.org ou CloudCannon.com utilisent Jampack pour squeeze encore plus de perf. Vous pensez vraiment faire mieux ? ^^

Et bien sûr, tout le code est open-source sur GitHub, sous licence MIT. Allez, sur ce, je vous laisse, j’ai un site à optimiser moi. See ya !

A découvrir ici.

Concocté par le français Kévin Dunglas, contributeur de longue date à l’écosystème PHP et membre de la Core Team Symfony, FrankenPHP va peut-être dépoussiérer un peu votre bon vieux serveur LAMP tout fatigué.

Il s’agit d’un serveur d’applications PHP moderne développé en Go qui s’appuie sur le serveur web de pointe Caddy. D’après son auteur, tous vos projets PHP, y compris Laravel, Symfony, Drupal, WordPress, Sulu et API Platform, seront optimisés comme jamais grâce à l’intégration native du mode worker.

Moins de lenteurs, plus de perf, et surtout pas mal de fonctionnalités avancées telles que les Early Hints pour un affichage éclair, la prise en charge d’HTTP/2 et HTTP/3 pour une navigation optimale, la compression Brotli, Zstandard et Gzip, les logs structurés, le support de Prometheus pour les métriques, et même du temps réel avec Mercure. Que vous soyez accro à Symfony, fan d’API Platform ou un inconditionnel de Laravel, FrankenPHP s’occupera de tout et d’après les benchmarks visibles sur le site officiel, il booste même les performances jusqu’à 3,5 fois plus vite que FPM sur les applications de type API Platform.

Conçu dans un souci de simplicité, ce serveur PHP n’a besoin que d’un seul service et d’un seul binaire. Pas besoin de PHP-FPM, il utilise son propre SAPI (Server API) spécialement conçu pour les serveurs web Go. Il peut être déployé facilement comme une application Cloud Native via une image Docker, et est compatible avec Kubernetes et toutes les plateformes Cloud modernes. Vous pouvez même packager votre application PHP comme un binaire statique autonome et auto-exécutable.

Si vous voulez le tester, vous pouvez soit lancer le binaire, soit utiliser Docker comme ceci :

docker run -v $PWD:/app/public -p 80:80 -p 443:443 -p 443:443/udp dunglas/frankenphp

En deux temps trois mouvements, vous voilà avec un serveur web + PHP 8.2 aux petits oignons ! Y’a plus qu’à mettre votre PHP dans le répertoire de Franken et tadaaa…

Si c’est le binaire que vous récupérez, vous pouvez servir le contenu du répertoire courant avec la commande suivante :

./frankenphp php-server

Ou lancer vos scripts en ligne de commande comme ceci :

./frankenphp php-cli /chemin/vers/votre/script.php

Bref, vous démarrez votre app une fois, et hop, elle reste en mémoire, prête à faire tourner votre site. Caddy gère l’HTTPS automatiquement avec génération, renouvellement et révocation des certificats. Il sert aussi les assets, pendant que PHP fait ce qu’il fait de mieux : exécuter votre code sans faillir. Vous pouvez même intégrer PHP dans n’importe quelle application Go en mode bibliothèque.

Et pour démarrer un serveur Caddy en prod avec FrankenPHP sans utiliser Docker, il suffit de cette configuration ultra simple:

{
    # Activer FrankenPHP 
    frankenphp
    order php_server before file_server
}

localhost {
    # Activer la compression (optionnel)
    encode zstd br gzip  
    # Exécuter les fichiers PHP dans le répertoire courant et servir les ressources
    php_server
}

Ça change un peu !

En tout cas, c’est à tester ! Bravo Kévin, j’ai hâte de voir comment ça va évoluer pour la suite !