| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316 | 
							- .. _intro:
 
- ========================
 
-  Introduction to Celery
 
- ========================
 
- .. contents::
 
-     :local:
 
-     :depth: 1
 
- What is a Task Queue?
 
- =====================
 
- Task queues are used as a mechanism to distribute work across threads or
 
- machines.
 
- A task queue's input is a unit of work called a task. Dedicated worker
 
- processes constantly monitor task queues for new work to perform.
 
- Celery communicates via messages, usually using a broker
 
- to mediate between clients and workers.  To initiate a task, a client adds a
 
- message to the queue, which the broker then delivers to a worker.
 
- A Celery system can consist of multiple workers and brokers, giving way
 
- to high availability and horizontal scaling.
 
- Celery is written in Python, but the protocol can be implemented in any
 
- language.  So far there's RCelery_ for the Ruby programming language,
 
- node-celery_ for Node.js and a `PHP client`_. Language interoperability can also be achieved
 
- by :ref:`using webhooks <guide-webhooks>`.
 
- .. _RCelery: http://leapfrogdevelopment.github.com/rcelery/
 
- .. _`PHP client`: https://github.com/gjedeer/celery-php
 
- .. _node-celery: https://github.com/mher/node-celery
 
- What do I need?
 
- ===============
 
- .. sidebar:: Version Requirements
 
-     :subtitle: Celery version 3.0 runs on
 
-     - Python ❨2.5, 2.6, 2.7, 3.2, 3.3❩
 
-     - PyPy ❨1.8, 1.9❩
 
-     - Jython ❨2.5, 2.7❩.
 
-     This is the last version to support Python 2.5,
 
-     and from the next version Python 2.6 or newer is required.
 
-     The last version to support Python 2.4 was Celery series 2.2.
 
- *Celery* requires a message transport to send and receive messages.
 
- The RabbitMQ and Redis broker transports are feature complete,
 
- but there's also support for a myriad of other experimental solutions, including
 
- using SQLite for local development.
 
- *Celery* can run on a single machine, on multiple machines, or even
 
- across data centers.
 
- Get Started
 
- ===========
 
- If this is the first time you're trying to use Celery, or you are
 
- new to Celery 3.0 coming from previous versions then you should read our
 
- getting started tutorials:
 
- - :ref:`first-steps`
 
- - :ref:`next-steps`
 
- Celery is…
 
- ==========
 
- .. _`mailing-list`: http://groups.google.com/group/celery-users
 
- .. topic:: \ 
 
-     - **Simple**
 
-         Celery is easy to use and maintain, and it *doesn't need configuration files*.
 
-         It has an active, friendly community you can talk to for support,
 
-         including a `mailing-list`_ and an :ref:`IRC channel <irc-channel>`.
 
-         Here's one of the simplest applications you can make:
 
-         .. code-block:: python
 
-             from celery import Celery
 
-             app = Celery('hello', broker='amqp://guest@localhost//')
 
-             @app.task
 
-             def hello():
 
-                 return 'hello world'
 
-     - **Highly Available**
 
-         Workers and clients will automatically retry in the event
 
-         of connection loss or failure, and some brokers support
 
-         HA in way of *Master/Master* or *Master/Slave* replication.
 
-     - **Fast**
 
-         A single Celery process can process millions of tasks a minute,
 
-         with sub-millisecond round-trip latency (using RabbitMQ,
 
-         py-librabbitmq, and optimized settings).
 
-     - **Flexible**
 
-         Almost every part of *Celery* can be extended or used on its own,
 
-         Custom pool implementations, serializers, compression schemes, logging,
 
-         schedulers, consumers, producers, autoscalers, broker transports and much more.
 
- .. topic:: It supports
 
-     .. hlist::
 
-         :columns: 2
 
-         - **Brokers**
 
-             - :ref:`RabbitMQ <broker-rabbitmq>`, :ref:`Redis <broker-redis>`,
 
-             - :ref:`MongoDB <broker-mongodb>` (exp), ZeroMQ (exp)
 
