Open topic with navigation
Helix Swarm uses background processes, called workers, to respond to events in the Helix server. The default number of workers is 3, and each worker processes events for up to 10 minutes. When a worker terminates, a new one is spawned.
Each worker maintains a connection to the Helix server for the duration of its lifetime. This may impact your Helix server management practices.
To determine the current status of workers, visit the URL:
The response is formatted in JSON, and looks like this:
During normal use of Swarm, the following error message appears for logged-in users when Swarm detects that no workers are running:
To adjust the configuration for workers, add a configuration block to the
// this block should be a peer of 'p4'
'queue' => array(
'workers' => 3, // defaults to 3
'worker_lifetime' => 595, // defaults to 10 minutes (less 5 seconds)
'worker_task_timeout' => 1800, // defaults to 30 minutes
'worker_memory_limit' => '1G', // defaults to 1 gigabyte
workersspecifies the number of worker processes that should be available. The default is 3. The cron job ensures that new worker processes are started when necessary. If the limit is reached or exceeded, new worker processes are not started.
worker_lifetimespecifies the amount of time in seconds that a worker process should run for. The default is 595 seconds (10 minutes less 5 seconds). If a worker process exceeds this limit while processing a task, it will complete the active task and then terminate.
worker_lifetimedoes not cause tasks to terminate mid-processing.
worker_task_timeoutspecifies the maximum amount of time in seconds that a worker process can spend processing a single task. The default is 1800 seconds (30 minutes). This is useful for terminating workers that might get stalled in a variety of situations.
worker_memory_limitspecifies the maximum amount of memory that a worker process is allowed to use while processing a task. The default is 1G (1 gigabyte).
To kick off a new worker process, visit the URL:
When the number of workers running matches the configured limit, the requested worker process is not started.
This technique does start a worker, but it lasts only for its configured lifetime. Typically, you would always want at least one worker running. See Set up a recurring task to spawn workers for details.
To restart an idle worker process, remove its lock file:
A worker process that is busy processing a task will continue operation until its task is complete. Immediately afterwards, if the worker notices that its lock file is missing it exits.
If you have a recurring task to start workers, the recurring task starts a fresh worker, if necessary. See Set up a recurring task to spawn workers for details.