我正在几个平台上尝试并发请求处理。
实验的目的是对某些选定技术的能力范围进行 广泛的 测量。
我成立了一个Linux VM我的机器上有一个基本的围棋http服务器(香草http.HandleFunc中的http默认包)。然后,服务器将计算 fasta 算法的修改版本,该版本将线程和进程限制为1,并返回结果。N设置为100000。该算法运行大约2秒钟。我在Google App Engine项目上使用了 相同的 算法和逻辑。
http.HandleFunc
http
该算法使用相同的代码编写,只是完成了处理程序设置,init()而不是main()按照GAE要求进行。
init()
main()
在另一端,Android客户端产生了500个线程,每个线程并行GET向 fasta 计算服务器发出请求,请求超时为5000毫秒。
GET
我期望GAE应用程序能够扩展并响应每个请求,而本地Go服务器在500个请求中失败,但是结果却相反:本地服务器正确地在超时范围内答复了每个请求,而GAE应用程序却是只能处理600个请求中的160个。其余请求超时。
我检查了Cloud Console,并确认产生了18个GAE实例,但绝大多数请求仍然失败。
我以为他们中的大多数人都因为每个GAE实例的启动时间而失败了,所以我之后立即重复了实验,但结果却是相同的:大多数请求都超时了。
我期望GAE能够扩展以适应所有请求,并相信如果单个本地VM可以成功回复500个并发请求,GAE也会这样做,但是事实并非如此。
GAE控制台未显示任何错误,并正确报告了传入请求的数量。
这可能是什么原因? 此外,如果单个实例仅可以通过goroutine来处理我计算机上的所有传入请求,那么GAE为何需要这么大扩展?
感谢大家的帮助。我对此主题的回答已经提出了许多有趣的观点和见解。
Cloud Console没有报告错误的事实使我相信瓶颈是在实际请求处理之后发生的。
我发现了结果不如预期的原因:带宽。
每个响应的有效负载大约为1MB,因此响应来自同一客户端的500个同时连接会阻塞线路,从而导致超时。向带宽大得多的VM请求时,显然没有发生这种情况。
现在,GAE缩放比例符合我的预期:它可以成功缩放以适应每个传入的请求。