Firebase 意外的并发连接数

Question

我刚刚遇到了一个促使我问这个问题的情况：

我每月有大约 150 名活跃用户，我在一天内的并发连接数刚刚达到 1k。

我进行了研究，发现许多关于“firebase 并发连接”主题的问题，那些提到用户与并发比率的人说，平均而言，它接近 1 个并发 = ~1400 个每月用户（例如 here 和 @987654322 @)。

我现在正试图了解我是否真的做错了什么，如果是，如何解决？

问题是：

• 与大约 150 个活动用户获得 1k 并发连接看起来可以吗？还是我看错了？
• 是否可以以某种方式分析并发连接？
• 关于 chrome 扩展，典型的“连接泄漏”有哪些？如何避免？

到目前为止，扩展的架构是所有与 firebase 数据库的通信都是通过后台持久脚本进行的，该脚本对于浏览器实例是全局的。

请注意，150 个活跃用户是一个估计值。对于上限，我可以说我总共有 472 个用户记录，其中一半安装了扩展程序并在此后不久将其卸载 - 所以他们没有使用它。大约 20% 的已安装实例也在 chrome 中被禁用。

Answer 1

这是我与支持团队讨论后得到的结果：

这里有其他常见的用例，可以加起来 应用中的连接：

• 在浏览器的多个选项卡中打开您的网络应用（每个选项卡 1 个连接）
• 从 Firebase 控制台访问实时数据库仪表板（每个选项卡 1 个连接）
• 拥有实时数据库触发器

所以Realtime Database triggers 似乎是我的情况。

进一步的讨论揭示了以下内容：

在上传 200 个数据点的情况下，每个数据点都会触发 函数，1 到 200 之间的任意数量的并发连接是 可能的。这完全取决于 Cloud Functions 的扩展方式。在一个极端 如果它可能只是一个处理所有 200 个事件的实例之一 一次。在另一个极端情况下，Cloud Functions 系统可以 决定启动 200 个新的服务器实例来处理传入的 事件。无法保证这里会发生什么，Cloud 函数会尝试做正确的事情。每个案件将花费 用户的 Cloud Functions 账单上的金额相同。什么最有可能 在一个真实的应用程序中（它不是一个完整的冷启动）是 中间的东西。

无需担心并发连接数 从 Cloud Functions 到 RTDB。 Cloud Functions 永远不会启动 接近 10 万个服务器实例。所以没有办法云函数 会吃掉整个并发限制。这只会发生在 客户端应用程序上有许多用户访问您的数据库 直接从他们的设备上。

所以我的问题中描述的行为似乎是可以预料的，它不会接近服务器端 100k 连接的限制。