我正在几个平台上尝试并发请求处理。
该实验的目的是对某些选定技术的容量范围进行广泛衡量。
我在我的机器上设置了一个Linux VM,其中包含一个基本的Go http服务器(http.HandleFunc
默认包的vanilla http
)。
然后,服务器将计算 fasta 算法的修改版本,该算法将线程和进程限制为1,并返回结果。 N设定为100000。
算法运行大约2秒钟。
我在Google App Engine项目中使用了相同的算法和逻辑。
算法是使用相同的代码编写的,只是处理程序设置是根据GAE要求在init()
上而不是main()
完成的。
另一方面,Android客户端正在产生500个线程,每个线程并行向{em> fasta 计算服务器发出GET
请求,请求超时为5000毫秒。
我期待GAE应用程序扩展并回复每个请求,并且本地Go服务器在500个请求中的某些请求失败但结果却相反: 本地服务器在超时范围内正确回复了每个请求,而GAE应用程序只能处理500个中的160个请求。其余请求超时。
我检查了云控制台,并确认已生成18个GAE实例,但绝大多数请求仍然失败。
我认为其中大部分因为每个GAE实例的启动时间而失败,所以我在之后重复了实验,但结果相同:大部分请求超时。
我期待GAE扩展以适应所有请求,相信如果一个本地VM可以成功回复500个并发请求,GAE会做同样的事情,但这不是发生的事情。
GAE控制台不显示任何错误,并正确报告传入请求的数量。
这可能是什么原因? 此外,如果单个实例只能通过goroutines处理我机器上的所有传入请求,那么GAE需要如何扩展这么多呢?
答案 0 :(得分:5)
要在最小化成本方面实现最佳使用,您需要在app.yaml
中配置一些内容:
threadsafe: true
- 实际上它来自Python config并且不适用于Go,但我会将其设置以防万一。max_concurrent_requests
- 设置为最高80 max_idle_instances
- 设置为最小0 max_pending_latency
- 将其设置为自动或大于min_pending_latency
min_idle_instances
- 将其设为0 min_pending_latency
- 设置为更高的数字。如果您可以获得1秒的延迟,并且您的处理程序平均需要100毫秒才能将其设置为900毫秒。然后你应该可以在单个实例上进行大量请求。
如果你可以为了回应而烧钱。 scalabiluty - 增加min_idle_instances
& max_idle_instances
。
您是否也为VM和GAE使用类似的实例类型? GAE F1实例不是太快,对于使用IO(数据存储区,http等)等异步任务更为理想。您可以配置更强大的实例的使用,以更好地扩展计算密集型任务。
您也在付费帐户上进行测试吗?免费帐户有配额,如果AppEngine认为如果连续使用相同的模式,那么负载会超过每日配额,AppEngine会拒绝请求的百分比。
答案 1 :(得分:4)
延伸亚历山大的答案。
GAE缩放逻辑基于传入流量趋势分析。
能够处理您的案例的关键 - 流量的突然高峰(由于其变化速度而在趋势分析中无法考虑) - 是为您的应用程序配置了足够的驻留(空闲)实例处理此类流量,直到GAE旋转其他动态实例。它可以处理你想要的高峰(如果你的口袋足够深)。
有关详细信息,请参阅Scaling dynamic instances。
答案 2 :(得分:2)
感谢大家的帮助。 我对这个主题的答案已经提出了许多有趣的观点和见解。
云控制台报告没有错误的事实使我相信在实际请求处理之后发生了瓶颈。
我找到了结果不符合预期的原因:带宽。
每个响应的有效负载大约为1MB,因此响应来自同一客户端的500个同时连接会阻塞线路,从而导致超时。 当请求到VM时,这显然没有发生,其中带宽要大得多。
现在GAE扩展符合我的预期:它成功扩展以适应每个传入的请求。