Encore.ts — Démarrages à froid plus rapides que NestJS et Fastify

Il y a quelques mois, nous avons publié Encore.ts, un framework backend Open Source pour TypeScript.

Comme il existe déjà de nombreux frameworks, nous souhaitons partager certaines des décisions de conception aberrantes que nous avons prises et comment elles conduisent à des résultats de performances remarquables.

Nous avons récemment publié des tests de performances montrant qu'Encore.ts atteint un débit de requêtes 9x par rapport à Express.js et 2x par rapport à Fastify.

Aujourd'hui, nous poursuivons notre parcours de performance en explorant comment Encore.ts atteint des temps de démarrage à froid incroyablement rapides.

Repères de performances

Cette fois, nous avons comparé Encore.ts, Fastify, NestJS et Express pour voir les performances de chaque framework en termes de temps de démarrage à froid.

Le programme de référence enregistre 10 points de terminaison d'API, chacun avec un schéma simple, et configure la validation du schéma.
Pour la validation du schéma, nous avons utilisé Zod lorsque cela était possible.
Dans le cas de Fastify, nous avons utilisé Ajv comme bibliothèque de validation de schéma officiellement prise en charge.

Nous avons mesuré le temps écoulé entre le début de l'exécution du code JavaScript et le moment où le serveur est prêt à accepter les demandes entrantes.
Pour chaque référence, nous avons pris le meilleur résultat sur cinq courses.

Assez parlé, passons aux chiffres !

Les démarrages à froid d'Encore.ts sont 17 fois plus rapides que NestJS et Fastify

(Consultez le code de référence sur GitHub.)

Comme vous pouvez le constater, Encore.ts atteint des temps de démarrage à froid remarquablement rapides, plus de 5 fois plus rapides qu'Express et plus de 17 fois plus rapides que NestJS.

Comment est-ce possible ? À partir de nos tests, nous avons identifié deux sources principales de performances, toutes deux liées au fonctionnement d'Encore.ts sous le capot.

Mais avant d'en arriver là, parlons de ce que sont réellement les démarrages à froid et de leur importance.

Qu'est-ce qu'un démarrage à froid ?

Dans le contexte du sans serveur, un démarrage à froid se produit lorsque la plate-forme sous-jacente doit d'abord démarrer une nouvelle instance de votre serveur afin de répondre à une requête entrante. (Cela peut également faire référence au premier démarrage d'une nouvelle instance de votre serveur pour traiter une requête, par exemple après un déploiement.)

Étant donné que la requête est effectivement en attente jusqu'à ce que le processus démarre et soit prêt à traiter la requête, la réduction des temps de démarrage à froid peut avoir un impact important sur la latence longue traîne de votre application.

Ceci est particulièrement important pour les systèmes distribués où vous disposez de plusieurs fonctions sans serveur, car il est beaucoup plus probable que vous rencontriez un démarrage à froid dans une partie du système lors du traitement d'une requête.

L'anatomie d'un démarrage à froid

Ce qui se passe exactement lors d'un démarrage à froid dépend un peu de la plate-forme sur laquelle vous déployez (Kubernetes, Lambda, Cloud Run, etc.).
Mais en général, le processus ressemble à ceci :

1. La plateforme télécharge l'image code/conteneur pour la fonction sans serveur
2. La plate-forme lance une nouvelle instance de la fonction/conteneur conteneur/sans serveur
3. Le conteneur/fonction s'initialise (importation de modules JavaScript, exécution du code d'initialisation, etc.)

Après ces étapes d'initialisation, le démarrage à froid est terminé et la fonction sans serveur commence à traiter la requête entrante.

Les deux premières étapes sont en grande partie hors de notre contrôle (sauf en nous assurant que la taille du code/conteneur est optimisée), concentrons donc notre attention sur la troisième étape.

En fait, décomposons davantage la troisième étape, et en supposant que nous utilisons Node.js :

1. Le processus de nœud démarre et commence l'initialisation du moteur JavaScript V8
2. Le fichier de point d'entrée est analysé, chargé et commence à exécuter le code de l'application
3. Lorsque le code JavaScript exécute les instructions import et require, davantage de fichiers sont chargés, analysés et exécutés. (Répétez plusieurs fois pour les applications avec beaucoup de dépendances.)

Enfin, une fois que toutes les dépendances ont été chargées et que tout le code d'initialisation a été exécuté, la fonction conteneur/sans serveur est prête à gérer les requêtes entrantes.

Optimiser les démarrages à froid

La répartition ci-dessus nous donne des objectifs d'optimisation clairs, et Encore.ts optimise fortement toutes les étapes sur lesquelles il contrôle.

Optimisation 1 : runtime Rust

Encore.ts est implémenté dans Rust et chargé dans Node.JS en tant que module natif. Cela présente plusieurs avantages pour les démarrages à froid :

Moins de JavaScript à analyser et à exécuter. Puisque JavaScript est un langage interprété, tout le code JavaScript doit être lu à partir du disque, analysé et exécuté. Encore.ts, en tant que module natif précompilé, se charge extrêmement rapidement et n'a pas besoin d'être analysé ou exécuté par le moteur JavaScript (V8).

Zéro dépendance NPM. Étant donné qu'Encore.ts implémente toutes ses fonctionnalités à l'aide de Rust, il n'a aucune dépendance NPM, ce qui réduit encore la quantité de JavaScript qui doit être exécuté lors d'un démarrage à froid.

Pré-compilé et optimisé. JavaScript s'appuie fortement sur la compilation juste à temps (JIT), où le code exécuté à plusieurs reprises est optimisé par le moteur JavaScript. Cela a beaucoup de sens pour un langage interprété, mais cela signifie également que l'exécution est un peu plus lente la première fois qu'un morceau de code s'exécute, ce qui a un impact considérable sur les démarrages à froid. Étant donné qu'Encore.ts est implémenté dans Rust, il est précompilé et fortement optimisé pour la plate-forme sur laquelle il s'exécute, ce qui signifie qu'il est rapide dès la première exécution.

Optimisation 2 : images Docker efficaces

Encore.ts crée par défaut des images Docker minifiées, en incluant uniquement le JavaScript transpilé et les dépendances nécessaires pour exécuter l'application. Cela réduit la taille des bundles, ce qui réduit le temps nécessaire au téléchargement et au démarrage du conteneur.

De plus, plusieurs plates-formes de calcul ont ajouté la prise en charge du streaming d'images Docker, ce qui signifie que la plate-forme peut démarrer le conteneur avant que l'image entière n'ait été téléchargée. Encore.ts prend en charge cela de manière intégrée et donne automatiquement la priorité aux parties de l'image nécessaires pour réduire les démarrages à froid.

Conclusion

En combinant un runtime Rust avec des images Docker optimisées, Encore.ts est capable d'atteindre des temps de démarrage à froid remarquables, ce qui peut avoir un impact important sur la latence longue traîne de votre application.

Si les performances sont importantes pour votre projet, cela pourrait être une bonne idée d'essayer Encore.ts.

Et tout est Open Source, vous pouvez donc consulter le code et contribuer sur GitHub.

Ou essayez-le et dites-nous ce que vous en pensez !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!