用TaskQueues突发处理能力？

我有一种情况，我想对数据存储做1000个不同的查询，对每个查询的结果做一些计算（得到1000个单独的结果），并返回结果列表。用TaskQueues突发处理能力？

我希望返回结果列表作为来自开始计算的相同30秒用户请求的响应，以获得更好的客户端性能。哈！

我有一个大胆的计划。

这些操作中的每一个单独通常都不会在一秒钟内完成问题，它们都不需要写入任何其他实体组，也不需要任何其他查询的任何信息。可能有可能启动1000个独立任务，每个任务都会接受其中一个查询，进行计算，并将结果存储在某种临时实体集合中？原始请求可能会等待10秒，然后对数据存储的结果执行单个查询（也许它们都设置了我可以查询的唯一值）。任何尚未结束的结果都会在客户端被注意到，客户可能会在十秒内再次请求这些值。

我希望有经验的appengineers能够回答的问题是：

这是可笑的？如果是这样，任何数量的任务都很可笑吗？ 50会立即合理吗？
我不会碰到数据存储争用，如果我是读同一个实体每秒20次，对吗？争用的东西全是为了写作？
有没有更简单的方法从任务获得响应？

来源

2011-04-05 Riley Lark

没错，听起来很可笑:)

你不应该依靠TASKQUEUE到这样的操作。你不能依靠1000个被迅速产生的任务（尽管他们很可能会这样做）。

为什么不使用Channel API来等待您的响应。所以，你的解决方案变为：

客户端使用令牌发送请求到服务器
服务器会生成N个任务做你的计算和响应客户与渠道的API令牌
客户端监听信道
一旦所有的任务完成服务器推动通过通道

响应客户这将避免会不时因任务很可能arrise不执行任何超时问题快速如你所愿，或其他原因。

来源

2011-04-05 17:00:14

感谢您的想法。为了简单起见，我可能会让客户每隔10秒钟检查一次，或者其他事情。对于你说的N，在原始请求返回之前尝试收集响应是合理的？ – 2011-04-05 17:34:32

如果对从数据存储中读取的每个值的*计算*将花费不到一秒的时间，那么1000个任务不会使其快1000倍，因为 – 2011-04-05 18:09:39

对不起？并行完成的1000个查询和计算不会比按顺序执行的查询快1000倍？ – 2011-04-05 18:26:51

任务队列不会提供任务何时执行的坚定保证 - ETA（默认为当前时间）是最早执行的时间，但如果队列已备份，或者没有可用于执行任务的实例，它可能会在稍后执行。

一个选项是使用Datastore Plus/NDB，它允许您并行执行查询。 1000个查询将会非常昂贵，不过，无论你如何执行它们。

@Chris建议的另一种选择是将任务队列与Channel API一起使用，以便在查询完成时异步通知用户。

来源

2011-04-06 01:31:24

Datastore Plus看起来很有趣，但我正在使用Java。这听起来像是任务队列是我完成工作的最佳选择，我不应该指望它在30秒内完成。我会考虑如何处理部分/最终结果。感谢您的建议！ – 2011-04-06 14:42:32

用TaskQueues突发处理能力？

回答

相关问题