Are there any major advantages of triggering Drupal's cron tasks via Drush rather than via a curl call to the site? The main thing I can think of is that no web server process would be needed, when using drush. Are there other benefits?
Thanks!
Add a comment
|
1 Answer
Advantages is a loaded term, but I'll describe the differences.
If you compare https://github.com/drush-ops/drush/blob/master/commands/core/core.drush.inc#L647 with http://cgit.drupalcode.org/drupal/tree/cron.php?h=7.x, you'll notice that they both ultimately execute drupal_cron_run(). The only difference at the code level is what happens before that.
cron.php checks that a cron_key is passed in the query string and that maintenance_mode is not on. It also logs to watchdog.
Drush doesn't check either of those things and uses drush_log which is very different than watchdog (see Where are logs created by drush_log() stored?).
Finally, wget uses the service configured to handle http requests (most likely Apache or Nginx) even when configured to request cron.php through localhost. Drush is PHP running in Bash which executes the Drupal functions like drupal_cron_run() directly.
There are several reason you may or may not want to trigger cron through an http service, but here is one use case that might help illustrate a big difference. Let say you have a Drupal site that is moving to a new server and domain and you configure a redirect at the .htaccess level to send all http requests for olddomain.com to the new site at newdomain.com. Requests to execute cron using wget in a crontab would also be redirected, but calls to drush would continue to run cron. If the wget requests being redirected to the new site used the old cron_key, you would begin seeing errors about that in your logs.
Someone could make the case that the memory and CPU footprint of the Drush request is smaller, but that should be very trivial compared to what happens in drupal_cron_run().
I don't think one is necessarily better than the other, but they are different.