-             - :ref:`CouchDB <broker-couchdb>` (exp), :ref:`SQLAlchemy <broker-sqlalchemy>` (exp)
 
-             - :ref:`Django ORM <broker-django>` (exp), :ref:`Amazon SQS <broker-sqs>`, (exp)
 
-             - and more…
 
-         - **Concurrency**
 
-             - prefork (multiprocessing),
 
-             - Eventlet_, gevent_
 
-             - threads/single threaded
 
-         - **Result Stores**
 
-             - AMQP, Redis
 
-             - memcached, MongoDB
 
-             - SQLAlchemy, Django ORM
 
-             - Apache Cassandra
 
-         - **Serialization**
 
-             - *pickle*, *json*, *yaml*, *msgpack*.
 
-             - *zlib*, *bzip2* compression.
 
-             - Cryptographic message signing.
 
- Features
 
- ========
 
- .. topic:: \ 
 
-     .. hlist::
 
-         :columns: 2
 
-         - **Monitoring**
 
-             A stream of monitoring events is emitted by workers and
 
-             is used by built-in and external tools to tell you what
 
-             your cluster is doing -- in real-time.
 
-             :ref:`Read more… <guide-monitoring>`.
 
-         - **Workflows**
 
-             Simple and complex workflows can be composed using
 
-             a set of powerful primitives we call the "canvas",
 
-             including grouping, chaining, chunking and more.
 
-             :ref:`Read more… <guide-canvas>`.
 
-         - **Time & Rate Limits**
 
-             You can control how many tasks can be executed per second/minute/hour,
 
-             or how long a task can be allowed to run, and this can be set as
 
-             a default, for a specific worker or individually for each task type.
 
-             :ref:`Read more… <worker-time-limits>`.
 
-         - **Scheduling**
 
-             You can specify the time to run a task in seconds or a
 
-             :class:`~datetime.datetime`, or or you can use
 
-             periodic tasks for recurring events based on a
 
-             simple interval, or crontab expressions
 
-             supporting minute, hour, day of week, day of month, and
 
-             month of year.
 
-             :ref:`Read more… <guide-beat>`.
 
-         - **Autoreloading**
 
-             In development workers can be configured to automatically reload source
 
-             code as it changes, including :manpage:`inotify(7)` support on Linux.
 
-             :ref:`Read more… <worker-autoreloading>`.
 
-         - **Autoscaling**
 
-             Dynamically resizing the worker pool depending on load,
 
-             or custom metrics specified by the user, used to limit
 
-             memory usage in shared hosting/cloud environments or to
 
-             enforce a given quality of service.
 
-             :ref:`Read more… <worker-autoscaling>`.
 
-         - **Resource Leak Protection**
 
-             The :option:`--maxtasksperchild` option is used for user tasks
 
-             leaking resources, like memory or file descriptors, that
 
-             are simply out of your control.
 
-             :ref:`Read more… <worker-maxtasksperchild>`.
 
-         - **User Components**
 
-             Each worker component can be customized, and additional components
 
-             can be defined by the user.  The worker is built up using "bootsteps" — a
 
-             dependency graph enabling fine grained control of the worker's
 
-             internals.
 
- .. _`Eventlet`: http://eventlet.net/
 
- .. _`gevent`: http://gevent.org/
 
- Framework Integration
 
- =====================
 
- Celery is easy to integrate with web frameworks, some of which even have
 
- integration packages:
 
-     +--------------------+------------------------+
 
-     | `Django`_          | `django-celery`_       |
 
-     +--------------------+------------------------+
 
-     | `Pyramid`_         | `pyramid_celery`_      |
 
-     +--------------------+------------------------+
 
-     | `Pylons`_          | `celery-pylons`_       |
 
-     +--------------------+------------------------+
 
-     | `Flask`_           | not needed             |
 
-     +--------------------+------------------------+
 
-     | `web2py`_          | `web2py-celery`_       |
 
-     +--------------------+------------------------+
 
-     | `Tornado`_         | `tornado-celery`_      |
 
-     +--------------------+------------------------+
 
