英文:
Is there any significant overhead to running Google Clouds Tasks (e.g. push queues)?
问题
Google Cloud Tasks（例如，推送队列）运行时是否有重大开销？
例如，如果一个任务执行了10个操作（例如，对Datastore进行10次调用），与每个任务执行相同操作的10个任务相比，是否会有更多的计算成本开销？当然，其他一切都相等。
最近，亚马逊Prime Video在新闻中展示了如何通过摆脱无服务器架构节省了大量资金。在某种程度上，Cloud Tasks有点像无服务器，所以我很好奇它们是否会以类似的方式变得昂贵。
是否有一种方法可以计算我的应用程序中的上述成本？
英文:
Is there any significant overhead to running Google Clouds Tasks (e.g. push queues)?
For example, will there be more overhead computational cost if you have one Task that does 10 operations in it (for example, making 10 calls to the Datastore) versus if you have 10 Tasks where each task does 1 of the same operation? All other things being equal of course.
Recently in the news Amazon Prime Video showed how it saved a lot of money by moving off of serverless architecture. In a way, Cloud Tasks are a bit like serverless so I am curious if they could become expensive in a similar way.
Is there a way to calculate the above costs in my application?
答案1
得分: 2
答案很复杂。
如果您使用云函数并且一个任务使用XX个CPU周期，那么在1个函数上有10XX个周期，或者在10个函数上有XX个周期，严格来说是一样的。粗略地说，
事实上，如果您深入了解，云函数的计费上限是100毫秒。因此，
- 如果您的任务需要20毫秒才能完成，如果在同一个云函数上运行10个任务，它将花费10x20 -> 200毫秒的计费CPU。
- 如果您有10个函数每个运行20毫秒，成本将每个函数100毫秒，总共为10个任务1000毫秒，是5倍。
如果任务需要很多秒才能完成，可以忽略这个差异
我可以继续深入探讨并使事情更加复杂！如果您使用Cloud Run，您可以同时处理相同实例（CPU和内存）的任务。
与云函数相反，（使用gen1）每个进程（每个任务）都会创建1个实例（CPU +内存）
在这种情况下，有2种情况：
- 您的进程需要大量CPU资源，并且在同一实例上进行并发处理毫无意义（您无法将CPU使用率共享到100％！），每个任务1个实例更好
- 您的进程大部分时间都在等待（通常在执行API调用时，进程会等待很长时间（50 - 200毫秒）以获取API响应。在进程等待时，可以执行其他操作，比如处理其他任务并生成API调用（或在接收时处理响应）。通过这种配置，您可以增加整体延迟，但显然可以减少成本。
还要考虑的另一个参数是函数的“init”和“outro”。
考虑这个设计：
- 初始化某些内容
- 执行任务（们）
- 格式化和发送答案。
同样，在这里，如果“init”和“格式化答案”需要大量CPU周期，并且在中间执行1个或10个任务没有实际区别，将任务分组到同一个函数中是明显的优势。
相反，如果它们不相关，那么根据我之前的描述，“相等”。
一种尺寸并不适合所有情况！！最佳选择取决于您的应用程序设计和行为！这是云架构师的真正工作！
英文:
The answer is complex.
If you use Cloud Functions and one task uses XX CPU cycles, have 10XX cycles on 1 function, or 10 functions of XX cycles is strictly the same. Roughtly
Indeed, if you go in the detail, on Cloud Functions the billing is at upper bound of 100ms. Therefore,
- if your task take 20ms to complete, if you run the 10 tasks on the same Cloud Functions, it will take 10x20 -> 200ms of billed CPU
- If you have 10 functions that run 20ms, the cost will be 100ms for each function, and there 1000ms for the 10 tasks, 5 time more.
That difference can be ignore is the tasks take many seconds to complete
I can continue in that headache and blur more the things! If you use Cloud Run, you process the tasks concurrently with the same instance (CPU and memory).
At the opposite of the Cloud Functions where (with gen1) 1 instance (CPU + memory) is created for each process (each task)
In that situation, there is 2 cases:
- Your process is CPU intensive and the concurrency on the same instance makes no sense (you can't share a CPU use at 100%!), and 1 instance per task is better
- Your process wait most of the time (typically when you perform an API call, the process wait a lot (50 - 200ms) the API answer. While the process wait, another things can be performed, like processing the other tasks and generate also API calls (or process the response when receive). With that configuration you could increase the whole latency, but clearly reduce the cost.
Another parameter to take into account is the "intro" and "outro" of the functions
Take this design:
- init something
- perform the task(s)
- format and send the answer.
Here again, if the "init" and the "format answer" take lot of CPU cycles, and there is no real differences if there is 1 or 10 tasks performed in the middle, it's a clear advantage to group the tasks in a same function.
At the opposite, if they are not relevant, it's "equal" (according to my description before).
One size does not fit all!! And the best choice depends on your app design and behavior! That's the real job of a cloud architect!
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论