Creación de perfiles de memoria de aplicaciones de Forge para reducir los costos de procesamiento

Con la transición oficial de Atlassian Forge a un modelo de precios basado en el consumo en 2026, la eficiencia es ahora un requisito fundamental de ingeniería. Con el nuevo modelo, el coste de tu aplicación está directamente relacionado con GB-segundos: el producto del tiempo de ejecución y la memoria asignada.

Si bien el tiempo de ejecución suele ser el objetivo de la optimización, Asignación de memoria es una palanca igualmente crítica para el control de costos. Muchos desarrolladores dejan sus aplicaciones en configuración predeterminada de 512 MB, básicamente pagando por «aire vacío».

Al perfilar el uso de la memoria en el mundo real, puede reducir sus asignaciones de forma segura y proteger nuestros resultados.

Por qué la asignación de memoria es importante para su factura

Dado que el tiempo de ejecución de Forge se basa en una infraestructura sin servidor, los principios económicos de AWS Lambda también se aplican aquí. A artículo reciente sobre dev.to proporciona información excelente sobre cómo la asignación de memoria impulsa los precios de los sistemas sin servidor.

La conclusión es sencilla: Sus costos aumentan con su reserva, no solo con su uso. En Forge, si asignas 512 MB pero tu código solo necesita 200 MB, se te facturarán los 312 MB no utilizados cada vez que se ejecute la función. Reducir esta brecha es una de las maneras más eficaces de reducir el consumo de GB por segundo.

Cómo perfilar la memoria en Forge

La consola para desarrolladores de Atlassian informa sobre los recuentos de invocaciones y las tasas de éxito, pero actualmente no proporciona una métrica de «RAM máxima utilizada» para las llamadas exitosas. Para descubrir la verdad, tienes que instrumentar tu código usando RSS (tamaño del conjunto residente) vía Proceso.MemoryUsage.rss ().

Seguimiento de los picos de uso

Para comprender sus requisitos de memoria, puede realizar un seguimiento del pico de RSS observado durante la vida útil de un entorno de ejecución específico mediante una variable simple a nivel de módulo.

// 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`);
};

Instrumentación de un solucionador

Para obtener un perfil preciso, llama al monitor en los puntos de entrada y salida de tus solucionadores, así como después de cualquier operación que consuma mucha memoria (como obtener grandes conjuntos de datos de la API de 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();

‍‍Comprensión del alcance: elaboración de perfiles por proceso

Es importante recordar que este seguimiento de la memoria es por proceso. Cuando su aplicación Forge gestiona varias solicitudes, la plataforma Forge puede utilizar procesos simultáneos. Cada proceso mantiene su propio estado a nivel de módulo en su propio espacio de memoria.

• Consolidación: Como no puede ver un único pico «global» en todos los usuarios, debe agregar sus registros para ver la distribución de los picos en los diferentes procesos.
• Alineación estadística: Si su carga de trabajo es uniforme, los picos en los diferentes procesos eventualmente se alinearán en un espacio muestral lo suficientemente grande.
• Cuidado con el «cisne negro»: Ten cuidado si tu aplicación ha ejecutado rutas de código con poca frecuencia. En ingeniería y gestión de riesgos, estas se conocen como Cisnes negros - eventos que ocurren raramente pero que tienen un impacto masivo. Por ejemplo, el botón «Exportar todos los datos» puede ocupar 450 MB, incluso si su pico «típico» es de solo 180 MB. Si optimizas basándote únicamente en el uso promedio, esas tareas poco frecuentes se bloquearán debido a errores de falta de memoria (OOM).

Determinar su asignación «segura»

Una vez que haya identificado su uso máximo de memoria mediante la creación de perfiles, la tentación es configurar su Memoria MB en el manifest.yml lo más cerca posible de ese número. Sin embargo, establecer un límite demasiado ajustado es peligroso por varias razones:

1. RSS frente a los límites de plataforma: Proceso.MemoryUsage.rss () es una medición interna del proceso Node.js. Si bien es la métrica más cercana de la que disponemos, no siempre coincide con los límites totales de asignación de memoria impuestos por la plataforma Forge.
2. Recolección de basura V8: El uso de la memoria de Node.js no es estático. El motor V8 puede retrasar la recolección de basura y provocar picos temporales en el uso de la memoria que superen el límite máximo «normal».
3. Espacio para el crecimiento: Incluso si tu código es eficiente hoy en día, necesitas un búfer para cargas de datos inusuales o para futuros cambios menores en el código que podrían aumentar ligeramente el consumo de memoria.

La fase de preparación y verificación

Antes de implementar nuevos ajustes de memoria en la producción, es fundamental dejar que la aplicación se «cocine» en un entorno de ensayo. Esta fase le permite verificar sus suposiciones comparándolas con una variedad de cargas de trabajo sin afectar a los usuarios finales.

• Simular carga: Ejecute las operaciones más intensivas varias veces para comprobar si el uso máximo de memoria se mantiene estable o si aumenta durante los arranques en caliente.
• Supervise las fallas: Vigile de cerca los registros para detectar cualquier error de falta de memoria (OOM). Si observas fallos durante la puesta en escena, significa que tu margen de maniobra es demasiado pequeño.
• Verifique las rutas «raras»: Active manualmente las rutas de código menos frecuentes (los «cisnes negros») para garantizar que puedan seguir ejecutándose dentro de los nuevos límites propuestos.

Conclusión: lograr una reducción de costos del 40%

En nuestra elaboración de perfiles, descubrimos que nuestro pico de RSS se mantenía constantemente 180 MB para operaciones estándar. Al tener en cuenta los factores de margen de maniobra y las variaciones de medición mencionados anteriormente, optamos por establecer Memoria MB a 300 MB en el manifest.yml.

Esto proporcionó un búfer saludable de 120 MB para los picos, a la vez que ofrecía un Reducción del 40% en nuestro espacio de procesamiento facturable en comparación con el tamaño predeterminado de 512 MB.

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

‍Al combinar una instrumentación específica con un búfer conservador y una fase de preparación rigurosa, puedes optimizar con confianza tu presencia en Forge para un nuevo mundo basado en el consumo. Implementa tus cambios, consulta los registros y disfruta de las mejoras en eficiencia.