Google App Engine可以长时间运行但CPU任务较少,还是长轮询?

时间:2016-08-28 06:55:05

标签: google-app-engine google-compute-engine

App Engine非常适合快速处理的请求,无需对数据库或缓存或第三方资源进行外部API调用,但我们发现引入任何类型的长时间运行"组件或外部延迟(例如,在后台异步运行的HTTP POST操作中,可能需要一两秒钟才能处理更强烈的数据库查询...从客户端的UX角度来看,完全不可见和正常,因为它是异步但却昂贵的App Engine计费,因为它长期运行)..."实例小时"复合和驱动成本大大增加。

这些费用导致一种情况,即请求实际上只是等待来自外部资源的响应并且在空闲期间需要几乎为零的CPU 似乎可以避免,但我不确定是否App Engine可以避免这种情况。

它几乎就像一个长期的民意调查"响应可能会保持开放但什么也不做。

有没有办法在App Engine上执行此操作而不需要支付疯狂的金额例如几小时,或者我们最好转移到Compute Engine或EC2?它是根据CPU负载自动扩展,还是仅基于总计数中的开放和非活动请求? - threadsafe确实已启用。

2 个答案:

答案 0 :(得分:3)

有两种方法可以解决这个问题(最重要的)。

使用任务队列!

如果工作不需要与请求同时完成,那么这正是App Engine中的[任务队列]所针对的。它们允许您将作业放在队列中,并让另一个模块接受工作。它们非常棒,因为您可以单独扩展前端和后端流程。

如果那不起作用......

使用App Engine灵活

引擎盖App Engine Flexible正在运行GCE实例。成本结构完全不同,因为您始终在后台运行为您的请求提供服务的VM。

希望这有帮助!

答案 1 :(得分:0)

您真正担心的是App Engine scales您的实例。由于您的许多请求只需要很少的资源,因此您的应用程序可能能够在单个实例上处理比正常情况更多的并发请求。您可以查看形状缩放here的参数。特别感兴趣的是:

  

max_concurrent_requests 自动扩展实例在调度程序生成新实例之前可以接受的并发请求数(默认值:8,最大值:80)。

这里存在一个危险,即实例可能会填满非长轮询请求并导致负担过重。为防止这种情况发生,您可以将长轮询请求隔离到自己的service中,并将其缩放参数与应用的其余部分分开设置。