django/daphne
1
1
Fork 0
mirror of https://github.com/django/daphne.git synced 2025-07-14 18:02:17 +03:00
Code Issues Packages Projects Releases Wiki Activity

Deployment docs tweak

Browse Source
This commit is contained in:
Andrew Godwin 2016-03-02 17:11:24 -08:00
parent 484320a675
commit 05e0f739d5
1 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/deploying.rst
View File

@ -97,18 +97,20 @@ cluster on the backend, see :ref:`wsgi-to-asgi`.
If you want to support WebSockets, long-poll HTTP requests and other Channels If you want to support WebSockets, long-poll HTTP requests and other Channels
features, you'll need to run a native ASGI interface server, as the WSGI features, you'll need to run a native ASGI interface server, as the WSGI
specification has no support for running these kinds of requests concurrenctly. specification has no support for running these kinds of requests concurrently.
Channels ships with an interface server that we recommend you use called Channels ships with an interface server that we recommend you use called
*Daphne*; it supports WebSockets, long-poll HTTP requests, HTTP/2 *(soon)* `Daphne <http://github.com/andrewgodwin/daphne/>`_; it supports WebSockets,
and performs quite well. Of course, any ASGI-compliant server will work! long-poll HTTP requests, HTTP/2 *(soon)* and performs quite well.
Of course, any ASGI-compliant server will work!
Notably, Daphne has a nice feature where it supports all of these protocols on Notably, Daphne has a nice feature where it supports all of these protocols on
the same port and on all paths; it auto-negotiates between HTTP and WebSocket, the same port and on all paths; it auto-negotiates between HTTP and WebSocket,
so there's no need to have your WebSockets on a separate port or path (and so there's no need to have your WebSockets on a separate port or path (and
they'll be able to share cookies with your normal view code). they'll be able to share cookies with your normal view code).
To run Daphne, it just needs to be supplied with a channel backend; To run Daphne, it just needs to be supplied with a channel backend, in much
first, make sure your project has an ``asgi.py`` file that looks like this the same way a WSGI server needs to be given an application.
First, make sure your project has an ``asgi.py`` file that looks like this
(it should live next to ``wsgi.py``):: (it should live next to ``wsgi.py``)::
import os import os
@ -128,7 +130,10 @@ like supervisord to ensure it is re-run if it exits unexpectedly.
If you only run Daphne and no workers, all of your page requests will seem to If you only run Daphne and no workers, all of your page requests will seem to
hang forever; that's because Daphne doesn't have any worker servers to handle hang forever; that's because Daphne doesn't have any worker servers to handle
the request and it's waiting for one to appear (while ``runserver`` also uses the request and it's waiting for one to appear (while ``runserver`` also uses
Daphne, it launches a worker thread along with it in the same process). Daphne, it launches a worker thread along with it in the same process). In this
scenario, it will eventually time out and give you a 503 error after 2 minutes;
you can configure how long it waits with the ``--http-timeout`` command line
argument.
Deploying new versions of code Deploying new versions of code