Cloudflare a annoncé la disponibilité du profilage à la demande de l’utilisation du processeur et de la mémoire pour les services Workers et Durable Objects. Les développeurs peuvent ainsi recueillir des profils directement depuis l’environnement de production et les afficher sous forme de flame graphs interactifs. Cette fonctionnalité permet d’identifier les fonctions qui consomment du temps processeur ou allouent le plus de mémoire, au lieu de s’appuyer uniquement sur les journaux et les indicateurs agrégés.
Le profilage peut être lancé depuis la page Workers Observability du tableau de bord Cloudflare ou via l’interface en ligne de commande. Le développeur choisit le type de profil, CPU ou memory, ainsi que la durée de collecte, et peut également sélectionner différentes versions du Worker. À la fin de la session, il est possible de consulter le graphique interactif et de télécharger le fichier de profil pour l’analyser avec d’autres outils.
Que montrent les flame graphs ?
Chaque rectangle du graphique représente un appel de fonction, tandis que sa largeur indique la quantité de temps processeur ou de mémoire qui lui est associée. Il est possible de cliquer sur les fonctions pour les examiner plus en détail ou d’utiliser la vue en tableau pour trier les résultats selon le nombre d’échantillons. Cloudflare recommande de capturer plusieurs profils et de rechercher les fonctions les plus larges, tout en activant les source maps dans les projets TypeScript afin d’éviter que les noms des fonctions apparaissent de manière ambiguë.
Le profilage nécessite de sélectionner une version déployée qui reçoit suffisamment de trafic : le service ne crée pas de nouvel isolement à des fins de mesure, car l’objectif est de surveiller l’exécution réelle en production. La commande suivante permet de capturer un profil CPU d’une durée de cinq secondes :
cf workers versions profile latest --worker-id "$WORKER_ID_OR_NAME" --duration-ms 5000 --profile-type cpu > worker-cpu.pprof
Résultats pratiques présentés par Cloudflare
Cloudflare a utilisé l’outil pour analyser un Worker qui applique un mappage R2. Le profilage a montré que la fonction genericR2JsonReplacer parcourait de nouveau un arbre JSON pendant l’exécution de JSON.stringify, ce qui entraînait, dans certains cas, le traitement d’une valeur imbriquée à cinq reprises. La correction a rendu la fonction 2,7 fois plus rapide. Le profilage a également révélé un appel répété à metrics : stocker le résultat et le réutiliser a suffi à réduire la consommation du processeur.
Dans un autre cas, un Worker dépassait la limite de mémoire de 128 mégaoctets : la consommation P999 atteignait environ 133 mégaoctets, ce qui provoquait des erreurs « Exceeded Memory ». Le profil du tas a montré que le code Prometheus responsable d’environ 66,7 % des allocations fonctionnait encore partiellement, alors qu’il était supposé être désactivé. Après la suppression complète du chemin de code, le P999 est passé de 133 à 118 mégaoctets, tandis que le P50 a reculé de 70 à 54 mégaoctets.
Qu’est-ce qui change concrètement ?
Cette fonctionnalité donne aux équipes de développement une visibilité directe sur l’exécution des Workers dans leurs conditions réelles, où le trafic et la répartition des isolements peuvent différer de l’environnement de développement local. La plateforme gère la complexité liée à la distribution des Workers entre plusieurs centres de données et appareils, tandis que, dans Durable Objects, le développeur peut désigner l’objet par son nom afin d’obtenir un profil correspondant précisément à l’isolement qui l’exécute.
Le mécanisme d’exécution continue d’accepter les requêtes pendant la collecte : le verrou de l’isolement n’est retenu qu’au démarrage et à l’arrêt du profilage, puis les échantillons CPU sont recueillis à intervalles d’une milliseconde pendant la durée définie. Les Durable Objects tirent quant à eux parti de leur nature avec état pour acheminer la requête de profilage vers l’isolement et le détenteur de l’objet désigné.
Limites et prochaine étape
Le profilage ne démarre pas automatiquement, ce qui signifie que la session peut manquer les périodes courtes ou rares pendant lesquelles le problème survient. Le profileur mémoire affiche uniquement les allocations effectuées pendant la fenêtre de mesure et ne détecte pas nécessairement la consommation liée au démarrage. Cloudflare indique travailler sur le profilage continu, qui recueillera automatiquement les échantillons et permettra de les consulter ultérieurement depuis le tableau de bord.