Advertencia: todo el contenido publicado tiene como objetivo recordar o mantener mis conocimientos y espero que también pueda ayudarte en tu viaje de aprendizaje.
Esta publicación está activa y se actualizará periódicamente.
Si encuentras algún defecto o notas que falta algo, ayúdame a mejorar :)

¿Alguna vez te has parado a pensar que cada vez somos más exigentes en cuanto al rendimiento de nuestras aplicaciones?
Cada día tenemos el desafío de hacerlos más rápidos y con eso, nos llevamos a evaluar soluciones y arquitecturas que nos permitan lograr el resultado.

Entonces la idea es traer un post corto, informando sobre una nueva evolución que nos puede ayudar a tener un aumento considerable en el rendimiento de las aplicaciones serverless en AWS Lambda. Esta solución es LLRT Javascript.

LLRT Javascript (Javascript de tiempo de ejecución de baja latencia)

El equipo de AWS está desarrollando un nuevo tiempo de ejecución de Javascript.
Actualmente es experimental y se están realizando esfuerzos para intentar lanzar una versión estable para finales de 2024.

ver la descripción que presenta AWS:

LLRT (Low Latency Runtime) es un tiempo de ejecución de JavaScript liviano diseñado para abordar la creciente demanda de aplicaciones sin servidor rápidas y eficientes. LLRT ofrece un inicio hasta 10 veces más rápido y un costo general hasta 2 veces menor en comparación con otros tiempos de ejecución de JavaScript que se ejecutan en AWS Lambda
Está integrado en Rust y utiliza QuickJS como motor de JavaScript, lo que garantiza un uso eficiente de la memoria y un inicio rápido.

Vea que su objetivo es ofrecer algo hasta 10 veces más rápido que otros tiempos de ejecución de JS.

Toda esta construcción se realiza utilizando Rust, que es un lenguaje de alto rendimiento, y QuickJS, que es un motor JavaScript liviano y de alto rendimiento diseñado para ser pequeño, eficiente y compatible con la última especificación ECMAScript, incluida. Funciones modernas como clases, async/await y módulos. Además, se utiliza un enfoque que no utiliza JIT. Por lo tanto, en lugar de asignar recursos para la compilación Just-In-Time, conserva estos recursos para ejecutar tareas dentro del código mismo.

Pero no te preocupes, no todo es color de rosa, son compensaciones (juego de palabras horrible, lo sé jajaja).
Por lo tanto, hay algunos puntos importantes a considerar antes de pensar en adoptar LLRT JS. Vea lo que dice AWS:

Hay muchos casos en los que LLRT muestra notables desventajas de rendimiento en comparación con los tiempos de ejecución impulsados ​​por JIT, como el procesamiento de grandes datos, simulaciones de Monte Carlo o la realización de tareas con cientos de miles o millones de iteraciones. LLRT es más eficaz cuando se aplica a funciones sin servidor más pequeñas dedicadas a tareas como transformación de datos, procesamiento en tiempo real, integraciones de servicios de AWS, autorización, validación, etc. Está diseñado para complementar los componentes existentes en lugar de servir como un reemplazo integral de todo. En particular, dado que las API compatibles se basan en la especificación Node.js, la transición a soluciones alternativas requiere ajustes mínimos de código.

Además, la idea es que LLRT JS no reemplaza a node.js y nunca lo será.

Mirar:

LLRT solo admite una fracción de las API de Node.js. NO es un reemplazo directo de Node.js, ni lo será nunca. A continuación se muestra una descripción general de alto nivel de las API y módulos parcialmente compatibles. Para más detalles consulte la documentación de la API.

Pruebas Evaluativas

Teniendo en cuenta la aplicabilidad mencionada por el propio AWS, realizaremos dos pruebas para evaluar y comparar LLRT con NodeJS. Una de las pruebas será para calcular números primos y la otra será para una simple llamada API.

¿Por qué utilizar el cálculo de números primos?
La respuesta es que el alto procesamiento requerido para identificar números primos resulta de la necesidad de realizar muchas operaciones matemáticas (divisiones) para verificar la primalidad, la distribución impredecible de los números primos y la creciente complejidad con el tamaño de los números. Estos factores se combinan para hacer que la verificación de primalidad y la búsqueda de números primos sean una tarea computacionalmente intensiva, especialmente a gran escala.

Manos a la obra entonces...

Crea la primera función lambda con nodejs:

Ahora, creemos la función con LLRT JS. Elegí usar la opción de capa.

Crear la capa:

Luego crea la función:

Y agregue esta capa a la función LLRT JS creada:

Para la prueba de números primos, usaremos el siguiente código:

let isLambdaWarm = false
export async function handler(event)  {

    const limit = event.limit || 100000;  // Defina um limite alto para aumentar a complexidade
    const primes = [];
    const startTime = Date.now()
    const isPrime = (num) => {
        if (num 



Y para las pruebas de API, usaremos el siguiente código:


let isLambdaWarm = false
export async function handler(event) {

  const url = event.url || 'https://jsonplaceholder.typicode.com/posts/1'
  console.log('starting fetch url', { url })
  const startTime = Date.now()

  let resp;
  try {
    const response = await fetch(url)
    const data = await response.json()
    const endTime = Date.now() - startTime
    resp = {
      statusCode: 200,
      body: JSON.stringify({
        executionTime: `${endTime} ms`,
        isLambdaWarm: `${isLambdaWarm}`
      }),
    }
  }
  catch (error) {
    resp = {
      statusCode: 500,
      body: JSON.stringify({
        message: 'Error fetching data',
        error: error.message,
      }),
    }
  }

  if (!isLambdaWarm) {
    isLambdaWarm = true
  }

  return resp;
};






  
  
  Resultados de la prueba


El objetivo aquí es más educativo, por lo que nuestra muestra para cada prueba consta de 15 datos de inicio en caliente y 1 dato de inicio en frío.

Consumo de memoria

LLRT JS: para ambas pruebas, se consumió la misma cantidad de memoria: 23 MB.

NodeJS: para la prueba de números primos, nodejs comenzó a consumir 69 MB y subió a 106 MB. 

Para la prueba API, el mínimo fue de 86 MB y el máximo de 106 MB. 

Tiempo de ejecución

después de eliminar los valores atípicos, este fue el resultado:





Informe final

Consumo de memoria: para el consumo de memoria se observó que LLRT hizo un mejor uso del recurso disponible en comparación con nodejs.

Rendimiento: notamos que en el escenario de alto procesamiento, el nodo mantuvo un rendimiento mucho mejor que LLRT, tanto en arranque en frío como en arranque en caliente.

Para el escenario de procesamiento inferior, LLRT tenía cierta ventaja, especialmente en el arranque en frío.

Esperemos los resultados finales y esperemos que podamos tener mejoras aún más significativas, pero es genial ver la flexibilidad de JS y ver cuánto puede y aún tiene que ofrecernos. 


Espero que lo hayas disfrutado y te haya ayudado a mejorar tu comprensión de algo o incluso te haya abierto caminos hacia nuevos conocimientos. Cuento contigo para críticas y sugerencias para que podamos mejorar el contenido y mantenerlo siempre actualizado para la comunidad.