【问题标题】:Firebase Dynamic Pages using Cloud Functions with Firestore are slow使用 Cloud Functions 和 Firestore 的 Firebase 动态页面速度很慢
【发布时间】:2018-11-12 22:10:56
【问题描述】:

我们有 动态页面Firebase Cloud Functions 提供服务,但是 TTFB 在这些页面上非常慢,TTFB 为 900ms - 2s,起初我们只是假设它是一个cold start 问题,但即使流量稳定,在700ms - 1.2s 的TTFB 上也很慢。

这对我们的项目来说有点问题,因为它依赖于自然流量,而且 Google Pagespeed 需要的服务器响应小于200ms

无论如何,我们尝试检查可能导致问题的原因,并使用 Firestore 进行了定位,当云函数访问 Firestore 时,我们注意到存在一些延迟。这是我们如何实现 Cloud Function 和 Firestore 的基本示例代码:

dynamicPages.get('/ph/test/:id', (req, res) => {

    var globalStartTime = Date.now();
    var period = [];

    db.collection("CollectionTest")
        .get()
        .then((querySnapshot) => {

            period.push(Date.now() - globalStartTime);

            console.log('1', period);

            return db.collection("CollectionTest")
                .get();

        })
        .then((querySnapshot) => {

            period.push(Date.now() - globalStartTime);

            console.log('2', period);

            res.status(200)
                .send('Period: ' + JSON.stringify(period));

            return true;

        })
        .catch((error) => {

            console.log(error);
            res.end();

            return false;

        });

});

这是在 Firebase + Cloud Functions + NodeJS

上运行的

CollectionTest 非常小,里面只有 100 个文档,每个文档都有以下字段:

directorName: (string)
directorProfileUrl: (string)
duration: (string)
genre: (array)
posterUrl: (string)
rating: (string)
releaseDate: (string)
status: (int)
synopsis: (string)
title: (string)
trailerId: (string)
urlId: (string)

通过这个测试,我们会得到以下结果:

[467,762] 1.52s
[203,315] 1.09s
[203,502] 1.15s
[191,297] 1.00s
[206,319] 1.03s
[161,267] 1.03s
[115,222] 843ms
[192,301] 940ms
[201,308] 945ms
[208,312] 950ms

此数据为 [Firestore 调用 1 执行时间Firestore 调用 2 执行时间] TTFB

如果我们检查测试结果,有迹象表明 TTFB 正在变低,可能是 Cloud Function 已经预热的时候?但即便如此,根据我们第二次 Firestore 调用的结果,Firestore 在 Cloud Function 中消耗了 200-300 毫秒,即使 Firestore 执行时间较短,TTFB 仍将占用 600-800 毫秒,但那是另一回事。

无论如何,任何人都可以帮助我们如何提高 Cloud Functions 中的 Firestore 性能(或者如果可能的话,提高 TTFB 性能)?也许我们正在做一些我们不知道的明显错误的事情?

【问题讨论】:

  • 您有免费或付费计划吗?因为带宽变化很大,性能也随之改变:see the firebase plans
  • @Emanuele 我们正在使用 blaze 计划

标签: node.js firebase google-cloud-firestore google-cloud-functions


【解决方案1】:

我会尽力提供帮助,但在返回 dynamicPages 之前可能缺少一些关于您加载的内容的背景信息,但这里有一些线索:

首先,最明显的部分(无论如何我都要指出来):

1 - 注意如何测量 TTFB:

远程测量 TTFB 意味着您也在测量网络 延迟同时掩盖了 TTFB 实际上是什么 衡量:网络服务器响应请求的速度。

2 - 来自 Google Developers 关于Understanding Resource Timing (here) 的文档:

[...]。要么:

Bad network conditions between client and server, or
A slowly responding server application

要解决高 TTFB 问题,首先要切断尽可能多的网络。 理想情况下,在本地托管应用程序,看看是否还有大 TTFB。如果有,那么应用程序需要针对 响应速度。这可能意味着优化数据库查询, 为内容的某些部分实现缓存,或修改 您的网络服务器配置。后端可能有很多原因 慢。您将需要对您的软件进行研究并弄清楚 什么不符合您的绩效预算。

如果本地 TTFB 较低,则说明您的客户端与 服务器是问题。网络遍历可能会受到阻碍 任何数量的东西。客户和客户之间有很多点 服务器,每个都有自己的连接限制,并且可以 造成问题。测试减少这种情况的最简单方法是将 您的应用程序在另一台主机上,看看 TTFB 是否有所改善。

不那么明显的:

您可以在此处查看有关 Cloud Functions Performance 的 Google 官方文档:https://cloud.google.com/functions/docs/bestpractices/tips

您之前需要一些文件吗?

根据Firebase cloud functions is very slow的这个回答:Firebase cloud functions is very slow

看起来很多这些问题都可以使用隐藏来解决 变量 process.env.FUNCTION_NAME 如下所示: https://github.com/firebase/functions-samples/issues/170#issuecomment-323375462

这些加载的动态页面是由guest 用户还是logged 用户访问的?因为可能第一个请求要理清身份验证细节,所以已知会比较慢……

如果这些都不起作用,我将看看常见的性能问题,例如数据库连接 (here: Optimize Database Performance)、改进服务器配置、尽可能缓存并处理应用程序中可能出现的重定向。 ..

最后,通过互联网阅读,您的问题有很多线程(简单的 Cloud Functions 性能低下)。喜欢这个:https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2374 && 在 S.O:https://stackoverflow.com/search?q=%5Bgoogle-cloud-functions%5D+slow

与 cmets 类似:

由于使用云功能,每次http都会产生惩罚 调用开销仍然很高(即每次 HTTP 调用 0.8 秒)。

或:

请注意,Cloud Functions 和 Cloud Firestore 都在 beta 并且不提供性能保证。我确定如果你 与实时数据库比较性能,你会看到更好 数字。

也许这仍然是一个问题。

希望对你有帮助!

【讨论】:

  • 您好,感谢您的回答。虽然我们的目标是从整体上减少 TTFB,但我的问题有一个关于 Firestore 的核心问题。因为即使我们可以将 TTFB 因素降低到最低,仍在服务器端消耗 200-300 毫秒的 Firestore 问题仍然会影响 TTFB。我希望先解决 Firestore 问题,然后再解决 TTFB 问题,因为就像您指出的那样,TTFB 有很多因素,而且在大多数情况下都是个案。
猜你喜欢
  • 2019-09-09
  • 1970-01-01
  • 2021-06-04
  • 2018-08-18
  • 1970-01-01
  • 2018-11-21
  • 2019-10-06
  • 1970-01-01
  • 2018-10-16
相关资源
最近更新 更多