Firebase 云功能非常慢
Firebase cloud functions is very slow
我们正在开发一个使用新的 Firebase 云功能的应用程序。当前正在发生的是将事务放入队列节点。然后该函数删除该节点并将其放入正确的节点中。这是因为能够离线工作而实现的。
我们目前的问题是函数的速度。该函数本身大约需要 400 毫秒，所以没关系。但有时函数需要很长时间（大约 8 秒），而条目已经添加到队列中。
我们怀疑服务器启动需要时间，因为当我们在第一次之后再次执行操作时。它花费的时间更少。
有什么办法可以解决这个问题吗？在这里我添加了我们函数的代码。我们怀疑它没有任何问题，但我们添加它以防万一。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
const database = admin.database();
exports.insertTransaction = functions.database
.ref('/userPlacePromotionTransactionsQueue/{userKey}/{placeKey}/{promotionKey}/{transactionKey}')
.onWrite(event => {
if (event.data.val() == null) return null;
// get keys
const userKey = event.params.userKey;
const placeKey = event.params.placeKey;
const promotionKey = event.params.promotionKey;
const transactionKey = event.params.transactionKey;
// init update object
const data = {};
// get the transaction
const transaction = event.data.val();
// transfer transaction
saveTransaction(data, transaction, userKey, placeKey, promotionKey, transactionKey);
// remove from queue
data[`/userPlacePromotionTransactionsQueue/${userKey}/${placeKey}/${promotionKey}/${transactionKey}`] = null;
// fetch promotion
database.ref(`promotions/${promotionKey}`).once('value', (snapshot) => {
// Check if the promotion exists.
if (!snapshot.exists()) {
return null;
}
const promotion = snapshot.val();
// fetch the current stamp count
database.ref(`userPromotionStampCount/${userKey}/${promotionKey}`).once('value', (snapshot) => {
let currentStampCount = 0;
if (snapshot.exists()) currentStampCount = parseInt(snapshot.val());
data[`userPromotionStampCount/${userKey}/${promotionKey}`] = currentStampCount + transaction.amount;
// determines if there are new full cards
const currentFullcards = Math.floor(currentStampCount > 0 ? currentStampCount / promotion.stamps : 0);
const newStamps = currentStampCount + transaction.amount;
const newFullcards = Math.floor(newStamps / promotion.stamps);
if (newFullcards > currentFullcards) {
for (let i = 0; i < (newFullcards - currentFullcards); i++) {
const cardTransaction = {
action: "pending",
promotion_id: promotionKey,
user_id: userKey,
amount: 0,
type: "stamp",
date: transaction.date,
is_reversed: false
};
saveTransaction(data, cardTransaction, userKey, placeKey, promotionKey);
const completedPromotion = {
promotion_id: promotionKey,
user_id: userKey,
has_used: false,
date: admin.database.ServerValue.TIMESTAMP
};
const promotionPushKey = database
.ref()
.child(`userPlaceCompletedPromotions/${userKey}/${placeKey}`)
.push()
.key;
data[`userPlaceCompletedPromotions/${userKey}/${placeKey}/${promotionPushKey}`] = completedPromotion;
data[`userCompletedPromotions/${userKey}/${promotionPushKey}`] = completedPromotion;
}
}
return database.ref().update(data);
}, (error) => {
// Log to the console if an error happened.
console.log('The read failed: ' + error.code);
return null;
});
}, (error) => {
// Log to the console if an error happened.
console.log('The read failed: ' + error.code);
return null;
});
});
function saveTransaction(data, transaction, userKey, placeKey, promotionKey, transactionKey) {
if (!transactionKey) {
transactionKey = database.ref('transactions').push().key;
}
data[`transactions/${transactionKey}`] = transaction;
data[`placeTransactions/${placeKey}/${transactionKey}`] = transaction;
data[`userPlacePromotionTransactions/${userKey}/${placeKey}/${promotionKey}/${transactionKey}`] = transaction;
}
firebaser 在这里
听起来您正在经历所谓的函数冷启动。
当您的函数有一段时间未执行时，Cloud Functions 会将其置于使用较少资源的模式，这样您就无需为未使用的计算时间付费。然后，当您再次点击该功能时，它会从此模式恢复环境。恢复所需的时间包括固定成本（例如恢复容器）和部分可变成本（例如if you use a lot of node modules, it may take longer）。
我们会持续监控这些操作的性能，以确保开发人员体验和资源使用之间的最佳组合。所以希望这些时间会随着时间的推移而改善。
好消息是您应该只在开发过程中体验到这一点。一旦您的功能在生产中被频繁触发，它们很可能再也不会冷启动，尤其是当它们具有稳定的流量时。但是，如果某些功能倾向于看到流量峰值，您仍然会看到每个峰值都是冷启动。在这种情况下，您可能需要考虑 minInstances setting 以始终保持一定数量的延迟关键函数实例热。
2021 年 3 月更新 可能值得查看@George43g 的以下答案，它提供了一个巧妙的解决方案来自动执行以下过程。注意 - 我自己没有尝试过，所以不能保证，但它似乎使这里描述的过程自动化。您可以在 https://github.com/gramstr/better-firebase-functions 阅读更多内容 - 否则请继续阅读以了解如何自己实现它并了解函数内部发生的事情。
2020 年 5 月更新 感谢 maganap 的评论 - 在 Node 10+ 中 FUNCTION_NAME 被替换为 K_SERVICE（FUNCTION_TARGET 是函数本身，而不是它的名称，替换 ENTRY_POINT)。下面的代码示例已更新如下。
更多信息请访问 https://cloud.google.com/functions/docs/migrating/nodejs-runtimes#nodejs-10-changes
Update - 看起来很多问题都可以使用隐藏变量 process.env.FUNCTION_NAME 解决，如下所示：https://github.com/firebase/functions-samples/issues/170#issuecomment-323375462
更新代码 - 例如，如果您有以下索引文件：
...
exports.doSomeThing = require('./doSomeThing');
exports.doSomeThingElse = require('./doSomeThingElse');
exports.doOtherStuff = require('./doOtherStuff');
// and more.......
然后将加载所有文件，并且还将加载所有这些文件的要求，从而导致大量开销并污染所有函数的全局范围。
而是将您的包含分离为：
const function_name = process.env.FUNCTION_NAME || process.env.K_SERVICE;
if (!function_name || function_name === 'doSomeThing') {
exports.doSomeThing = require('./doSomeThing');
}
if (!function_name || function_name === 'doSomeThingElse') {
exports.doSomeThingElse = require('./doSomeThingElse');
}
if (!function_name || function_name === 'doOtherStuff') {
exports.doOtherStuff = require('./doOtherStuff');
}
这只会在特定调用该函数时加载所需的文件；允许您保持全局范围更清洁，这将导致更快的冷启动。
这应该比我在下面所做的更简洁的解决方案（尽管下面的解释仍然有效）。
原答案
看起来在全局范围内需要文件和一般初始化是冷启动期间速度变慢的一个重要原因。
随着项目获得更多功能，全局范围受到越来越多的污染，使问题变得更糟 - 特别是如果您将功能范围划分到单独的文件中（例如通过在 index.js 中使用 Object.assign(exports, require('./more-functions.js')); .
通过将我的所有要求移动到下面的 init 方法中，然后将其作为该文件的任何函数定义中的第一行调用，我已经成功地看到了冷启动性能的巨大提升。例如：
const functions = require('firebase-functions');
const admin = require('firebase-admin');
// Late initialisers for performance
let initialised = false;
let handlebars;
let fs;
let path;
let encrypt;
function init() {
if (initialised) { return; }
handlebars = require('handlebars');
fs = require('fs');
path = require('path');
({ encrypt } = require('../common'));
// Maybe do some handlebars compilation here too
initialised = true;
}
当我将这种技术应用到一个项目时，我看到了从大约 7-8 秒到 2-3 秒的改进，该项目在 8 个文件中包含约 30 个函数。这似乎也导致功能需要冷启动的频率降低（可能是由于内存使用率较低？）
不幸的是，这仍然使 HTTP 函数几乎无法用于面向用户的生产用途。
希望 Firebase 团队在未来有一些计划允许适当的函数范围界定，以便只需要为每个函数加载相关模块。
我也做过这些事情，一旦函数预热就可以提高性能，但是冷启动让我很痛苦。我遇到的另一个问题是 cors，因为它需要两次访问云函数才能完成工作。不过，我确定我可以解决这个问题。
当您的应用处于早期（演示）阶段且不经常使用时，性能不会很好。这是应该考虑的事情，因为拥有早期产品的早期采用者需要在潜在 customers/investors 面前展示他们最好的一面。我们喜欢这项技术，所以我们从旧的久经考验的框架迁移过来，但我们的应用程序在这一点上似乎非常缓慢。接下来我要尝试一些热身策略让它看起来更好
我在使用 firestore 云功能时遇到了类似的问题。最大的是性能。特别是在早期初创公司的情况下，当您负担不起早期客户看到 "sluggish" 应用程序时。例如，一个简单的文档生成函数给出了这个：
-- 函数执行耗时 9522 毫秒，完成状态码：200
然后：我有一个简单明了的条款和条件页面。使用云函数，冷启动导致的执行有时甚至需要 10-15 秒。然后我将它移动到一个 node.js 应用程序，托管在 appengine 容器上。时间已经缩短到 2-3 秒。
我一直在比较 mongodb 和 firestore 的许多功能，有时我也想知道在我的产品的这个早期阶段我是否也应该转移到不同的数据库。我在 firestore 中获得的最大优势是触发文档对象的 onCreate、onUpdate 功能。
https://db-engines.com/en/system/Google+Cloud+Firestore%3BMongoDB
基本上，如果您网站的静态部分可以卸载到 Appengine 环境，这也许不是一个坏主意。
更新：2022 - 再次维护库。 Firebase 现在能够使实例保持温暖，但仍有潜在的性能和代码结构优势。
UPDATE/EDIT：新语法和更新将于 2020 年 5 月推出
我刚刚发布了一个名为 better-firebase-functions 的包，它会自动搜索您的函数目录并正确地将所有找到的函数嵌套在您的 exports 对象中，同时将函数彼此隔离以提高冷启动性能。
如果您延迟加载和缓存模块范围内每个函数所需的依赖项，您会发现这是在快速增长的项目中保持函数最佳效率的最简单和最简单的方法。
import { exportFunctions } from 'better-firebase-functions'
exportFunctions({__filename, exports})
我在 Firebase Functions 中的第一个项目的性能很差，一个简单的函数会在几分钟内执行（知道函数执行的 60 秒限制，我知道我的函数有问题）。我的问题是我没有正确终止函数
如果有人遇到同样的问题，请确保通过以下方式终止该功能：
- 发送 HTTP 触发器的响应
- 返回后台触发器的承诺
这是来自 Firebase 的 youtube link 帮助我解决了问题
由于其中使用了 gRpc 库，Cloud Functions 在与 firestore 库一起使用时冷启动时间不一致。
我们最近制作了一个完全兼容的 Rest 客户端 (@bountyrush/firestore)，旨在与官方 nodejs-firestore 客户端并行更新。
幸运的是，冷启动现在好多了，我们甚至放弃了使用 redis 内存存储作为我们之前使用的缓存。
集成步骤：
1. npm install @bountyrush/firestore
2. Replace require('@google-cloud/firestore') with require('@bountyrush/firestore')
3. Have FIRESTORE_USE_REST_API = 'true' in your environment variables. (process.env.FIRESTORE_USE_REST_API should be set to 'true' for using in rest mode. If its not set, it just standard firestore with grpc connections)
我们正在开发一个使用新的 Firebase 云功能的应用程序。当前正在发生的是将事务放入队列节点。然后该函数删除该节点并将其放入正确的节点中。这是因为能够离线工作而实现的。
我们目前的问题是函数的速度。该函数本身大约需要 400 毫秒，所以没关系。但有时函数需要很长时间（大约 8 秒），而条目已经添加到队列中。
我们怀疑服务器启动需要时间，因为当我们在第一次之后再次执行操作时。它花费的时间更少。
有什么办法可以解决这个问题吗？在这里我添加了我们函数的代码。我们怀疑它没有任何问题，但我们添加它以防万一。
const functions = require('firebase-functions');
const admin = require('firebase-admin');
const database = admin.database();
exports.insertTransaction = functions.database
.ref('/userPlacePromotionTransactionsQueue/{userKey}/{placeKey}/{promotionKey}/{transactionKey}')
.onWrite(event => {
if (event.data.val() == null) return null;
// get keys
const userKey = event.params.userKey;
const placeKey = event.params.placeKey;
const promotionKey = event.params.promotionKey;
const transactionKey = event.params.transactionKey;
// init update object
const data = {};
// get the transaction
const transaction = event.data.val();
// transfer transaction
saveTransaction(data, transaction, userKey, placeKey, promotionKey, transactionKey);
// remove from queue
data[`/userPlacePromotionTransactionsQueue/${userKey}/${placeKey}/${promotionKey}/${transactionKey}`] = null;
// fetch promotion
database.ref(`promotions/${promotionKey}`).once('value', (snapshot) => {
// Check if the promotion exists.
if (!snapshot.exists()) {
return null;
}
const promotion = snapshot.val();
// fetch the current stamp count
database.ref(`userPromotionStampCount/${userKey}/${promotionKey}`).once('value', (snapshot) => {
let currentStampCount = 0;
if (snapshot.exists()) currentStampCount = parseInt(snapshot.val());
data[`userPromotionStampCount/${userKey}/${promotionKey}`] = currentStampCount + transaction.amount;
// determines if there are new full cards
const currentFullcards = Math.floor(currentStampCount > 0 ? currentStampCount / promotion.stamps : 0);
const newStamps = currentStampCount + transaction.amount;
const newFullcards = Math.floor(newStamps / promotion.stamps);
if (newFullcards > currentFullcards) {
for (let i = 0; i < (newFullcards - currentFullcards); i++) {
const cardTransaction = {
action: "pending",
promotion_id: promotionKey,
user_id: userKey,
amount: 0,
type: "stamp",
date: transaction.date,
is_reversed: false
};
saveTransaction(data, cardTransaction, userKey, placeKey, promotionKey);
const completedPromotion = {
promotion_id: promotionKey,
user_id: userKey,
has_used: false,
date: admin.database.ServerValue.TIMESTAMP
};
const promotionPushKey = database
.ref()
.child(`userPlaceCompletedPromotions/${userKey}/${placeKey}`)
.push()
.key;
data[`userPlaceCompletedPromotions/${userKey}/${placeKey}/${promotionPushKey}`] = completedPromotion;
data[`userCompletedPromotions/${userKey}/${promotionPushKey}`] = completedPromotion;
}
}
return database.ref().update(data);
}, (error) => {
// Log to the console if an error happened.
console.log('The read failed: ' + error.code);
return null;
});
}, (error) => {
// Log to the console if an error happened.
console.log('The read failed: ' + error.code);
return null;
});
});
function saveTransaction(data, transaction, userKey, placeKey, promotionKey, transactionKey) {
if (!transactionKey) {
transactionKey = database.ref('transactions').push().key;
}
data[`transactions/${transactionKey}`] = transaction;
data[`placeTransactions/${placeKey}/${transactionKey}`] = transaction;
data[`userPlacePromotionTransactions/${userKey}/${placeKey}/${promotionKey}/${transactionKey}`] = transaction;
}
firebaser 在这里
听起来您正在经历所谓的函数冷启动。
当您的函数有一段时间未执行时，Cloud Functions 会将其置于使用较少资源的模式，这样您就无需为未使用的计算时间付费。然后，当您再次点击该功能时，它会从此模式恢复环境。恢复所需的时间包括固定成本（例如恢复容器）和部分可变成本（例如if you use a lot of node modules, it may take longer）。
我们会持续监控这些操作的性能，以确保开发人员体验和资源使用之间的最佳组合。所以希望这些时间会随着时间的推移而改善。
好消息是您应该只在开发过程中体验到这一点。一旦您的功能在生产中被频繁触发，它们很可能再也不会冷启动，尤其是当它们具有稳定的流量时。但是，如果某些功能倾向于看到流量峰值，您仍然会看到每个峰值都是冷启动。在这种情况下，您可能需要考虑 minInstances setting 以始终保持一定数量的延迟关键函数实例热。
2021 年 3 月更新 可能值得查看@George43g 的以下答案，它提供了一个巧妙的解决方案来自动执行以下过程。注意 - 我自己没有尝试过，所以不能保证，但它似乎使这里描述的过程自动化。您可以在 https://github.com/gramstr/better-firebase-functions 阅读更多内容 - 否则请继续阅读以了解如何自己实现它并了解函数内部发生的事情。
2020 年 5 月更新 感谢 maganap 的评论 - 在 Node 10+ 中 FUNCTION_NAME 被替换为 K_SERVICE（FUNCTION_TARGET 是函数本身，而不是它的名称，替换 ENTRY_POINT)。下面的代码示例已更新如下。
更多信息请访问 https://cloud.google.com/functions/docs/migrating/nodejs-runtimes#nodejs-10-changes
Update - 看起来很多问题都可以使用隐藏变量 process.env.FUNCTION_NAME 解决，如下所示：https://github.com/firebase/functions-samples/issues/170#issuecomment-323375462
更新代码 - 例如，如果您有以下索引文件：
...
exports.doSomeThing = require('./doSomeThing');
exports.doSomeThingElse = require('./doSomeThingElse');
exports.doOtherStuff = require('./doOtherStuff');
// and more.......
然后将加载所有文件，并且还将加载所有这些文件的要求，从而导致大量开销并污染所有函数的全局范围。
而是将您的包含分离为：
const function_name = process.env.FUNCTION_NAME || process.env.K_SERVICE;
if (!function_name || function_name === 'doSomeThing') {
exports.doSomeThing = require('./doSomeThing');
}
if (!function_name || function_name === 'doSomeThingElse') {
exports.doSomeThingElse = require('./doSomeThingElse');
}
if (!function_name || function_name === 'doOtherStuff') {
exports.doOtherStuff = require('./doOtherStuff');
}
这只会在特定调用该函数时加载所需的文件；允许您保持全局范围更清洁，这将导致更快的冷启动。
这应该比我在下面所做的更简洁的解决方案（尽管下面的解释仍然有效）。
原答案
看起来在全局范围内需要文件和一般初始化是冷启动期间速度变慢的一个重要原因。
随着项目获得更多功能，全局范围受到越来越多的污染，使问题变得更糟 - 特别是如果您将功能范围划分到单独的文件中（例如通过在 index.js 中使用 Object.assign(exports, require('./more-functions.js')); .
通过将我的所有要求移动到下面的 init 方法中，然后将其作为该文件的任何函数定义中的第一行调用，我已经成功地看到了冷启动性能的巨大提升。例如：
const functions = require('firebase-functions');
const admin = require('firebase-admin');
// Late initialisers for performance
let initialised = false;
let handlebars;
let fs;
let path;
let encrypt;
function init() {
if (initialised) { return; }
handlebars = require('handlebars');
fs = require('fs');
path = require('path');
({ encrypt } = require('../common'));
// Maybe do some handlebars compilation here too
initialised = true;
}
当我将这种技术应用到一个项目时，我看到了从大约 7-8 秒到 2-3 秒的改进，该项目在 8 个文件中包含约 30 个函数。这似乎也导致功能需要冷启动的频率降低（可能是由于内存使用率较低？）
不幸的是，这仍然使 HTTP 函数几乎无法用于面向用户的生产用途。
希望 Firebase 团队在未来有一些计划允许适当的函数范围界定，以便只需要为每个函数加载相关模块。
我也做过这些事情，一旦函数预热就可以提高性能，但是冷启动让我很痛苦。我遇到的另一个问题是 cors，因为它需要两次访问云函数才能完成工作。不过，我确定我可以解决这个问题。
当您的应用处于早期（演示）阶段且不经常使用时，性能不会很好。这是应该考虑的事情，因为拥有早期产品的早期采用者需要在潜在 customers/investors 面前展示他们最好的一面。我们喜欢这项技术，所以我们从旧的久经考验的框架迁移过来，但我们的应用程序在这一点上似乎非常缓慢。接下来我要尝试一些热身策略让它看起来更好
我在使用 firestore 云功能时遇到了类似的问题。最大的是性能。特别是在早期初创公司的情况下，当您负担不起早期客户看到 "sluggish" 应用程序时。例如，一个简单的文档生成函数给出了这个：
-- 函数执行耗时 9522 毫秒，完成状态码：200
然后：我有一个简单明了的条款和条件页面。使用云函数，冷启动导致的执行有时甚至需要 10-15 秒。然后我将它移动到一个 node.js 应用程序，托管在 appengine 容器上。时间已经缩短到 2-3 秒。
我一直在比较 mongodb 和 firestore 的许多功能，有时我也想知道在我的产品的这个早期阶段我是否也应该转移到不同的数据库。我在 firestore 中获得的最大优势是触发文档对象的 onCreate、onUpdate 功能。
https://db-engines.com/en/system/Google+Cloud+Firestore%3BMongoDB
基本上，如果您网站的静态部分可以卸载到 Appengine 环境，这也许不是一个坏主意。
更新：2022 - 再次维护库。 Firebase 现在能够使实例保持温暖，但仍有潜在的性能和代码结构优势。
UPDATE/EDIT：新语法和更新将于 2020 年 5 月推出
我刚刚发布了一个名为 better-firebase-functions 的包，它会自动搜索您的函数目录并正确地将所有找到的函数嵌套在您的 exports 对象中，同时将函数彼此隔离以提高冷启动性能。
如果您延迟加载和缓存模块范围内每个函数所需的依赖项，您会发现这是在快速增长的项目中保持函数最佳效率的最简单和最简单的方法。
import { exportFunctions } from 'better-firebase-functions'
exportFunctions({__filename, exports})
我在 Firebase Functions 中的第一个项目的性能很差，一个简单的函数会在几分钟内执行（知道函数执行的 60 秒限制，我知道我的函数有问题）。我的问题是我没有正确终止函数
如果有人遇到同样的问题，请确保通过以下方式终止该功能：
- 发送 HTTP 触发器的响应
- 返回后台触发器的承诺
这是来自 Firebase 的 youtube link 帮助我解决了问题
由于其中使用了 gRpc 库，Cloud Functions 在与 firestore 库一起使用时冷启动时间不一致。
我们最近制作了一个完全兼容的 Rest 客户端 (@bountyrush/firestore)，旨在与官方 nodejs-firestore 客户端并行更新。
幸运的是，冷启动现在好多了，我们甚至放弃了使用 redis 内存存储作为我们之前使用的缓存。
集成步骤：
1. npm install @bountyrush/firestore
2. Replace require('@google-cloud/firestore') with require('@bountyrush/firestore')
3. Have FIRESTORE_USE_REST_API = 'true' in your environment variables. (process.env.FIRESTORE_USE_REST_API should be set to 'true' for using in rest mode. If its not set, it just standard firestore with grpc connections)