当我使用 git & npm install 时，AWS EFS 太慢了答案

【问题标题】：AWS EFS too slow when i use git & npm install当我使用 git & npm install 时，AWS EFS 太慢了
【发布时间】：2020-09-06 19:18:25
【问题描述】：

我正在为我的几十个静态网站使用 aws S3 存储和云端。我也将 aws lambda 与 nodejs 和 EFS 一起用于 git、node_modules 和构建缓存文件。

当我尝试来自 EFS 的 git clone、npm install 和 npm run build 时，它的工作速度变慢了。但是当我从 lambda /tmp 文件夹尝试时，它的工作速度比 EFS 存储快 10 倍。

我需要像 EFS 这样的存储，因为我存储了几十个网站 git、节点包和缓存文件。那么如何提高 EFS 性能。

【问题讨论】：

我能问一下为什么文件需要在 EFS 上。如果您可以提供有关用例的更多信息，那将有所帮助:)
@ChrisWilliams 感谢您的评论。我正在用 gatsbyjs 构建我的网站。它为每个需要构建的站点运行 aws-lambda "npm run build" 命令。我选择 EFS 是因为我需要一个存储空间来保存以前使用 git clone 和 npm install 安装的文件。
在我以前的角色中，我们决定不将 EFS 用于 kubernetes gitlab 部署，因为对于 gitlab\git，不建议使用 EFS：“客户和用户报告说 AWS EFS 在 GitLab 的用例中表现不佳. 许多小文件以序列化方式编写的工作负载，如 git，不适合 EFS。顶部有 NFS 服务器的 EBS 会表现得更好。相反，我们选择使用 EBS 卷。 docs.gitlab.com/ee/administration/nfs.html你的代码库不能使用代码提交吗？

标签： amazon-web-services aws-lambda amazon-efs

【解决方案1】：

如果您已使用 EFS 的标准设置，您将使用可突发的积分，您所做的文件更改越多，这些积分就会耗尽。

根据文件大小和 EFS 挂载上的更改数量，您可能会耗尽可用积分，这会给附加到 EFS 挂载的任何应用程序带来性能问题。您可以通过查看 BurstCreditBalance CloudWatch 指标来检测这一点，同时注意 TotalIOBytes 的任何扁平化，因为这可能表明它已达到其最大吞吐量。

当您执行 git clone 时，您还可以使用值为 1 的 --depth 创建一个浅克隆。此选项将仅获取最新提交，而不是克隆整个 git 历史记录。

对此工作流程的改进我建议重新考虑使用以下技术来提供您想要的工作流程。与其创建 Lambda 函数，不如创建一个 CodePipeline 管道，该管道将触发 CodeBuild 作业。此 CodeBuild 作业将负责为您运行 npm install 任务以及任何其他操作。

CodePipeline 流程的一部分是它将沿途将遗留工件存储在 S3 中，以便您拥有它的副本。 CodePipeline 也可以在最后部署到您的 S3 存储桶。

几个可能对你有用的链接：

【讨论】：

这个建议正是我所采用的，github 用于源代码和一个代码管道，主要由一组代码构建作业和一个包含通用代码的自定义构建代理组成。工作得很好，除了代码管道需要提前知道分支，这意味着我只有一个主管道，并依赖几个代码构建作业来处理功能分支推送和拉取请求 webhook，
@berimbolo CodePipeline 绑定到单个分支，但 CodeBuild 没有。如果您直接使用 CodeBuild，则可以从任何 git commit/branch 构建。
是的，我知道，并且我确实使用（如我所提到的）代码构建作业单独用于功能推送和 PR，这是在我的更改合并到 master 之前，一旦合并到 master 我就会触发代码主管道上的管道......在管道之外运行代码构建只会让我到目前为止，例如手动批准阶段或想要轻松地将代码构建链接在一起使用代码管道很容易......