- The integration packages are not strictly necessary, but they can make
 
- development easier, and sometimes they add important hooks like closing
 
- database connections at :manpage:`fork(2)`.
 
- .. _`Django`: http://djangoproject.com/
 
- .. _`Pylons`: http://pylonshq.com/
 
- .. _`Flask`: http://flask.pocoo.org/
 
- .. _`web2py`: http://web2py.com/
 
- .. _`Bottle`: http://bottlepy.org/
 
- .. _`Pyramid`: http://docs.pylonsproject.org/en/latest/docs/pyramid.html
 
- .. _`pyramid_celery`: http://pypi.python.org/pypi/pyramid_celery/
 
- .. _`django-celery`: http://pypi.python.org/pypi/django-celery
 
- .. _`celery-pylons`: http://pypi.python.org/pypi/celery-pylons
 
- .. _`web2py-celery`: http://code.google.com/p/web2py-celery/
 
- .. _`Tornado`: http://www.tornadoweb.org/
 
- .. _`tornado-celery`: http://github.com/mher/tornado-celery/
 
- Quickjump
 
- =========
 
- .. topic:: I want to ⟶
 
-     .. hlist::
 
-         :columns: 2
 
-         - :ref:`get the return value of a task <task-states>`
 
-         - :ref:`use logging from my task <task-logging>`
 
-         - :ref:`learn about best practices <task-best-practices>`
 
-         - :ref:`create a custom task base class <task-custom-classes>`
 
-         - :ref:`add a callback to a group of tasks <canvas-chord>`
 
-         - :ref:`split a task into several chunks <canvas-chunks>`
 
-         - :ref:`optimize the worker <guide-optimizing>`
 
-         - :ref:`see a list of built-in task states <task-builtin-states>`
 
-         - :ref:`create custom task states <custom-states>`
 
-         - :ref:`set a custom task name <task-names>`
 
-         - :ref:`track when a task starts <task-track-started>`
 
-         - :ref:`retry a task when it fails <task-retry>`
 
-         - :ref:`get the id of the current task <task-request-info>`
 
-         - :ref:`know what queue a task was delivered to <task-request-info>`
 
-         - :ref:`see a list of running workers <monitoring-control>`
 
-         - :ref:`purge all messages <monitoring-control>`
 
-         - :ref:`inspect what the workers are doing <monitoring-control>`
 
-         - :ref:`see what tasks a worker has registered <monitoring-control>`
 
-         - :ref:`migrate tasks to a new broker <monitoring-control>`
 
-         - :ref:`see a list of event message types <event-reference>`
 
-         - :ref:`contribute to Celery <contributing>`
 
-         - :ref:`learn about available configuration settings <configuration>`
 
-         - :ref:`receive email when a task fails <conf-error-mails>`
 
-         - :ref:`get a list of people and companies using Celery <res-using-celery>`
 
-         - :ref:`write my own remote control command <worker-custom-control-commands>`
 
-         - :ref:`change worker queues at runtime <worker-queues>`
 
- .. topic:: Jump to ⟶
 
-     .. hlist::
 
-         :columns: 4
 
-         - :ref:`Brokers <brokers>`
 
-         - :ref:`Applications <guide-app>`
 
-         - :ref:`Tasks <guide-tasks>`
 
-         - :ref:`Calling <guide-calling>`
 
-         - :ref:`Workers <guide-workers>`
 
-         - :ref:`Daemonizing <daemonizing>`
 
-         - :ref:`Monitoring <guide-monitoring>`
 
-         - :ref:`Optimizing <guide-optimizing>`
 
-         - :ref:`Security <guide-security>`
 
-         - :ref:`Routing <guide-routing>`
 
-         - :ref:`Configuration <configuration>`
 
-         - :ref:`Django <django>`
 
-         - :ref:`Contributing <contributing>`
 
-         - :ref:`Signals <signals>`
 
-         - :ref:`FAQ <faq>`
 
-         - :ref:`API Reference <apiref>`
 
- .. include:: ../includes/installation.txt
 
 
  |