When running Drupal on multiple servers, it can be useful to offload the cron processing to all or some servers.
If using the wget method for launching cron, this can be done on all servers which will then serve as redundant launchers. You can settle for launching cron on one server, but then you have a single point of failure.

Service groups

A service group is a collection of service hosts and a method for distributing load to these hosts. The default distribution algorithm is to choose a random host. An alternative method for distributing load is implemented in the Background Process Apache Server Status as a proof-of-concept. This method sends the job to the web server with the most idle connections.

Examples

Assuming example.com as the host name, and that the following servers are present in the setup:

Server #1: 192.168.1.2
Server #2: 192.168.1.3
Server #3: 192.168.1.4
Server #4: 192.168.1.5

Service host configuration

To configure the above service hosts, the following is add to settings.php:

<?php
$conf['background_process_service_hosts'] = array(
'server_1' => array(
'base_url' => 'http://192.168.1.2',
'http_host' => 'example.com',
),
'server_2' => array(
'base_url' => 'http://192.168.1.3',
'http_host' => 'example.com',
),
'server_3' => array(

Q: My web site is slow or unresponsive
A: Ultimate Cron launches jobs in parallel through an HTTP request (unless using Drush). If a lot jobs are scheduled to run, ensure that the "Simultaneous connections" setting is lower than the MaxClient of your web server.

Q: Jobs are stuck in "Starting" state.
A: If the Drupal site is not reachable at $base_url from the web server, Background Process can fail in launching requests, especially if migrating db's from one environment to another. One solution can be to click the "Determine default service host" button on the Background Process settings page. Another solution could be to manually configure the service hosts in the settings file. See Background Process for more.
A: The web server accepts the connection but never actually executes it. This a somewhat theoretical problem that hasn't been confirmed yet, but seem to have happened to some people, especially when using SSL.
A: This will happen with the combination Drupal 6, clean urls and nginx. This has been fixed in the dev version

Q: Jobs are running but never finishes.
A: It can happen from time to time that a job dies without Ultimate Cron being able to catch this. There are two known reasons for this.

It is recommended to disable Ultimate Cron's poorman's cron function, and instead setup the crontab on the server to run each minute, e.g.:

* * * * * wget -O - -q -t 1 http://www.example.com/cron.php

Ultimate Cron will launch each Drupal cron handler at it's configured time. By default, all queues run each minute, and all regular jobs run every 10 minutes, with a slight offset to each other. The default rule can be configured on the Ultimate Cron settings page.

Ultimate Cron is installed just like any other module. After installing, Ultimate Cron will take over cron operations and begin to run cron jobs in a parallel order.

Ultimate Cron require the following modules:

• Background Process
• Progress

Ultimate Cron has optionally support for:

Ultimate Cron is an extention of Drupal's cron system, allowing you to individually control each cron job.

The module sf_import (bundled with salesforce) exposes a cron hook to import from SFDC and facilitate bidrectional sync on a cron schedule. This is not the same as realtime sync which could be handled outside of cron using sf_notifications to expose an endpoint to be accessed directly by Salesforce update messages according to workflow rules there.