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