README.rst

celery - Distributed Task Queue for Django.

Introduction

It is used for executing tasks asynchronously, routed to one or more
worker servers, running concurrently using multiprocessing.

It is designed to solve certain problems related to running websites
demanding high-availability and performance.

It is perfect for filling caches, posting updates to twitter, mass
downloading data like syndication feeds or web scraping. Use-cases are
plentiful. Implementing these features asynchronously using celery is
easy and fun, and the performance improvements can make it more than
worthwhile.

Features

You can run as many worker servers as you want, and still
be guaranteed that the task is only executed once.

Tasks are executed concurrently using the Python 2.6
multiprocessing module (also available as a backport
to older python versions)

Supports periodic tasks, which makes it a (better) replacement
for cronjobs.

When a task has been executed, the return value is stored using either
a MySQL/Oracle/PostgreSQL/SQLite database, memcached,
or Tokyo Tyrant backend.

If the task raises an exception, the exception instance is stored,
instead of the return value.

All tasks has a Universaly Unique Identifier (UUID), which is the
task id, used for querying task status and return values.

Supports tasksets, which is a task consisting of several subtasks.
You can find out how many, or if all of the subtasks has been executed.
Excellent for progress-bar like functionality.

Has a map like function that uses tasks, called dmap.

However, you rarely want to wait for these results in a web-environment.
You'd rather want to use Ajax to poll the task status, which is
available from a URL like celery/<task_id>/status/. This view
returns a JSON-serialized data structure containing the task status,
and the return value if completed, or exception on failure.