The Drupal 7 documentation introduces the Batch API as:

Functions allowing forms processing to be spread out over several page requests, thus ensuring that the processing does not get interrupted because of a PHP timeout...

I took this to mean that Batch handles the timeout-related issues for the developer.

However, other posts (ie. How does the batch API work internally?) imply that it is the developer's responsibility to tell Batch how much work to do before waiting for another user to arrive and Batch to be invoked again --- thereby avoiding the timeout.

If the latter is true then I assume Batch does not guarantee that jobs won't be timed out. Does Batch provide any guarantees? Is it up to the developer to guess how much Batch can process before timing out?

Thank you!

  • 3
    This is a pretty damn good question, thank you :-)
    – Chapabu
    Commented Apr 17, 2013 at 19:55

2 Answers 2


Batch simply says "I will do N number of things (at most) and then do a page refresh ... and do more."

If you say do 5 items per job chunk that take 5 seconds each you would be fine with the default php timeout value of 30 seconds.

If you say do 20 items per job chunk that take 5 seconds each, your workload per request is too high and will likely timeout.

Remember when your in PHP the lifecycle of a page is request in -> response out. And that your webserver keeps each thread alive for a finite amount of time. You have to work around that timeout -- which the Batch API helps you do.

Running stuff from say Drush, server side using community modules such as Migrate can help you completely avoid timeouts if need be.


Also bear in mind that every page request is a full drupal bootstrap and Batch API picks off where it left off. That is one of the most expensive operations when using the Batch API, reloading drupal every N items. That's why people have been working on server side techniques to create nodes, import content, etc. Batch API is great for simple, repetitive tasks. But it tends to fall apart in either complex, or very very large datasets.

  • 1
    Are you saying that Batch is invoked on every page load; ie. Batch wakes up to see if there are any tasks (like poorman's cron)? This was suspected; however, I don't understand why you emphasized the computational cost of the process. Isn't the additional cost just a few compares and whatever work Batch has in it's queue or is Batch doing something special like calling itself by loading a page?
    – Toaster
    Commented Apr 17, 2013 at 20:58
  • 1
    see kiamlaluno answer below. A batch progress bar page simply re-loads itself after X seconds. If you load up Firebug or Chrome in the Network tab and run a Batch API job, look at the URLs and you'll simply see the same page called with different item offsets and chunk sizes. The computation cost of bootstrapping all of drupal every single page request is HIGH. Running a Drush sql import loads drupal only once, for example. For large datasets and problems the Batch API overhead becomes too high.
    – tenken
    Commented Apr 17, 2013 at 22:52

The batch API simply registers _batch_shutdown() as shutdown function with register_shutdown_function(). That function just saves in a database table the current state of the batch being executed.
The Batch API doesn't provide any guarantee that the operation you are executing is not interrupted in the middle. That is why batch operations normally execute simple operations like reading a database row from saving a table, and saving a database row in another table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.