具有 Firebase 云功能的高 TTFB

Posted 2023-02-24

【中文标题】具有 Firebase 云功能的高 TTFB

【英文标题】：High TTFB with firebase cloud functions

【发布时间】：2020-08-04 15:54:57

【问题描述】：

我有一个获取一些 JSON 数据的云函数。这就是它所做的一切。 我遵循了此视频中突出显示的提示：https://www.youtube.com/watch?v=IOXrwFqR6kY

所以，我有 cors 和 rp 依赖项，在我的功能之外没有任何东西。数据被压缩（我认为这是默认功能）。 Chrome 开发工具显示数据已被 gzip 压缩。压缩后为 37KB。 开发工具一致表明 TTFB 约为 4.5 秒。内容下载仅需 7.8 毫秒左右。

如果我从本地机器向相同的 json 数据发出 curl 请求，我会得到以下信息：

    time_namelookup:  0.028s
       time_connect:  0.225s
    time_appconnect:  0.921s
   time_pretransfer:  0.921s
      time_redirect:  0.000s
 time_starttransfer:  1.574s
                    ----------
         time_total:  1.576s

似乎有很大的差距。如果我没记错的话，应该将 TTFB 与我的 curl 请求的 time_starttransfer 进行比较。 差距是什么原因造成的？这一切都与冷启动有关吗？我的云功能似乎总不能低于 4.6 秒。 根据他们共享的数据，我向其发送请求的服务器的正常运行时间响应相当一致，约为 500 毫秒。

我可以做些什么来将该数字降低到接近 1.5 秒，或者可能更低？

谢谢！

【问题讨论】：

不知道是不是跟冷启动没关系....这种表现是一直一样还是第一次这样然后更好？

是的，我相信这是由于冷启动。似乎 4.5s 是我能用我的简单功能做的最好的事情。我找到了一个解决方案。请看我的回答

【参考方案1】：

好的，所以我找到了方法。对于同样情况下的其他人，这里有一个解释：

我是通过 Firebase 了解 Google Cloud 的，因此直到昨天我才知道 Firebase 是关于 Google Cloud 解决方案的全部内容。来自https://firebase.google.com 的其他 Google 云服务很少提及，或者至少不够明显。

事实证明，Google 没有 1 个，也不是 2 个，而是 5 个不同的云计算选项。 Firebase 的 Cloud Function 是其中之一。还有4个人。 在这里查看这个很好的视频摘要，它遍历了 5 个选项中的每一个，并突出了差异https://www.youtube.com/watch?v=wzPmgWJ5fpU&feature=youtu.be

因此，根据我的理解和经验，云功能是一种无服务器解决方案，旨在与其他 Firebase 服务（例如 Firestore、存储和托管）一起使用。有了这些服务，功能响应速度非常快。 为了与 3rd 方 API 交互，您需要使用其他 4 个解决方案之一，因为从请求到 3rd 方 API 的响应时间远远超出了可接受的范围。 作为指导，Google 建议 TTFB 最长为 200 毫秒 (https://developers.google.com/web/tools/chrome-devtools/network/understanding-resource-timing?hl=ko)。 Lighthouse 的编码 TTFB 阈值为 600 毫秒 (https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/audits/time-to-first-byte.js)。无论如何，这是一个指导方针。

就易用性而言，最接近 Firebase Cloud 功能的是 AppEngine。 https://cloud.google.com/appengine。其他解决方案具有更大的灵活性，但也需要基础架构专业知识。

AppEngine 是一种无服务器解决方案，可让您专注于后端代码，并通过 PAYG 支付方案控制成本。

就编码体验而言，Firebase C.F 旨在让您使用 onCall 方法更轻松。 AppEngine 仍然相对易于使用，您可以快速启动和准备好您的后端。

无论如何，使用 AppEngine，并使用与 OP 中提到的相同的服务器请求和相同的依赖项（cors、compression、rp、express），我可以在 1 秒内获得相同的 JSON 数据（而使用 CF 则需要 4.5 秒） .这是一个很大的进步，不是吗？我可能会得到这个数字甚至更低。

也就是说，有 2 种不同的 AppEngine 配置：标准和弹性。对于我猜的大多数开发人员来说，标准将是显而易见的选择。如果您选择 flex，您可能需要先阅读以下内容：Pricing of Google App Engine Flexible env, a $500 lesson

从纯粹的 Google 客户 POV 来看，我仍然不确定为什么我必须涉及 2 种不同的无服务器服务才能让我的工作正常运行，但就是这样。

我只是希望在他们的 Firebase 网站上更好地描述 Google 的服务，这样可以节省我一些宝贵的时间。由于有人对 reddit 的评论，我了解了 AppEngine。我希望 Google 的人至少可以向我指出他们的其他解决方案作为回复。

【参考方案2】：

为了避免所谓的“冷启动”，实际上是您希望避免查看您的问题，一个好的解决方案是使用 App Engine Flex。

App Engine 是不同平台 Google Cloud Platform (GCP) 的一部分。是的，Firebase 和 GCP 是不同的产品，尽管它们的某些部分相互重叠。 Firebase 旨在用于移动应用，而 GCP 是一个完整的云解决方案。

有些功能确实是一样的。 GCP 项目可以配置为 Firebase 项目，并且每个 Firebase 项目都在后台 GCP 项目中。 Storage、Firesore 和 Functions 等解决方案在幕后是相同的。当您在其中一个平台上创建它们时，它们也可以从另一个平台访问。

如果您想了解更多关于 GCP 和 Firebase 的信息，可以阅读this。

Cloud Functions 是设计上应该经常使用的解决方案，并且它们会自动扩展。如果不使用它们，则不会将它们存储为就绪环境（缩放到 0 个实例）。在第一次使用之前，必须准备好环境：需要创建实例并部署功能。

为避免“冷启动”，您必须使用一种解决方案，让您的应用程序至少有一个实例始终处于活动状态。不错的选择是 App Engine Flex，您可以在其中将最小实例数设置为 1：min_num_instances 用于自动缩放或 instances 用于 app.yaml file 中的手动缩放。

我认为在 GCP 中执行此操作的可能性更大，当您想避免“冷启动”时，App Engine Flex 似乎是自然的选择。

希望对你有帮助！

【讨论】：

伴侣。你的回答不是我在 12 小时前对我自己的帖子的回答几乎是逐字逐句的吗？请阅读我的回答。 AE flex 并不是这里最好的默认解决方案。

我认为这只是该领域的另一种观点。我的答案足够不同，可以单独回答。 :) 我只是专注于这样一个事实，即如果您想很少使用您的功能并始终准备好并提供示例，您必须至少保留一个实例。我多次阅读您的答案，但没有找到。