Choisir entre une fonction WASM et un runtime Node.js ne se règle pas avec une comparaison de langages. Il faut mesurer le même traitement, sur la même infrastructure, puis regarder les démarrages à froid, la mémoire et le coût réellement facturé. Sans mesures faites dans votre environnement, aucun chiffre de performance ne permet de conclure pour votre application.

Aurabase fournit des Edge Functions, mais les runtimes et formats de déploiement disponibles dépendent de l’environnement utilisé. Vérifiez d’abord qu’il accepte bien les deux variantes que vous voulez tester. Pour le contexte sur les fonctions Rust et WASM dans une architecture applicative, voir notre guide sur Next.js et les fonctions Edge WASM.

1. Définir une charge représentative

Choisissez une tâche qui ressemble à votre trafic : valider un jeton, transformer un petit document ou appliquer une règle métier. Évitez le test artificiel qui ne fait qu’additionner des nombres si votre fonction passe en production son temps à analyser des données ou à appeler une base.

Implémentez exactement le même contrat d’entrée et de sortie dans les deux versions. Gardez constants les données, les dépendances, les opérations de chiffrement et les appels réseau. Si vous comparez une fonction qui interroge PostgreSQL, utilisez les mêmes requêtes et le même jeu de données. Mesurez aussi une variante sans accès à la base : elle aide à distinguer le temps passé dans le runtime du temps d’attente réseau et base de données.

Avant la mesure, vérifiez que les deux fonctions produisent les mêmes résultats et traitent les erreurs de la même manière. Un test plus rapide qui saute une validation ou renvoie une réponse différente n’est pas une optimisation utile.

2. Séparer le froid du chaud

Une requête à froid est la première exécutée après une période durant laquelle l’instance a pu être arrêtée ou retirée. Une requête chaude réutilise un environnement déjà prêt. Ne mélangez pas ces deux cas dans une seule moyenne : ils répondent à des questions différentes. Le démarrage à froid compte surtout pour les trafics sporadiques; le temps chaud décrit mieux les appels répétés.

Pour chaque variante, déclenchez plusieurs séries après une période d’inactivité contrôlée, puis envoyez une charge soutenue séparément. Enregistrez le temps de bout en bout et, si la plateforme l’expose, le temps d’initialisation du runtime. Faites assez de répétitions pour repérer les variations. Présentez médiane et percentiles, notamment p95, plutôt qu’un seul meilleur résultat. Notez la région, la configuration, la taille de la charge et la concurrence utilisée.

Ne présumez pas que chaque nouvelle requête correspond à un démarrage à froid. La plateforme peut réutiliser ou remplacer les instances selon ses propres règles. Si vous ne pouvez pas contrôler ou identifier cet état, signalez cette limite : vous mesurez alors le comportement observé, pas un démarrage froid isolé.

3. Mesurer la mémoire sans fausse équivalence

Relevez le pic mémoire pendant l’initialisation et pendant le traitement. Utilisez la même définition de métrique pour les deux runtimes, si elle est disponible. La mémoire linéaire d’un module WASM et la mémoire totale d’un processus Node.js ne décrivent pas nécessairement le même périmètre. Comparez les mesures fournies par la plateforme ou son système de supervision, et indiquez précisément ce qu’elles couvrent.

Testez au moins deux tailles de charge. Une fonction peut avoir une empreinte initiale réduite et consommer davantage lorsque les entrées grandissent. À l’inverse, un pic bref peut disparaître dans une mesure moyenne. Gardez donc distincts le pic, la moyenne et la mémoire observée après plusieurs appels.

4. Relier les mesures au coût

Le coût ne se déduit pas du temps d’exécution seul. Il dépend de la formule de facturation du fournisseur : durée, mémoire allouée, nombre d’appels, ou combinaison de ces éléments. Reprenez les métriques et les tarifs de votre environnement, puis calculez le coût d’une charge mensuelle représentative. Si la facturation ou les données de mémoire ne sont pas disponibles, ne présentez pas une estimation comme un coût réel.

Consignez aussi les limites de concurrence, les erreurs et les délais dépassés. Un runtime qui finit plus vite à faible charge peut se comporter autrement lorsqu’un grand nombre d’appels arrivent ensemble. Le résultat utile n’est pas seulement un temps minimal, mais le coût et le taux de réussite pour la qualité de service visée.

5. Prendre une décision de production

Comparez les chiffres dans un tableau par scénario : froid, chaud, charge élevée, mémoire et coût estimé. Retenez le runtime qui respecte vos contraintes avec une marge suffisante, puis validez-le dans un déploiement représentatif avant de migrer les fonctions. Gardez un retour arrière simple et surveillez les mêmes indicateurs après mise en production.

WASM peut être intéressant si votre charge et votre environnement tirent parti de son modèle d’exécution; Node.js peut rester le choix le plus simple pour une fonction déjà écrite dans cet écosystème. Le benchmark tranche pour votre cas, pas pour toutes les fonctions edge. Si votre fonction passe surtout son temps à attendre PostgreSQL ou un service réseau, le runtime ne sera probablement pas le seul levier à examiner.