Внимание: любой опубликованный контент предназначен для напоминания или поддержания моих знаний, и я надеюсь, что он также поможет вам в вашем пути обучения.
Этот пост активен и будет периодически обновляться.
Если вы обнаружите какие-либо недостатки или заметите, что чего-то не хватает, помогите мне улучшить :)

Задумывались ли вы когда-нибудь, что к нам предъявляют все более высокие требования в отношении производительности наших приложений?
Каждый день перед нами стоит задача сделать их быстрее, и поэтому нам приходится оценивать решения и архитектуры, которые позволяют нам достичь результата.

Итак, идея состоит в том, чтобы опубликовать короткий пост, информирующий о новой эволюции, которая может помочь нам добиться значительного повышения производительности бессерверных приложений в AWS Lambda. Это решение LLRT Javascript.

LLRT Javascript (Javascript среды выполнения с низкой задержкой)

Команда aws разрабатывает новую среду выполнения Javascript.
В настоящее время это экспериментальная версия, и предпринимаются попытки выпустить стабильную версию к концу 2024 года.

см. описание, которое представляет AWS:

LLRT (Low Latency Runtime) — это облегченная среда выполнения JavaScript, разработанная для удовлетворения растущего спроса на быстрые и эффективные бессерверные приложения. LLRT обеспечивает более чем 10-кратное ускорение запуска и в 2 раза более низкую общую стоимость по сравнению с другими средами выполнения JavaScript, работающими на AWS Lambda
Он построен на Rust и использует QuickJS в качестве движка JavaScript, что обеспечивает эффективное использование памяти и быстрый запуск.

Смотрите, что они стремятся предоставить что-то в 10 раз быстрее, чем другие среды выполнения JS.

Вся эта конструкция выполняется с использованием высокопроизводительного языка Rust и QuickJS — легкого, высокопроизводительного движка JavaScript, небольшого размера, эффективного и совместимого с новейшими спецификациями ECMAScript, в том числе. современные функции, такие как классы, async/await и модули. Кроме того, используется подход, не использующий JIT. Поэтому вместо выделения ресурсов для JIT-компиляции он сохраняет эти ресурсы для выполнения задач внутри самого кода.

Но не волнуйтесь, не все так радужно, это компромиссы (ужасный каламбур, я знаю, лол).
Поэтому есть несколько важных моментов, которые следует учитывать, прежде чем думать о внедрении LLRT JS. Посмотрите, что говорит AWS:

Во многих случаях LLRT демонстрирует заметные недостатки в производительности по сравнению со средами выполнения на основе JIT, например, при обработке больших данных, моделировании Монте-Карло или выполнении задач с сотнями тысяч или миллионами итераций. LLRT наиболее эффективен при применении к небольшим бессерверным функциям, предназначенным для таких задач, как преобразование данных, обработка в реальном времени, интеграция сервисов AWS, авторизация, проверка и т. д. Он предназначен для дополнения существующих компонентов, а не для полной замены всего. Примечательно, что, поскольку поддерживаемые API основаны на спецификации Node.js, переход обратно к альтернативным решениям требует минимальных корректировок кода.

Кроме того, идея состоит в том, что LLRT JS не является заменой node.js и никогда ею не станет.

Смотреть:

LLRT поддерживает только часть API Node.js. Это НЕ замена Node.js и никогда не будет. Ниже приведен общий обзор частично поддерживаемых API и модулей. Для получения более подробной информации обратитесь к документации API.

Оценочные тесты

Принимая во внимание применимость, упомянутую самой AWS, мы проведем два теста для оценки и сравнения LLRT с NodeJS. Один из тестов будет предназначен для вычисления простых чисел, а другой — для простого вызова API.

Зачем использовать вычисление простых чисел?
Ответ заключается в том, что трудоемкая обработка, необходимая для идентификации простых чисел, является результатом необходимости выполнения множества математических операций (делений) для проверки простоты, непредсказуемого распределения простых чисел и увеличения сложности с увеличением размера чисел. В совокупности эти факторы делают проверку простоты и поиск простых чисел трудоемкой вычислительной задачей, особенно в больших масштабах.

Тогда давайте...

Создайте первую лямбда-функцию с помощью nodejs:

Теперь давайте создадим функцию с помощью LLRT JS. Я решил использовать опцию слоя.

Создайте слой:

Затем создайте функцию:

И добавьте этот слой к созданной функции LLRT JS:

Для проверки простых чисел мы будем использовать следующий код:

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 



А для тестирования API мы будем использовать следующий код:


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;
};






  
  
  Результаты испытаний


Цель здесь более образовательная, поэтому наша выборка для каждого теста состоит из 15 данных теплого запуска и 1 данных холодного запуска.

Потребление памяти

LLRT JS - для обоих тестов потреблялось одинаковое количество памяти: 23мб.

NodeJS — для теста простых чисел nodejs начал потреблять 69 МБ и увеличился до 106 МБ. 

Для теста API минимум составлял 86 МБ, а максимум — 106 МБ. 

Срок выполнения

после удаления выбросов получился вот такой результат:





Итоговый отчет

Потребление памяти. Что касается потребления памяти, было замечено, что LLRT лучше использовал доступный ресурс по сравнению с nodejs.

Производительность — мы заметили, что в сценарии с высокой производительностью узел поддерживает гораздо лучшую производительность, чем LLRT, как при холодном, так и при теплом старте.

В сценарии с более низким уровнем обработки LLRT имел определенное преимущество, особенно при холодном запуске.

Давайте подождем окончательных результатов и будем надеяться, что мы сможем добиться еще более значительных улучшений, но приятно видеть гибкость JS и видеть, сколько он может и еще должен нам дать. 


Надеюсь, вам понравилось и помогло улучшить понимание чего-либо или даже открыло пути к новым знаниям. Я рассчитываю на вашу критику и предложения, чтобы мы могли улучшить контент и всегда обновлять его для сообщества.