兰巴轻轨

首页 > 编程 > 兰巴轻轨

发布于2024-08-23

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

您是否曾经想过，我们对应用程序性能的要求越来越高？
我们每天都面临着让它们更快的挑战，因此，我们需要评估使我们能够实现结果的解决方案和架构。

因此，我们的想法是发表一篇简短的文章，介绍一项新的演变，可以帮助我们显着提高 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 怎么说：

在很多情况下，与 JIT 支持的运行时相比，LLRT 表现出显着的性能缺陷，例如大数据处理、蒙特卡洛模拟或执行数十万或数百万次迭代的任务。当应用于专用于数据转换、实时处理、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 



对于 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。 

执行时间

删除异常值后，结果如下：





最终报告

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

性能 - 我们注意到，在高处理场景下，无论是冷启动还是热启动，节点都保持了比 LLRT 更好的性能。

对于较低的处理场景，LLRT有一定的优势，尤其是在冷启动方面。

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


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