具有Firebase云功能的高TTFB

Question

我有一个云函数，可以获取一些JSON数据。这就是它的全部功能。我遵循了视频中强调的提示：https://www.youtube.com/watch?v=IOXrwFqR6kY

所以，我有cors和rp依赖项，除了我的函数之外什么都没有。数据是压缩的（我认为这是默认功能）。Chrome开发工具显示数据是gzip压缩的。压缩后是37KB。开发工具一致显示TTFB约为4.5秒。内容下载仅约为7.8ms

如果我从本地计算机对相同的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秒的总长度。根据他们共享的数据，我发送请求的服务器的正常运行时间相当一致，约为500ms。

我该怎么做才能把这个数字降低到接近1.5秒，或者可能更低？

谢谢你！

Answer 1

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

App Engine是不同平台Google Cloud platform（GCP）的一部分。是的，Firebase和GCP是不同的产品，尽管在某些方面相互重叠。Firebase是为移动应用设计的，而GCP是一个完整的云解决方案。

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

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

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

为了避免“冷启动”，您必须使用一种解决方案，使应用程序的至少一个实例始终处于活动状态。App Engine Flex是一个不错的选择，你可以将最小实例数设置为1:minnum\u实例用于自动缩放，或者在App中手动缩放实例。yaml文件。

我认为在GCP中有更多的可能性，当你想要避免“冷启动”时，App Engine Flex似乎是自然的选择。

我希望这会有帮助！

Answer 2

好吧，我找到了路。对于同一案例中的其他人，以下是一个解释：

我是通过Firebase被介绍给谷歌云的，因此直到昨天，Firebase还是我对谷歌云解决方案的全部了解。很少有人提到，或者至少还不够明显地提到谷歌的其他云服务https://firebase.google.com.

事实证明，谷歌没有1个，不是2个，而是5个不同的云计算选项。Firebase的云功能就是其中之一。还有4个。请看下面这段精彩的视频摘要，它介绍了5个选项中的每一个，并很好地突出了它们之间的差异https://www.youtube.com/watch?v=wzPmgWJ5fpU

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

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

AppEngine是一个无服务器解决方案，允许您专注于后端代码，并通过付费方案控制成本。

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

无论如何，使用AppEngine，使用OP中提到的相同的服务器请求和相同的依赖关系（cors、压缩、rp、Express），我可以在1秒内获得相同的JSON数据（而使用C. F.则为4.5秒）。这是一个相当大的改进，不是吗？我可能可以得到更低的数字。

也就是说，有两种不同的AppEngine配置：标准配置和flex配置。我猜标准配置对大多数开发人员来说是显而易见的选择。如果你选择flex，你可能想先读一下：谷歌应用引擎灵活环境的定价，一个500美元的教训

从一个纯粹的谷歌客户观点来看，我仍然不确定为什么我必须涉及两个不同的无服务器服务来让我的东西工作，但这就是方法。

我只希望谷歌的Firebase网站能更好地描述谷歌的服务，这会为我节省一些宝贵的时间。由于有人对reddit的评论，我了解了AppEngine。我希望谷歌的人至少能给我指出他们的其他解决方案作为回答。