如何加快批处理API的操作？

我已经在第三方贡献模块以及我自己的一些操作中遇到了这个问题。我对加快我/ contrib 批处理操作的各种方式感到好奇吗？

假设它们与节点配合使用（导入/更新等），并且我们正在处理10,000+范围内的节点列表的解析（尽管我必须处理1500万行。）-是的-我刚搞定。 ）

附加到drupals cron.php作业并运行“ headless”是否更快？使用Drush？还是这仅仅是我可以如何高效和快速地解析代码的问题，并且没有外界影响或批次特定的优化技巧……

目前，我遇到了一些操作（使用一些粗略的计算）可能需要24小时以上的时间...

谢谢！

这不适用于contrib代码，但是如果是您的代码并且您很了解，我建议编写drush命令来完成工作。在drush中，将drupal_bootstrap（）限制为适当的引导程序级别。我不记得实际的数字，但是每个drupal请求的时间中有很大一部分时间花在了引导程序上，您可以在那里节省很多时间。

此外，请检查迁移模块的内容。我不知道它是如何工作的（从来没有花时间来研究它），但是它可以非常快地穿越大量节点。

每个批处理调用都是一个HTTP请求。因此，您需要找到可以触发另一个HTTP请求之前可以处理的迭代次数的完美结合。需要考虑的两件事是内存和最大执行时间。您将希望每批处理尽可能多的迭代，以减少HTTP请求的数量，因为它们很可能是您的慢批处理的罪魁祸首。

如果您的批次太重而无法有效运行，则可以尝试使用队列。http://sf2010.drupal.org/conference/sessions/batch-vs-queue-api-smackdown上有一个很好的批处理与队列演示。队列不提供用户反馈，可以并行运行。

如果您需要用户反馈，则可以使用批处理，但您甚至可以在批处理中使用队列来尝试对其进行优化。

正如其他人所说，Drush是一个很好的解决方案，但是队列是一个很好的使用工具。Drupal 7中的Batch API使用内置的核心Queue API，因此，如果您使用的是MySQL，那么您的过程可能会遇到瓶颈。但是，Drupal 7的Queue API是可插入的，因此您可以使用另一个队列系统，例如beantalkd。

如果可以使其平行，那就是一个好的开始。这是我的一些想法，因为我之前使用4个线程（通过boost）抓取了超过一百万页。希望现在就将其推广。http://groups.drupal.org/node/126624