小编sud*_*cha的帖子

我们有一个小脚本，可以抓取网页（约 17 个条目），并将它们写入 Firestore 集合。为此，我们在 Google Cloud Run 上部署了一项服务。

使用 Docker 容器镜像在本地测试时，此代码的执行需要约 5 秒。部署到 Cloud Run 的同一映像需要 1 多分钟。

即使是“删除集合中的所有文档”这样的简单命令，在本地需要 2-3 秒，而在 Cloud Run 上部署时需要 10 多秒。

我们知道冷启动，所以我们在第三次、第四次和第五次运行中测试了 Cloud Run 的性能，但它仍然很慢。

我们还尝试了 CPU 数、实例数、并发数、内存数，使用两端的默认值和极值，但 Cloud Run 的性能很慢。

这是预期的吗？Cloud Run 的单个实例真的这么弱吗？我们可以做些什么来让它更快吗？

这种缓慢的问题在于，如果我们为大量条目运行我们的代码，Cloud Run 最终会超时（更不用说每秒 Cloud Run 的成本）

在阅读了每一个问题，在线提供的文档后，我们找不到解决方案，所以在这里发布一个问题。

我们的设置：

1. 项目 FB：仅用于开发模式下的 Firestore。我们希望在托管在不同云项目上的开发后端服务器中访问来自该项目的数据。

2. Project GCP：一个 GCP 项目，其应用程序部署在 GAE 中，可以对 Project FB 的文档进行简单的 get() 调用。该应用程序使用 Python 编写，并且在 localhost 中可以完美运行，但在部署之后就不行了。

我们正在测试的样例 Flask 代码：

route('/test-fb', methods=['POST', 'GET'])
def test():
    doc = doc_ref.get()
    if doc.exists:
        print(u'Document data: {}'.format(doc.to_dict()))
    else:
        print(u'No such document!')
    return make_response("Firestore worked!")

笔记：

1. 这不是 Firestore 规则的问题，因为我们使用的是服务帐户密钥。为了在任何情况下 100% 确定，我们将规则设置为：始终为真

   match /{document=**} { 允许读、写：如果为真

2. 我们通过转到“设置 -> 服务帐户”来生成服务帐户私钥，生成新的私钥。然后在我们的代码上方使用 Python 中的 Admin SDK 配置片段代码。这在本地主机中完美运行。

3. 意识到所需的服务帐户权限，我们为 Project GCP (@appspot.gserviceaccount.com) 的 GAE 服务帐户的 Project FB IAM 帐户添加了许多权限，包括“编辑器”、“存储管理员”和“云数据存储所有者”

4. 所有 Firestore 包，任何其​​他依赖项都更新到最新版本。

5. 创建新密钥以再次测试。对于 Project FB，更新了凭据 -> …