Profilage de la mémoire de l'application Forge pour réduire les coûts de calcul

Avec la transition officielle d'Atlassian Forge vers un modèle de tarification basé sur la consommation en 2026, l'efficacité est désormais une exigence d'ingénierie fondamentale. Selon le nouveau modèle, le coût de votre application est directement lié à GB-secondes: le produit de votre temps d'exécution et de la mémoire allouée.

Bien que le temps d'exécution soit souvent au centre de l'optimisation, Allocation de mémoire est un levier tout aussi essentiel pour le contrôle des coûts. De nombreux développeurs laissent leurs applications au réglage par défaut de 512 Mo, en payant essentiellement pour « l'air vide ».

En établissant un profil de l'utilisation de la mémoire dans le monde réel, vous pouvez réduire vos allocations en toute sécurité et protéger nos résultats financiers.

Pourquoi l'allocation de mémoire est importante pour votre facture

L'environnement d'exécution de Forge étant basé sur une infrastructure sans serveur, les principes économiques d'AWS Lambda s'appliquent également ici. UNE article récent sur dev.to fournit d'excellentes informations sur la manière dont l'allocation de mémoire influe sur la tarification des solutions sans serveur.

Le plat à emporter est simple : Vos coûts varient en fonction de votre réservation, et pas seulement de votre utilisation. Dans Forge, si vous allouez 512 Mo mais que votre code n'a besoin que de 200 Mo, les 312 Mo non utilisés vous sont facturés à chaque exécution de la fonction. Réduire cet écart est l'un des moyens les plus efficaces de réduire votre consommation de Gbit/s.

Comment profiler la mémoire dans Forge

La Developer Console d'Atlassian indique le nombre d'appels et les taux de réussite, mais elle ne fournit actuellement pas de métrique de « RAM maximale utilisée » pour les appels réussis. Pour découvrir la vérité, vous devez instrumenter votre code à l'aide de RSS (taille de l'ensemble des résidents) via Process.MemoryUsage.rss ().

Suivi des pics d'utilisation

Pour comprendre vos besoins en mémoire, vous pouvez suivre le pic de RSS observé pendant la durée de vie d'un environnement d'exécution spécifique à l'aide d'une simple variable au niveau du module.

// memProfile.js
let peakMemory = 0;

export const monMemUsage = (label = "Checkpoint") => {
  const mem = process.memoryUsage.rss();
  const memMB = Math.round(mem / 1024 / 1024);
  
  if (memMB > peakMemory) {
    peakMemory = memMB;
  }
  
  console.log(`[Memory] ${label} - Current: ${memMB}MB, Peak Observed: ${peakMemory}MB`);
};

Instrumentation d'un résolveur

Pour obtenir un profil précis, appelez le moniteur aux points d'entrée et de sortie de vos résolveurs, ainsi qu'après toute opération gourmande en mémoire (comme la récupération de grands ensembles de données depuis l'API Jira).

import Resolver from '@forge/resolver';
import { monMemUsage } from './memProfile';

const resolver = new Resolver();

resolver.define('getData', async (req) => {
  monMemUsage('Resolver Start');
  
  const data = await someHeavyApiCall();
  monMemUsage('Post API Fetch');
  
  const result = transformData(data);
  monMemUsage('Resolver End');
  
  return result;
});

export const handler = resolver.getDefinitions();

‍‍Comprendre le champ d'application : profilage par processus

Il est important de se rappeler que ce suivi de la mémoire est par processus. Lorsque votre application Forge gère plusieurs demandes, la plateforme Forge peut utiliser des processus simultanés. Chaque processus conserve son propre état au niveau du module dans son propre espace mémoire.

• Consolidation : Comme vous ne pouvez pas voir un seul pic « global » pour tous les utilisateurs, vous devez agréger vos journaux pour voir la répartition des pics entre les différents processus.
• Alignement statistique : Si votre charge de travail est uniforme, les pics des différents processus finiront par s'aligner sur un espace d'échantillonnage suffisamment grand.
• Attention au « cygne noir » : Soyez prudent si votre application a rarement exécuté des chemins de code. En ingénierie et en gestion des risques, ils sont connus sous le nom de Cygnes noirs - des événements qui se produisent rarement mais qui ont un impact considérable. Par exemple, un bouton « Exporter toutes les données » peut utiliser 450 Mo, même si votre pic « typique » n'est que de 180 Mo. Si vous optimisez uniquement sur la base de l'utilisation moyenne, ces rares tâches se bloqueront en raison d'erreurs d'épuisement de la mémoire (OOM).

Déterminer votre allocation « sûre »

Une fois que vous avez identifié votre utilisation maximale de la mémoire grâce au profilage, la tentation est de définir votre Mémoire MB dans le manifest.yml aussi proche que possible de ce chiffre. Cependant, fixer une limite trop stricte est dangereux pour plusieurs raisons :

1. Limites du RSS par rapport à la plateforme : Process.MemoryUsage.rss () est une mesure interne du processus Node.js. Bien qu'il s'agisse de la métrique la plus proche dont nous disposons, elle ne correspond pas toujours à 1:1 pour les limites d'allocation de mémoire totales appliquées par la plate-forme Forge.
2. Collecte des déchets V8 : L'utilisation de la mémoire du fichier Node.js n'est pas statique. Le moteur V8 peut retarder le ramassage des déchets, provoquant des pics temporaires d'utilisation de la mémoire qui dépassent le seuil « normal ».
3. Des marges de manœuvre pour la croissance : Même si votre code est efficace aujourd'hui, vous avez besoin d'une mémoire tampon pour les charges utiles de données inhabituelles ou les futures modifications mineures du code susceptibles d'augmenter légèrement l'encombrement de la mémoire.

La phase de préparation et de vérification

Avant de déployer de nouveaux paramètres de mémoire en production, il est essentiel de laisser l'application « fonctionner » dans un environnement de test. Cette phase vous permet de vérifier vos hypothèses par rapport à diverses charges de travail sans impact sur les utilisateurs finaux.

• Simuler la charge : Exécutez plusieurs fois vos opérations les plus intensives pour vérifier si l'utilisation maximale de la mémoire reste stable ou si elle augmente lors des démarrages à chaud.
• Surveillez les défaillances : Surveillez de près les journaux pour détecter toute erreur de mémoire hors mémoire (OOM). Si vous constatez des accidents lors de la mise en scène, cela signifie que votre marge de manœuvre est trop petite.
• Vérifiez les chemins « rares » : Déclenchez manuellement ces chemins de code moins fréquents (les « Black Swans ») pour vous assurer qu'ils peuvent toujours s'exécuter dans les nouvelles limites proposées.

Conclusion : réduction des coûts de 40 %

Lors de notre profilage, nous avons constaté que notre taux de flux RSS le plus élevé restait constant 180 MO pour les opérations standard. En tenant compte des facteurs de marge et des variances de mesure mentionnés ci-dessus, nous avons choisi de définir Mémoire MB pour 300 MO dans le manifest.yml.

Cela a fourni une mémoire tampon saine de 120 Mo pour les pics, tout en fournissant un 40 % de réduction dans notre espace informatique facturable par rapport à la valeur par défaut de 512 Mo.

app:
  runtime:
    name: nodejs22.x
    memoryMB: 300 # Optimized from 512MB default

‍En combinant une instrumentation ciblée avec une mémoire tampon conservatrice et une phase de préparation rigoureuse, vous pouvez optimiser en toute confiance votre empreinte Forge pour le nouveau monde basé sur la consommation. Déployez vos modifications, consultez les journaux et profitez des gains d'efficacité.