NextERP/documentation
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[IMP] deploy: reword multi-thread/process section

Browse Source 
Many users don't start odoo-bin in --workers (multi-processing) mode but
instead leave the default configuration which use the development/demo
multi-threaded server, even in production.

This commit rewords the section about the difference between the
built-in servers and highlight the many advantages of the
multi-processing on. It repeats that information when it comes to
running a dedicated cron server, that it should use the multi-processing
server instead of the default multi-threading one.

closes odoo/documentation#5887

Fixes: odoo/odoo#88984
Closes: odoo/odoo#128571
X-original-commit: 9ee92c3a27
Signed-off-by: Jonathan Castillo (jcs) <jcs@odoo.com>
This commit is contained in:
Julien Castiaux 2023-07-20 16:42:44 +00:00
parent 923839f2cf
commit 8e9ae99423
1 changed files with 46 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
content/administration/install/deploy.rst
View File

@ -179,21 +179,31 @@ or 'verify-full'
Builtin server Builtin server
============== ==============
Odoo includes built-in HTTP servers, using either multithreading or Odoo includes built-in HTTP, cron, and live-chat servers, using either multi-threading or
multiprocessing. multi-processing.
For production use, it is recommended to use the multiprocessing server as it The **multi-threaded** server is a simpler server primarily used for development, demonstrations,
increases stability, makes somewhat better use of computing resources and can and its compatibility with various operating systems (including Windows). A new thread is spawned
be better monitored and resource-restricted. for every new HTTP request, even for long-lived connections such as websocket. Extra daemonic cron
threads are spawned too. Due to a Python limitation (GIL), it doesn't make the best use of the
hardware.
* Multiprocessing is enabled by configuring :option:`a non-zero number of The multi-threaded server is the default server, also for docker containers. It is selected by
worker processes <odoo-bin --workers>`, the number of workers should be based leaving the :option:`--workers <odoo-bin --workers>` option out or setting it to ``0``.
on the number of cores in the machine (possibly with some room for cron
workers depending on how much cron work is predicted)
* Worker limits can be configured based on the hardware configuration to avoid
resources exhaustion
.. warning:: multiprocessing mode currently isn't available on Windows The **multi-processing** server is a full-blown server primarily used for production. It is not
liable to the same Python limitation (GIL) on resource usage and hence makes the best use of the
hardware. A pool of workers is created upon server startup. New HTTP requests are queued by the OS
until there are workers ready to process them. An extra event-driven HTTP worker for the live chat
is spawned on an alternative port. Extra cron workers are spawned too. A configurable process
reaper monitors resource usage and can kill/restart failed workers.
The multi-processing server is opt-in. It is selected by setting the :option:`--workers
<odoo-bin --workers>` option to a non-null integer.
.. note::
Because it is highly customized for Linux servers, the multi-processing server is not available
on Windows.
Worker number calculation Worker number calculation
------------------------- -------------------------
@ -214,18 +224,12 @@ Needed RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (h
LiveChat LiveChat
-------- --------
In multiprocessing, a dedicated LiveChat worker is automatically started and In multi-processing, a dedicated LiveChat worker is automatically started and listens on
listening on :option:`the gevent port <odoo-bin --gevent-port>` but the :option:`--gevent-port <odoo-bin --gevent-port>`. By default, the HTTP requests will keep
the client will not connect to it. accessing the normal HTTP workers instead of the LiveChat one. You must deploy a proxy in front of
Odoo and redirect incoming requests whose path starts with ``/websocket/`` to the LiveChat worker.
Instead you must have a proxy redirecting requests whose URL starts with You must also start Odoo in :option:`--proxy-mode <odoo-bin --proxy-mode>` so it uses the real
``/websocket/`` to the gevent port. Other request should be proxied to client headers (such as hostname, scheme, and IP) instead of the proxy ones.
the :option:`normal HTTP port <odoo-bin --http-port>`
To achieve such a thing, you'll need to deploy a reverse proxy in front of Odoo,
like nginx or apache. When doing so, you'll need to forward some more http Headers
to Odoo, and activate the proxy_mode in Odoo configuration to have Odoo read those
headers.
Configuration sample Configuration sample
-------------------- --------------------
@ -364,38 +368,30 @@ of workers anymore it can not setup cron or livechat workers
Cron Workers Cron Workers
------------ ------------
To run cron jobs for an Odoo deployment as a WSGI application requires Starting one of the built-in Odoo servers next to the WSGI server is required to process cron jobs.
That server must be configured to only process crons and not HTTP requests using the
:option:`--no-http <odoo-bin --no-http>` cli option or the ``http_enable = False`` configuration
file setting.
* A classical Odoo (run via ``odoo-bin``) On Linux-like systems, using the multi-processing server over the multi-threading one is recommended
* Connected to the database in which cron jobs have to be run (via to benefit from better hardware usage and increased stability, i.e., using
:option:`odoo-bin -d`) the :option:`--workers=-1 <odoo-bin --workers>` and :option:`--max-cron-threads=n
* Which should not be exposed to the network. To ensure cron runners are not <odoo-bin --max-cron-threads>` cli options.
network-accessible, it is possible to disable the built-in HTTP server
entirely with :option:`odoo-bin --no-http` or setting ``http_enable = False``
in the configuration file
LiveChat LiveChat
-------- --------
The second problematic subsystem for WSGI deployments is the LiveChat: where Using a gevent-compatible WSGI server is required for the correct operation of the live chat
most HTTP connections are relatively short and quickly free up their worker feature. That server should be able to handle many simultaneous long-lived connections but doesn't
process for the next request, LiveChat require a long-lived connection for need a lot of processing power. All requests whose path starts with ``/websocket/`` should be
each client in order to implement near-real-time notifications. directed to that server. A regular (thread/process-based) WSGI server should be used for all other
requests.
This is in conflict with the process-based worker model, as it will tie The Odoo cron server can also be used to serve the live chat requests. Just drop
up worker processes and prevent new users from accessing the system. However, the :option:`--no-http <odoo-bin --no-http>` cli option from the cron server and make sure requests
those long-lived connections do very little and mostly stay parked waiting for whose path starts with ``/websocket/`` are directed to this server, either on
notifications. the :option:`--http-port <odoo-bin --http-port>` (multi-threading server) or on
the :option:`--gevent-port <odoo-bin --gevent-port>` (multi-processing server).
The solutions to support livechat/motifications in a WSGI application are:
* Deploy a threaded version of Odoo (instead of a process-based preforking
one) and redirect only requests to URLs starting with ``/websocket/`` to
that Odoo, this is the simplest and the websocket URL can double up as the cron
instance.
* Deploy an evented Odoo via ``odoo-gevent`` and proxy requests starting
with ``/websocket/`` to
:option:`the gevent port <odoo-bin --gevent-port>`.
.. _deploy/streaming: .. _deploy/streaming: