我正在尝试使用Cloud Run来运行连接到Firestore的微服务。微服务基于s2geometry创建对象，以创建具有特定属性的多个地理区域，从而帮助本地化用户根据我定位他们的区域向他们发送信息。
我使用Python 3.7和FastAPI创建了微服务以及与之通信的路由
微服务在我的本地机器和计算引擎上运行平稳，因为当我测试它们时，我的大多数路由需要不到150毫秒的时间来回答。然而，当我使用Cloud Run部署它时，我遇到了一个延迟问题。微服务有时需要很长时间才能回答(长达15分钟(，我无法确定具体原因。
这是一个屏幕截图，我们可以在其中看到请求计数和请求延迟：
请求计数和请求延迟
请求延迟和请求数量之间没有真正的相关性，或者至少没有微不足道的相关性。我还查看了该服务的内存使用情况，内存使用率最多为30%。然而，CPU使用率有时会达到100%，但在请求缓慢时不一定如此。
最后，当我浏览跟踪列表并比较具有高延迟的请求时，我注意到的以下差异
跟踪慢速请求
跟踪快速请求
快速请求似乎自称，而慢速请求则不然，我不知道为什么。
目前我们的用户并不多，所以我认为这可能是一个冷启动问题，但慢请求不一定是第一个。
现在，老实说，我不知道这里发生了什么，也不知道Cloud Run做了什么(或者我做错了什么(，我也发现很难找到一个关于Cloud Run实际工作原理的彻底解释，所以如果你有一个(除了谷歌的(，我很乐意深入研究。
非常感谢您对的帮助
经过几次测试后，似乎是冷启动问题。如果不使用Cloud Run容器，它们会在一段时间后停止使用，而且由于我们没有太多流量，每次用户想要访问应用程序时，容器都必须重新启动。
解决方案：
我创建了一个Cloud Function，它在触发时向容器发送请求，然后创建了一份每分钟运行一次该函数的Cloud Scheduler作业。
注意：
如果不同的修订被路由到您的服务，您需要为每个修订创建一个Cloud Scheduler作业。为此，您必须为每个路由的修订(当前为测试版(创建一个修订URL(标记(。
编辑：
现在，正如@Jofre所提到的，您可以通过设置"；实例的最小数目"；至1。如果你正在使用控制台GCP，甚至告诉你"；设置为1以减少冷启动"；。