大约在 2011 年 3 月，我测试了 GAE(Java 版本)作为大规模并行计算的潜在平台。这个日期很重要，因为 GAE 一直在发展。我发现该应用程序在大约 43.2 倍的计算吞吐量下受到有效限制。 有没有人成功地将 GAE 用于大规模并行计算或获得了更高的计算增益？为了这个问题的目的，我将任意定义大规模并行计算意味着大于 1000 倍的计算吞吐量。
我使用了一个桌面客户端，它实例化了多个线程来访问 URL。我正在使用 GAE 任务队列。该应用程序需要非常少的输入并产生非常少的输出，无论是 Datastore 还是 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 秒，只是为了留出安全边际。有些任务什么都不做的情况是为了降低每个任务必须完成的平均工作量，以影响整个谷歌“会计”。因此，例如 2000 个任务，每个任务有 0.8 秒的工作时间，但另外 222 个任务没有工作，这意味着 10% 没有工作。
编辑:@PeterRecore，我正在测量吞吐量增益，它是 totalWorkInSeconds 除以 elapsedTimeInSeconds，这是在客户端测量的。客户端发出请求并测量耗时，直到所有 GAE 任务完成，每个任务都发送一个非常小的响应来指示。我试图找出当前形式的 GAE 是否可用于创建实现高吞吐量增益值的应用程序。在 2011 年 3 月，这似乎不太可能。今天怎么样？它将如何完成或您实际上是如何完成的？达到了什么样的吞吐量增益水平？正如我所说，Datastore 的使用是最少的，并且包括每个任务在完成任务时编写一个简单的小对象。每个任务循环到一个与 secondsOfWorkPerTask 成正比的整数。 GAE 旋转实例是问题的一部分。谷歌通过告诉人们他们更喜欢亚秒级任务来加剧这个问题。如果我有大型任务，问题就会得到缓解，因为这样实例化所用的周期数所占的百分比就较小。
最佳答案
App Engine 并不是为用作大型计算作业的后端而设计的——它是为可扩展站点(和 API，就此而言)的快速高效服务而设计的。它所做的并没有围绕您要实现的目标进行优化。
关于java - Google App Engine 可以用于大规模并行计算吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8105564/