- Dans le benchmark du développeur indépendant Theo Browne, Cloudflare Workers s’est révélé jusqu’à 3,5 fois plus lent que Vercel Node.js
- Les causes de ces résultats provenaient de plusieurs problèmes liés à l’infrastructure, à la configuration des bibliothèques et à la méthodologie du benchmark
- De nombreuses améliorations de la plateforme et du framework ont été apportées, notamment une refonte de l’algorithme d’ordonnancement, un réglage du garbage collector de V8 et des optimisations d’OpenNext
- Grâce à ces correctifs majeurs, l’écart de performance entre Cloudflare et Vercel a désormais fortement diminué dans la plupart des benchmarks
- À l’avenir, Cloudflare prévoit de continuer à contribuer à l’amélioration de l’infrastructure publique et des frameworks, tout en poursuivant les optimisations et la validation des benchmarks
Vue d’ensemble et controverse autour du benchmark
- En octobre 2023, le développeur Theo Browne a publié un benchmark comparant la vitesse d’exécution côté serveur de JavaScript sur Cloudflare Workers et sur Vercel (basé sur AWS Lambda)
- Cloudflare Workers repose sur le moteur JavaScript V8, comme Vercel, mais une baisse de performances allant jusqu’à 3,5 fois a été observée
- Un écart de performances déraisonnable est apparu en raison de plusieurs facteurs, comme un micro-réglage de l’infrastructure, des différences entre bibliothèques JavaScript et des problèmes dans la méthode de test
- Le processus de correction de ces problèmes a permis d’améliorer les performances globales de Cloudflare Workers
- Parmi les principaux correctifs figurent aussi des améliorations pouvant bénéficier à d’autres plateformes, comme l’accélération des calculs trigonométriques
Méthodologie du benchmark
- Le client de test initial de Theo accédait au service depuis San Francisco via Webpass, tandis que Vercel s’exécutait dans la région
sfo1
- Côté Cloudflare, la communication avec l’instance
iad1 de Vercel s’effectuait directement depuis un datacenter AWS us-east-1, afin de minimiser l’impact de la latence réseau
- Tous les benchmarks ont été réalisés dans un environnement mono-thread (1 vCPU), ce qui facilitait aussi la comparaison des coûts
- Les bugs découverts pendant les tests ont été soumis en amont via des Pull Requests puis corrigés
Améliorations des performances de la plateforme Cloudflare
Améliorations de l’ordonnancement et de l’isolation dans le runtime Workers
- Jusqu’ici, un algorithme orientant le trafic vers des isolats « chauds » (instances prêtes à traiter rapidement) était utilisé pour optimiser la latence et le débit des applications à grande échelle, mais il était inefficace pour les charges fortement consommatrices de CPU
- Lorsque de nombreuses requêtes monopolisaient fortement le CPU, les files d’attente s’allongeaient et la latence augmentait, ce que le benchmark a mis en évidence
- Comme la facturation de Cloudflare Workers est basée sur le temps CPU utilisé, le temps d’attente (par exemple avant la préparation d’un isolat) n’est pas facturé
- Une refonte de l’algorithme a permis de détecter plus rapidement les charges à forte consommation CPU et de créer plus vite de nouveaux isolats
- Le système réagit désormais efficacement aussi bien aux charges I/O-bound qu’aux charges CPU-bound, avec un déploiement mondial immédiat
Amélioration des réglages du garbage collector de V8
- Les tests ont confirmé que les problèmes de garbage collection et de gestion mémoire en JavaScript avaient un impact important sur les performances
- La taille de la zone mémoire « young generation » du moteur V8 était figée de manière trop restrictive (sur l’ancienne recommandation de 128 Mo)
- Sur les versions récentes de V8, cette méthode de configuration provoquait au contraire des GC fréquents et inutiles
- Le réglage manuel a été supprimé afin de laisser V8 gérer une allocation mémoire dynamique basée sur ses propres heuristiques
- Une amélioration d’environ 25 % des performances sur les benchmarks a été constatée, puis appliquée à tous les Workers
Optimisations de performances Next.js basées sur OpenNext
Suppression des allocations mémoire et copies inutiles
- L’analyse a montré que 10 à 25 % du temps de traitement des requêtes était consacré à la libération mémoire (GC)
- OpenNext, Next.js et React contenaient de nombreux motifs de code copiant excessivement les buffers de données internes
- Cela incluait la copie inutile de l’intégralité des données de sortie d’un flux, ou de gros volumes de données copiés via
Buffer.concat dans le seul but de mesurer leur longueur
- Les problèmes concernés sont en cours d’amélioration via des Pull Requests dans le dépôt OpenNext
- L’objectif est de continuer à affiner ces changements afin qu’ils apportent des gains de performances communs à l’ensemble de la plateforme
Optimisation d’adaptateurs de flux inefficaces
- Workers s’appuie sur la Web Streams API, tandis que Next.js est principalement conçu autour de l’API de streams de Node.js, ce qui nécessite des adaptateurs de conversion
- L’usage inutile d’adaptateurs imbriqués entraînait de nombreuses surcharges de copie mémoire et de buffering
- Le code a été simplifié en utilisant
ReadableStream.from(chunks), ce qui a supprimé les copies intermédiaires
- La structure de flux à valeur unique par défaut (
highWaterMark=1) a été remplacée par des flux d’octets (highWaterMark=4096, etc.) afin d’optimiser le traitement de gros volumes de données
- Des correctifs destinés à améliorer le traitement des flux dans Next.js et React seront également remontés en amont vers les plateformes supérieures
Problème de performances de JSON.parse() et correctif V8
- Dans Next.js et React, l’usage de
JSON.parse() avec l’option reviver entraînait un nombre excessif d’appels (plus de 100 000)
- Le standard ECMAScript récent permet désormais de recevoir un troisième argument (contexte source) dans le reviver, ce qui a encore aggravé les performances, de manière commune à Firefox, Chrome, etc.
- L’équipe Cloudflare Workers a proposé un correctif au moteur V8 (amélioration de 33 % des performances), dont bénéficieront à terme tout l’écosystème, y compris Node.js, le navigateur Chrome et Deno
Problème de performances des fonctions trigonométriques dans Node.js
- Indépendamment du benchmark de Theo, un benchmark répétant des appels à des fonctions trigonométriques (
sin, cos, etc.) a montré que Cloudflare Workers était 3 fois plus rapide
- La cause était que Node.js n’avait pas encore pris en charge le chemin trigonométrique le plus récent et le plus rapide fourni par V8 (via un compile-time flag)
- Cloudflare Workers avait ce flag activé par défaut par hasard, et un correctif a été soumis à Node.js via Pull Request
- Comme ce problème concerne aussi l’écosystème open source dans son ensemble, son intégration future dans AWS Lambda et Vercel devrait également stabiliser les performances globales
Limites de conception et de mesure du benchmark, et enseignements
- Les benchmarks reposaient majoritairement sur une mesure du temps de requête (latence) côté client, sans mesurer directement le temps CPU réellement consommé côté serveur
- Le chemin réseau, la localisation des datacenters, la génération du matériel, la multi-location et d’autres variables difficilement comparables peuvent influencer les résultats
- Lorsqu’on ne mesure que le temps d’arrivée du premier octet (TTFB), il est difficile de refléter le temps total de rendu/transfert ; passer au TTFL peut au contraire rendre la mesure plus sensible aux différences de vitesse réseau
- La diversité du matériel et des logiciels côté serveur, ainsi que l’aléa dans l’attribution des instances, introduisent aussi du bruit temporaire ou corrélé
- La clarification des environnements et des workflows de benchmark, ainsi que l’alignement des variables, ont permis d’identifier des améliorations concrètes utiles aussi bien pour leur propre plateforme que pour celles des autres
Problèmes découverts pendant les expériences dans le benchmark et la configuration de l’environnement
- L’absence d’application du réglage
force-dynamic de Next.js, la logique de cache et les différences de mode de streaming des réponses pouvaient conduire à une mauvaise interprétation des résultats
- Dans le benchmark React SSR, la variable d’environnement
NODE_ENV n’était pas définie, ce qui activait le mode dev et produisait des résultats plus lents que la réalité
- Ces erreurs ont été corrigées en définissant explicitement les variables d’environnement
Plan pour la suite et conclusion
- Les différentes améliorations de performances du runtime Cloudflare Workers sont déjà déployées à grande échelle, et les utilisateurs en bénéficient sans action particulière
- Des Pull Requests intégrant le code de test et les optimisations OpenNext ont été fournies à Theo
- D’autres améliorations sont prévues pour réduire l’écart entre OpenNext et Next.js basé sur Vercel
- Cloudflare compte continuer à faire évoluer son algorithme d’ordonnancement et les moteurs open source (V8, Node.js), tout en contribuant à la communauté
- De meilleurs benchmarks et outils de profiling doivent permettre de détecter plus tôt les problèmes potentiels, de poursuivre les optimisations et de maintenir une culture de partage
Références et liens complémentaires
1 commentaires
Discussion sur Hacker News
C’est une bonne chose que CF fasse réellement des efforts pour améliorer son produit. Mais les changements vont tellement vite qu’il est difficile de suivre, et les lancements devancent souvent la maturité du produit. Par exemple, R2 Data Catalog manque toujours de support pour Iceberg v3, Wrangler a déjà beaucoup changé en seulement quelques mois, et Pages semble sur le point de disparaître, ce qui rend la migration vers Workers Assets extrêmement pénible. Une configuration qui fonctionnait très bien avec Wrangler 3 ne s’appliquait pas correctement avec Wrangler 4, et on a l’impression que Wrangler 5 introduira encore un nouveau modèle d’interaction
À propos de « Pages semble sur le point de disparaître », CF a indiqué dans un post de la communauté qu’ils ne supprimeront pas Pages tant que Workers n’aura pas atteint le même niveau Post lié Il est difficile de trouver une annonce officielle disant que Pages serait abandonné, et pages.cloudflare.com comme developer.cloudflare.com/pages sont tous deux activement maintenus. Un post sur Reddit laisse entendre une migration de Pages, mais même ce lien ne mentionne aucun arrêt officiel Je partage le reste de l’avis, mais c’est surtout ce point qui m’a surpris Lien Reddit de référence
Je ne peux pas être d’accord avec l’idée que la configuration de Wrangler 3 ne fonctionnerait plus telle quelle dans Wrangler 4. Le format de configuration n’a absolument pas changé dans Wrangler 4, et la hausse de version majeure n’a eu aucun impact pour 99,99 % des utilisateurs. Le détail des changements est disponible ici. Le simple passage à une version majeure a déjà été perçu comme pénible, au point que j’ai moi-même exprimé des réserves en interne, mais l’équipe a été prudente à cause de cas limites extrêmement rares. À l’avenir, nous allons développer des moyens de gérer ce type de sujet sans augmentation de version majeure, par exemple avec le support simultané de plusieurs versions d’esbuild. Côté runtime, nous faisons particulièrement attention à la rétrocompatibilité Blog sur la rétrocompatibilité Pages ne disparaît pas, et Workers Assets est simplement une version plus flexible de l’implémentation de Pages. Si vous n’avez pas besoin de fonctionnalités supplémentaires, il n’est pas nécessaire de migrer, et une migration automatique est prévue plus tard
Cela rappelle une fois de plus qu’il vaut mieux utiliser des « technologies ennuyeuses » pour des projets critiques ou des systèmes destinés à durer plusieurs années
Je me demande d’où vient l’idée que « Pages semble sur le point de disparaître ». De mon côté, j’utilise très bien Pages sur plusieurs projets
Ce qui est intéressant, c’est que toute cette controverse a commencé avec l’affirmation que Cloudflare était plus rapide que Vercel. Ensuite, quelqu’un de vraiment compétent a réalisé un benchmark et a montré que c’était en fait l’inverse, ce qui a conduit Cloudflare à faire un vrai travail d’amélioration des performances
J’ai beaucoup aimé le fait que l’article, au lieu de dénigrer la concurrence, cherche et mette en avant les pistes d’amélioration. Il est aussi impressionnant de voir des progrès dans l’implémentation d’OpenNext, qui peuvent être réutilisés chez d’autres fournisseurs
Je suis en train de migrer un hébergement NextJS sur Vercel vers Astro/React sur Cloudflare. Ce qui m’étonne, c’est que même en rendant la web app à chaque requête à l’« edge », le temps de réponse reste autour de 100 à 200 ms, soit une vitesse quasiment comparable à celle d’une page statique. J’ai aussi très nettement ressenti les améliorations récentes de Cloudflare Worker ces dernières semaines : les cold starts ont presque disparu et les temps de réponse sont bien plus stables Lien vers la web app en cours de portage
Je trouve fascinant qu’une vidéo publiée par un YouTuber de taille modeste ait pu se diffuser aussi efficacement, au point d’entraîner chez Cloudflare de vraies améliorations significatives et la résolution de problèmes de plateforme
C’est un PR extrêmement bien ficelé. Bravo aux personnes qui ont préparé ce post
En tant qu’ancien client de cf, je peux dire que cf ne se contente pas d’exceller dans les billets de blog et l’open source : c’est aussi l’une des meilleures entreprises d’infrastructure en matière de support. Les membres de l’équipe, Kenton compris, aident souvent directement les utilisateurs sur Discord ou prennent en compte leurs retours, et il est possible d’échanger rapidement avec les ingénieurs réellement responsables des bugs ou incidents. J’ai même déjà vu des PR ou des demandes de fonctionnalités que j’avais proposées être intégrées rapidement, sans procédure lourde. Et tout cela avec des tarifs très bas par rapport aux autres grandes entreprises, tout en offrant un support bien meilleur
Merci ! Ce PR et ce post ont été entièrement imaginés et réalisés de façon proactive par les ingénieurs de l’équipe Workers à 100 % (j’y ai aussi participé)
J’aime beaucoup la manière dont ce post est rédigé, la façon de décomposer l’information et la discussion ouverte. Ma confiance envers l’équipe Cloudflare Workers augmente
À mon avis, SvelteKit est extrêmement rapide, et Next.js est relativement très lent
Conclusion plausible
J’espère que des frameworks pragmatiques comme SvelteKit, Astro et TanStack finiront bientôt par remplacer la complexité de NextJS
C’est exactement pour ce genre de cas qu’il faut de la concurrence et des benchmarks indépendants. Cela pousse même les services insuffisants à faire des efforts pour s’améliorer
Encore faut-il que l’on tienne réellement à son produit pour que ces efforts aient un effet
Des benchmarks indépendants existent déjà
Il est impressionnant de voir Cloudflare accepter humblement les résultats et améliorer les choses de manière constructive
C’est un excellent texte, centré sur le fond et sans attaque gratuite. En revanche, j’ai été surpris que Cloudflare n’ait pas auparavant mieux surveillé et ajusté à l’avance des paramètres comme la taille des générations. Dans le tuning de performances JVM, régler la taille des générations m’a toujours semblé être la base