选择 Google Cloud Run 中的实例数量
我正在 Google Cloud Run 中运行连接到 Cloud SQL 数据库的 PHP-FPM 应用程序。我的应用程序在正常使用中运行良好，但我们有时会发布大量产品，并期望较高的流量负载。我们提前知道客户何时发布他们的产品，流量会增加，因此我们能够相应地规划我们的服务器容量。
我们预计大约有 1000 位客户，他们会疯狂地刷新页面。这将对我们的数据库产生很大的压力，因为许多端点会对数据库产生大量的查询。 我一直在运行 Siege 来加载测试我的应用程序，因此我知道我们的数据库是服务器负载增加时的临界点。通常我们只在一个 Cloud Run 实例上运行。我还从早期的 Siege 测试运行中了解到，大量流量会导致 Cloud Run 动态启动新实例。对于我们的应用程序来说，这是一个非常耗时的过程，导致平均请求处理时间较长。因此，我们希望有超过 1 个容器实例可供发布。 对于早期且较小的版本，我们已将最小容器数量增加到 20 个，但这个数字几乎是出乎意料的。 因此，我正在寻找在 Cloud Run 中运行这些版本的最佳设置，但是 我正在努力寻找关于我应该运行多少个 Cloud Run 实例（“最小服务器”和“最大服务器”）的任何好的答案。
这些是我的相关应用程序配置：
Cloud Run 配置：
8 GB RAM
4 CPUs
Maximum requests per container: 80
数据库配置：
15 GB RAM
4 CPUs
EDIT: Can handle 4000 simultaneous connections
相关 PHP-FPM 配置：
pm = dynamic
pm.max_children = 375 (formula: (8000MB - 500MB)/ 20MB. Memory of server minus some "extras", limited to 20 MB per child.)
pm.start_servers = 37 (formula: 10% of pm.max_children)
pm.min_spare_servers = 35 (Bit of a guess, must be less than pm.start_servers.
pm.max_spare_servers = 100 (Bit of a guess on my side)
因此，我的 Cloud Run 实例总共接受 80 个并行请求，而我的 PHP-FPM 允许 375 个子进程。
我在 Cloud Run 并发文档中看到“...当您设置了最大实例限制，在某些情况下，没有足够的实例来满足该流量负载，在这种情况下，传入请求可能会排队长达 10 秒”。 对我们来说，不要丢弃任何请求很重要，因此运行的实例也不能太少。
我的问题：
是否有任何涉及进程数量、服务器硬件或任何上述规格的公式可以为我指明 Cloud Run 中理想的实例数量？
我是否应该限制 Cloud Run 可以启动的最大容器数量？我非常有信心 100 个 Cloud Run 容器同时向我的数据库发送垃圾邮件将导致灾难。
在我的应用程序之外实现单独的排队功能是否是一个好主意，这样它就不会过载？
有人可以向我指出一些其他资源，可以帮助我找到正确的方向吗？我能找到的唯一合适的东西是关于 Pluralsight 的课程，高性能 PHP< /a>，但它不包括在云中运行和扩展应用程序。
我知道这些问题的答案并不完全是黑白分明的，但我正在寻找一些指导方针，因为我认为 Cloud Run 文档并不是特别有启发性。我不知道以后应该用2个还是20个容器。
PS：这种升级仅在非常有限的时间内进行，因此我不关心运行许多容器的成本。我只是想要最好的性能和最小的灾难机会。
I am running a PHP-FPM application inside Google Cloud Run connected to a Cloud SQL database. My application is running fine in normal use, but we sometimes release a large amount of products, and expect a high traffic load. We know in advance when our customers release their products and the traffic will increase, so we are able to plan our server capacity accordingly.
We are expecting about 1000 customers, who will refresh the page like crazy. That will generate a lot of pressure on our database, as many of the endpoints generate a huge amount of queries to the database.
I have been running Siege to load test my application, and I therefore know that our database is the critical point when the server load increases. Normally we run on only one Cloud Run instance. I also know from earlier test runs with Siege, that much traffic causes Cloud Run to spin up new instances on the fly. This was a very time consuming process for our application, resulting in a high average request processing time. For this reason, we want to have more than 1 container instance ready for the release.
For earlier, and smaller, releases, we have bumped the minimum number of containers to 20, but that number is taken pretty much out of the blue.
Therefore I am looking for the optimal setup to run in Cloud Run for these releases, but
I am struggling to find any good answers to how many Cloud Run instances I should run, both "min servers" and "max servers".
These are my relevant application configs:
Cloud Run configs:
8 GB RAM
4 CPUs
Maximum requests per container: 80
Database configs:
15 GB RAM
4 CPUs
EDIT: Can handle 4000 simultaneous connections
Relevant PHP-FPM configs:
pm = dynamic
pm.max_children = 375 (formula: (8000MB - 500MB)/ 20MB. Memory of server minus some "extras", limited to 20 MB per child.)
pm.start_servers = 37 (formula: 10% of pm.max_children)
pm.min_spare_servers = 35 (Bit of a guess, must be less than pm.start_servers.
pm.max_spare_servers = 100 (Bit of a guess on my side)
So my Cloud Run instance is accepting a total of 80 parallel requests, and my PHP-FPM allows 375 child processes.
I have seen in Cloud Run concurrency docs that "...when you set a maximum instances limit, in some scenarios there will be insufficient instances to meet that traffic load. In that case, incoming requests can be queued for up to 10 seconds".
It is important to us not dropping any requests, so I can not have too few instances running either.
My questions:
Is there any formula involving number of processes, server hardware or any of the abovementioned specs that could point me to an ideal number of instances in Cloud Run?
Should I limit the max number of containers that Cloud Run can spin up? I am pretty confident that 100 Cloud Run containers all spamming my database simultaneously will lead to disaster.
Could it be a good idea to implement a separate queuing functionality outside of my application, so that it is not overloaded?
Could anyone point me to some other resources that can get me in the right direction here? The only proper thing I have been able to find is a course on Pluralsight, High Performance PHP, but it does not cover running and scaling your application in the cloud.
I understand that the answers to these questions are not completely black and white, but I am looking for some guidelines, as I don't find the Cloud Run docs especially enlightening. I don't know whether I should use 2 or 20 containers in the future.
PS: This upscaling is for a very limited time only, so I don't care about the cost of running many containers. I simply want the best performance with the least chance of disaster.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
此类高级主题需要测试、深入分析以及对基础设施所有元素的深入了解。无论如何，我会尝试回答一些关键点。
首先，我不知道任何公式来知道Cloud Run实例的正确数量。
Cloud Run 的强大之处在于自动扩展和缩减的能力。但是，我知道容器启动时间很长，您更愿意避免该功能以保持较低的请求延迟（请注意，冷启动仅发生一次，然后您的查询会快速得到服务，因此考虑到请求量，影响很小你有（即百分比），但我可以理解你的用例）。
要解决该问题，您可以设置最小实例数。这些实例已启动并保持温暖。您不必启动它们来提供流量。但是，您将支付提供流量的标准实例的 10% 的 CPU 成本和 100% 的内存成本。
要设置多少个实例？这不是一个 Cloud Run 问题，而是一个数据库问题：一个 Cloud Run 实例可以与数据库创建多少个连接？有多少个连接可以接受数据库？当然，可以在数据库上执行多少个查询而不会使数据库崩溃（您还可以考虑只读副本来解决一些挑战）
您还必须监视 Cloud Run 实例，以确保始终有足够的容量，不会丢失任何数据要求。 Cloud Run 还可以自动将请求排队最多 10 秒，无需为此添加外部层。
我的答案并不完美，但可以帮助您更快地做出正确的选择。
Advanced topics like that required tests, deep analysis and good knowledge of all the element of your infrastructure. Anyway, I will try to answer some keypoints.
Firstly, I don't know any formula to know the correct number of instance of Cloud Run.
The power of Cloud Run is the capacity to scale up and down automatically. However, I understand that a container start is very long and you prefer avoid that feature to keep the request latency low (note that the cold start occur only once and then your queries are served fast, so the impact is minimal considering the volume of request that you have (i.e. in percentage), but I can understand your use case).
To solve that issue, you can set a min number of instance. Those instances are started and kept warm. You don't have to start them to serve traffic. However, you will pay 10% of the CPU cost and 100% of the memory cost of a standard instance serving traffic.
How many instances to set? It's not a Cloud Run question but a database question: How many connections one Cloud Run instance can create with the database? And how many connections can accept the database? And of course, how many query can be performed on your database without crashing it (you can also think about read replicas to solve some challenges)
You also have to monitor the Cloud Run instances to be sure to always have enough capacity no to drop any request. Cloud Run can also queue automatically the request up to 10 seconds, no need to add an external layer for that.
My answer is not perfect, but can help you to go quicker to the right choice.