首页  >  文章  >  web前端  >  兰巴轻轨

兰巴轻轨

WBOY
WBOY原创
2024-08-21 06:14:05442浏览

免责声明:发布的所有内容都是为了提醒或维护我的知识,我希望它也能在您的学习之旅上有所帮助。
这篇文章是实时的,并将定期更新。
如果您发现任何缺陷或发现缺少某些内容,请帮助我改进:)


您是否曾经想过,我们对应用程序性能的要求越来越高?
我们每天都被鼓励让它们更快,这样我们就可以评估解决方案和架构,使我们能够实现结果。


因此,我们的想法是发表一篇简短的文章,介绍一项新的演变,可以帮助我们显着提高 AWS Lambda 中无服务器应用程序的性能。这个解决方案是LLRT Javascript

LLRT Javascript(低延迟运行时 Javascript)

aws 团队正在开发新的 Javascript 运行时。
目前处于实验阶段,我们正在努力尝试在 2024 年底之前发布稳定版本。

请参阅 AWS 提供的描述:

LLRT(低延迟运行时)是一种轻量级 JavaScript 运行时,旨在满足对快速高效的无服务器应用程序不断增长的需求。与 AWS Lambda 上运行的其他 JavaScript 运行时相比,LLRT 的启动速度提高了 10 倍以上,总体成本降低了 2 倍
它采用 Rust 构建,利用 QuickJS 作为 JavaScript 引擎,确保高效的内存使用和快速启动。

看到他们的目标是提供比其他 JS 运行时快 10 倍的东西。

所有这些构建都是使用 Rust(一种高性能语言)和 QuickJS 完成的,QuickJS 是一种轻量级高性能 JavaScript 引擎,设计小巧、高效且与最新的 ECMAScript 规范兼容。现代功能,如类、异步/等待和模块。此外,还使用了不使用JIT的方法。因此,它不是为即时编译分配资源,而是保留这些资源用于在代码本身内执行任务。

但是别担心,并不是一切都是美好的,这是权衡(可怕的双关语,我知道哈哈)。
因此,在考虑采用 LLRT JS 之前,需要考虑一些重要的要点。看看 AWS 怎么说:

在很多情况下,LLRT 与 JIT 支持的运行时相比表现出明显的性能缺陷,例如大数据处理、蒙特卡洛模拟或执行数十万或数百万次迭代的任务。当应用于专用于数据转换、实时处理、AWS 服务集成、授权、验证等任务的小型无服务器功能时,LLRT 最为有效。它旨在补充现有组件,而不是作为所有组件的全面替代品。值得注意的是,鉴于其支持的 API 基于 Node.js 规范,转换回替代解决方案需要最少的代码调整。

此外,我们的想法是 LLRT JS 不会取代 Node.js,也永远不会取代。

参见:

LLRT 仅支持 Node.js API 的一小部分。它不是 Node.js 的替代品,也永远不会。以下是部分支持的 API 和模块的高级概述。有关更多详细信息,请参阅 API 文档。


评估测试

考虑到AWS本身提到的适用性,我们将进行两次测试来评估和比较LLRT与NodeJS。其中一项测试将用于计算素数,另一项测试将用于简单的 API 调用。

为什么要使用素数的计算?
答案是,识别素数所需的高处理能力是由于需要执行许多数学运算(除法)来验证素数、素数的不可预测的分布以及随着数字的大小而增加的复杂性。这些因素结合在一起,使得素性检查和素数搜索成为一项计算密集型任务,尤其是在大规模情况下。


动手吧...

使用 Nodejs 创建第一个 lambda 函数:

Lamba LLRT

现在,让我们使用 LLRT JS 创建该函数。我选择使用图层选项。

创建图层:
Lamba LLRT

然后创建函数:
Lamba LLRT

并将该层添加到创建的 LLRT JS 函数中:
Lamba LLRT

对于素数测试,我们将使用以下代码:

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 <= 1) return false;
        if (num <= 3) return true;
        if (num % 2 === 0 || num % 3 === 0) return false;
        for (let i = 5; i * i <= num; i += 6) {
            if (num % i === 0 || num % (i + 2) === 0) return false;
        }
        return true;
    };

    for (let i = 2; i <= limit; i++) {
        if (isPrime(i)) {
            primes.push(i);
        }
    }

  const endTime = Date.now() - startTime

    const response = {
        statusCode: 200,
        body: JSON.stringify({
            executionTime: `${endTime} ms`,
            isLambdaWarm: `${isLambdaWarm}`
        }),
    };


    if (!isLambdaWarm) { 
        isLambdaWarm = true
    }

    return response;
};


对于 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 - 对于这两个测试,消耗了相同的内存量:23mb。

NodeJS - 对于素数测试,nodejs 开始消耗 69mb 并上升到 106mb。
对于 API 测试,最小值为 86mb,最大值为 106mb。

执行时间
删除异常值后,结果如下:

Lamba LLRT

Lamba LLRT

最终报告

内存消耗 - 对于内存消耗,我们观察到 LLRT 比 Nodejs 更好地利用了可用资源。

性能 - 我们注意到,在高处理场景下,无论是冷启动还是热启动,节点都保持了远高于 LLRT 的性能。
对于较低的处理场景,LLRT 有一定的优势,尤其是在冷启动方面。

然后让我们等待最终结果,并希望我们能够有更显着的改进,但是很高兴看到 JS 的灵活性并看到它可以并且仍然需要为我们提供多少。


我希望你喜欢它,并帮助你提高对某些事物的理解,甚至开辟通往新知识的道路。我期待您的批评和建议,以便我们改进内容并始终为社区保持更新。

以上是兰巴轻轨的详细内容。更多信息请关注PHP中文网其他相关文章!

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn