fork/django-q2
1
0
Fork 0
mirror of https://github.com/django-q2/django-q2.git synced 2026-10-09 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

fixing README some typos

Browse Source
This commit is contained in:
Ilan Steemers
2015-06-24 22:48:35 +02:00
parent 06791005c9
commit a44ad57b7a
2 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+8 -8
View File
@@ -4,14 +4,14 @@
### Status ### Status
In Alpha. In Alpha.
Everything should work, but the basic structure can still change. Everything should work, but the basic structure can still change.
Main focus is on creating more test, better coverage and stability. Main focus is on creating more tests, better coverage and stability.
### Architecture ### Architecture
![Django Q schema](http://i.imgur.com/wTIeg2T.png) ![Django Q schema](http://i.imgur.com/wTIeg2T.png)
### Usage ### Usage
Schedule the asynchronous exectution of a function by calling `async` from within your Django project. Schedule the asynchronous execution of a function by calling `async` from within your Django project.
```python ```python
async(func,*args,hook=None,**kwargs) async(func,*args,hook=None,**kwargs)
@@ -31,8 +31,8 @@ You can monitor basic information about all the connected clusters by running `
![qmonitor command](http://i.imgur.com/5cm7hdP.png) ![qmonitor command](http://i.imgur.com/5cm7hdP.png)
###Admin integration ###Admin integration
Django Q registers itself with the admin page to show failed and succesful tasks. Django Q registers itself with the admin page to show failed and successful tasks.
From there task results can be read or deleted. If neccesary, failed tasks can be reintroduced to the queue. From there task results can be read or deleted. If necessary, failed tasks can be reintroduced to the queue.
### Signed Tasks ### Signed Tasks
Tasks are first pickled to Json and then signed using Django's own signing module before being sent to a Redis list. This ensures that task packages on the Redis server can only be excuted and read by clusters and django servers who share the same secret key. Tasks are first pickled to Json and then signed using Django's own signing module before being sent to a Redis list. This ensures that task packages on the Redis server can only be excuted and read by clusters and django servers who share the same secret key.
@@ -40,18 +40,18 @@ Tasks are first pickled to Json and then signed using Django's own signing modul
Optionally, packages can be compressed before transport by setting `Q_COMPRESSED = True ` Optionally, packages can be compressed before transport by setting `Q_COMPRESSED = True `
### Pusher ### Pusher
The pusher process continously checks the Redis list for new task packages and pushes them on the Task Queue. The pusher process continuously checks the Redis list for new task packages and pushes them on the Task Queue.
### Worker ### Worker
A worker process checks the package signing, unpacks the task, executes it and saves the return value. Irrespective of the failure or success of any of these steps, the package is then pushed onto the Result Queue. A worker process checks the package signing, unpacks the task, executes it and saves the return value. Irrespective of the failure or success of any of these steps, the package is then pushed onto the Result Queue.
By default Django Q spawns a worker for each detected CPU on the host system. By default Django Q spawns a worker for each detected CPU on the host system.
This can be overridden by setting `Q_WORKERS = n`. With *n* being the numbe of desired worker processes. This can be overridden by setting `Q_WORKERS = n`. With *n* being the number of desired worker processes.
### Monitor ### Monitor
The result monitor checks the Result Queue for processed packages and saves both failed and succesful packages to the Django database. The result monitor checks the Result Queue for processed packages and saves both failed and successful packages to the Django database.
By default only the last 100 succesful packages are kept in the database. By default only the last 100 successful packages are kept in the database.
This can be increased or decreased at will by settings `Q_SAVE_LIMIT = n`. With *n* being the desired number of records. This can be increased or decreased at will by settings `Q_SAVE_LIMIT = n`. With *n* being the desired number of records.
Set `Q_SAVE_LIMIT = 0` to save all results to the database. Set `Q_SAVE_LIMIT = 0` to save all results to the database.
Failed packages are always saved. Failed packages are always saved.
README.rst
+13 -13
View File
@@ -4,12 +4,9 @@ Django Q
A multiprocessing task queue application for Django A multiprocessing task queue application for Django
--------------------------------------------------- ---------------------------------------------------
Status |image0| ### Status In Alpha. Everything should work, but the basic
~~~~~~ structure can still change. Main focus is on creating more tests, better
coverage and stability.
In Alpha and Python 3 only (for now). Everything should work, but the
basic structure can still change. Main focus will be put on creating
tests now.
Architecture Architecture
~~~~~~~~~~~~ ~~~~~~~~~~~~
@@ -21,7 +18,7 @@ Architecture
Usage Usage
~~~~~ ~~~~~
Schedule the asynchronous exectution of a function by calling ``async`` Schedule the asynchronous execution of a function by calling ``async``
from within your Django project. from within your Django project.
.. code:: python .. code:: python
@@ -57,8 +54,8 @@ Admin integration
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
Django Q registers itself with the admin page to show failed and Django Q registers itself with the admin page to show failed and
succesful tasks. From there task results can be read or deleted. If successful tasks. From there task results can be read or deleted. If
neccesary, failed tasks can be reintroduced to the queue. necessary, failed tasks can be reintroduced to the queue.
Signed Tasks Signed Tasks
~~~~~~~~~~~~ ~~~~~~~~~~~~
@@ -74,7 +71,7 @@ Optionally, packages can be compressed before transport by setting
Pusher Pusher
~~~~~~ ~~~~~~
The pusher process continously checks the Redis list for new task The pusher process continuously checks the Redis list for new task
packages and pushes them on the Task Queue. packages and pushes them on the Task Queue.
Worker Worker
@@ -86,15 +83,15 @@ any of these steps, the package is then pushed onto the Result Queue.
By default Django Q spawns a worker for each detected CPU on the host By default Django Q spawns a worker for each detected CPU on the host
system. This can be overridden by setting ``Q_WORKERS = n``. With *n* system. This can be overridden by setting ``Q_WORKERS = n``. With *n*
being the numbe of desired worker processes. being the number of desired worker processes.
Monitor Monitor
~~~~~~~ ~~~~~~~
The result monitor checks the Result Queue for processed packages and The result monitor checks the Result Queue for processed packages and
saves both failed and succesful packages to the Django database. saves both failed and successful packages to the Django database.
By default only the last 100 succesful packages are kept in the By default only the last 100 successful packages are kept in the
database. This can be increased or decreased at will by settings database. This can be increased or decreased at will by settings
``Q_SAVE_LIMIT = n``. With *n* being the desired number of records. Set ``Q_SAVE_LIMIT = n``. With *n* being the desired number of records. Set
``Q_SAVE_LIMIT = 0`` to save all results to the database. Failed ``Q_SAVE_LIMIT = 0`` to save all results to the database. Failed
@@ -119,3 +116,6 @@ Todo
~~~~ ~~~~
I'll add to this README while I'm developing the various parts. I'll add to this README while I'm developing the various parts.
.. |image0| image:: https://travis-ci.org/Koed00/django-q.svg?branch=master
:target: https://travis-ci.org/Koed00/django-q