在大约2011年3月，我测试了GAE（Java版本）作为大规模并行计算的潜在平台。该日期是相关的，因为GAE一直在发展。我发现该应用程序有效地受到约43.2X计算吞吐量的限制。 有没有人成功地使用GAE进行大规模并行计算或获得了更高的计算增益？为了这个问题的目的，我将任意定义大规模并行计算，意味着大于1000倍的计算吞吐量。
我使用了一个实例化多个线程的桌面客户端来点击URL。我正在使用GAE任务队列。该应用程序只需很少的输入并产生非常少的输出，无论是数据存储还是HTML，因为它旨在评估计算吞吐量。
由于经常建议将GAE任务保持在1秒以内（虽然目前尚不清楚此建议是否适用于任务队列任务）但我尝试了各种排列。我的一些结果包含在这里。正如您所看到的，即使是0.8秒的任务，与低于1秒的建议一致，吞吐量也达到了43.2倍。
Elapsed Tasks SecondsOf Total Gain
Seconds Requested WorkPerTask Work
FLT (FEW LARGE TASKS)
15 72 1 72 4.9
103 72 20 1440 14.0
1524 72 400 28800 18.9
MST (MANY SMALL TASKS)
53 1000 0.8 800 15.1
63 2000 0.8 1600 25.4
127 4000 0.8 3200 25.2
313 4000 0.8 3200 10.2
258 8000 0.8 6400 24.8
177 8000 0.8 6400 36.2 (Have 5% of tasks do nothing.)
49 2000 0.8 1600 32.7 (Have 1% of tasks do nothing.)
37 2000 0.8 1600 43.2 (Have 5% of tasks do nothing.)
42 2000 0.8 1600 38.1 (Have 10% of tasks do nothing.)
249 2000 0.8 1600 6.4 (Have 50% of tasks do nothing.)
MLT (MANY LARGE TASKS)
6373 1000 200 200000 31.4
380 200 60 12000 31.6
请注意，任务队列任务超过600秒是不可取的，所以我去的最高时间是400秒，只是为了留下安全边际。某些任务无效的情况是降低每项任务必须完成的平均工作量，以影响整体Google“会计”。所以每个，比如2000个任务，都有0.8秒的工作，但额外的222个任务没有工作，这意味着10％没有工作。
编辑：@PeterRecore，我正在测量吞吐量增益，它是totalWorkInSeconds除以elapsedTimeInSeconds，这是在客户端测量的。客户端发出请求并测量所有GAE任务完成所经过的时间，每个GAE任务都发送一个非常小的响应。我试图找出当前形式的GAE是否可用于创建实现高吞吐量增益值的应用程序。 2011年3月似乎不太可能。今天怎么样？怎么做呢或你是怎么做到的？达到了什么级别的吞吐量增益？正如我所说的那样，数据存储的使用是最小的，包括每个任务在完成任务时编写一个简单的小对象。每个任务循环到与secondsOfWorkPerTask成比例的整数。 GAE旋转实例是问题的一部分。谷歌通过告诉人们他们更喜欢亚秒级任务来改变这个问题。如果我有大型任务，问题会得到缓解，因为那时实例化占所用周期数的百分比较小。
答案 0 :(得分：1)
App Engine实际上并非设计用作大型计算任务的后端 - 它专为快速有效地提供可扩展站点（以及API）而设计。它所做的并没有围绕你想要达到的目标进行优化。