私は、サードパーティのcontribモジュールと自分の操作の両方でこれに遭遇しました。バッチ操作を高速化するさまざまな方法に興味がありますか？
それらがノード（インポート/更新など）で動作し、10,000以上の範囲のノードのリストを解析していると仮定します（ただし、1500万行を処理する必要がありました。 ）
drupals cron.phpジョブにアタッチして「ヘッドレス」を実行する方が速いですか？Drushを使用していますか？または、これは単にコードを開発できる効率的かつ迅速な解析の問題であり、外部の影響やバッチ固有の最適化のヒントはありません ...
現在、私は（多少の大まかな計算を使用して）24時間以上かかる可能性のある操作に遭遇しました...
ありがとう！
回答:
これはcontribコードでは機能しませんが、それがあなたのコードであり、あなたがそれをよく知っているなら、仕事をするためにdrushコマンドを書くことをお勧めします。drush内で、drupal_bootstrap（）を適切なブートストラップレベルに制限します。実際の数値を思い出すことはできませんが、すべてのdrupalリクエストの時間の非常に大きな割合がブートストラップに費やされており、そこで多くの時間を節約できます。
さらに、Migrateモジュールの基本を確認してください。私はそれがどのようにモジョであるのかわかりません（それを手探りするのに時間をかけませんでした）が、それはノードの巨大なバッチを非常に素早く燃やすことができます。
すべてのバッチ呼び出しはHTTPリクエストです。そのため、別のHTTP要求が起動されるまでに処理できる反復の数の完璧なブレンドを見つける必要があります。考慮すべき2つのことは、メモリと最大実行時間です。HTTPリクエストの数を減らすため、バッチごとに可能な限り多くの反復を処理する必要があります。これは、スローバッチの原因である可能性が高いためです。
バッチが重すぎて効率的に実行できない場合は、代わりにキューを使用してみてください。http://sf2010.drupal.org/conference/sessions/batch-vs-queue-api-smackdownには、バッチとキューのプレゼンテーションがあります。キューはユーザーからのフィードバックを提供せず、並行して実行できます。
ユーザーのフィードバックが必要な場合は、バッチに関連付けられていますが、バッチでキューを使用して最適化を試みることもできます。
それを並行させることができれば、それは良いスタートです。これまでに、4つのスレッドを使用して100万ページ以上をクロールする（ブースト経由）ので、これについての私の考えをいくつか示します。今それを一般化しようとしています。http://groups.drupal.org/node/126624