How to Set Up Workers in Odoo 19 for Better Performance: Full Guide
As an Odoo instance grows with more users, modules, and data, pages take longer to load and processes slow down. This is where the right worker configuration comes into play — not as an optional enhancement but as a basic requirement for getting good performance from the platform. Setting up workers well in Odoo 19 is one of the biggest keys to scaling your system. It allows the server to process multiple requests simultaneously rather than one at a time, transforming your Odoo instance from a single-lane road into a well-designed highway. This complete step by step beginner guide walks through everything you need to know about configuring workers in Odoo 19 for optimal performance.
What You'll Learn:
- What workers do and why they are essential for Odoo performance
- How to configure workers in the odoo.conf file
- How to calculate the optimal number of workers for your server
- How to set memory limits, CPU limits, and time limits
- How to configure longpolling for real-time features
- How to set up Nginx as a reverse proxy with longpolling separation
- How to restart Odoo after configuration changes
Understanding What Workers Actually Do in Odoo 19
Odoo 19 will begin to develop more latency as it gains users, building up over time until the system starts to feel heavy. This slow lag is due to Odoo's method of handling incoming requests. By default, each request is processed sequentially, which works well with few users but does not scale as the number of concurrent requests increases.
To speed up Odoo 19 and provide consistent performance, workers allow Odoo to process requests in parallel by creating multiple processes that handle multiple requests simultaneously. Instead of using a single thread to wait on each action's completion, multiple workers divide the workload among themselves, providing faster and more consistent service. As a result, users no longer block each other, and Odoo feels responsive even under heavy load.
Parallel Request Processing
Workers spawn multiple processes that handle requests concurrently instead of sequentially, eliminating user blocking and ensuring responsive performance.
Resource Isolation
Each worker operates independently with its own memory allocation. If one worker encounters an issue, other workers remain unaffected, maintaining overall system stability.
Memory Safeguards
Workers have configurable soft and hard memory limits. A worker that exceeds its hard limit is automatically killed, preventing runaway processes from crashing the entire server.
Longpolling Support
Dedicated longpolling workers handle real-time features like live chat and bus notifications separately from standard HTTP request processing.
Step by Step: Configuring Workers in odoo.conf
Workers in Odoo 19 are configured in the odoo.conf file. Once the worker setting has been enabled, the configuration must be tuned according to the available capacity of your server. Below is a standard and correct base-level configuration to get started.
[options]
; Enable multiprocessing
workers = 5
; Memory limits (in bytes)
limit_memory_soft = 629145600 ; 600 MB
limit_memory_hard = 786432000 ; 750 MB
; CPU and real-time limits (in seconds)
limit_time_cpu = 60
limit_time_real = 120
; Background job threads
max_cron_threads = 2
; Longpolling for real-time features
longpolling_port = 8072
Understanding Each Configuration Parameter
| Parameter | Purpose | Recommendation |
|---|---|---|
| workers | Number of worker processes to spawn | (CPU cores x 2) + 1, constrained by memory |
| limit_memory_soft | Soft memory warning threshold per worker | ~600 MB (adjust based on available RAM) |
| limit_memory_hard | Hard memory limit — worker killed if exceeded | ~750 MB (should be higher than soft limit) |
| limit_time_cpu | Maximum CPU time per request (seconds) | 60s default, increase for complex operations |
| limit_time_real | Maximum wall-clock time per request (seconds) | 120s default, covers waiting time |
| max_cron_threads | Threads for background cron jobs | 2 (one thread per cron job running concurrently) |
| longpolling_port | Port for real-time longpolling connections | 8072 (separate from standard 8069) |
How to Calculate the Optimal Number of Workers
A widely used formula for determining how many workers to enable in Odoo is based on the number of available CPU cores. The basic formula is:
workers = (CPU cores x 2) + 1
For a server with two CPU cores, the formula suggests about five worker processes. However, this is not an absolute rule — memory is equally important. The average memory used per worker ranges between 200 MB and 300 MB, depending on which modules are used and the workload. Follow this practical approach to balance CPU and memory:
Reserve Memory for System Processes
Assume approximately 2 GB of RAM will be reserved for the operating system, PostgreSQL, and other system processes before allocating any memory to Odoo workers.
Calculate Memory-Based Worker Count
Take the remaining RAM and divide by approximately 250 MB (the average memory per worker). For example, on an 8 GB server: 8 GB - 2 GB = 6 GB available, 6 GB / 250 MB = approximately 24 workers from a memory perspective.
Choose the Lower of the Two Values
Compare the CPU-based count with the memory-based count and select the smaller number. This ensures you never exceed either your CPU capacity or your available memory. For a 2-core server with 8 GB RAM, you would use 5 workers (CPU-limited) rather than 24 (memory-limited).
Experience Over Formulas
In practice, personal experience with your specific deployment will always trump generic formulas. An overloaded system with too many workers will crash much more frequently than a well-balanced and managed system with fewer workers. Start conservatively and increase gradually while monitoring performance.
How to Configure Memory and Time Limits
Setting proper limits on worker resource utilization is essential for maintaining server stability. Without these limits, one resource-intensive worker could consume all available memory and crash the entire server. The four key limit parameters are:
| Limit Parameter | Default Value | When Triggered |
|---|---|---|
| limit_memory_soft | ~600 MB | Warning logged, worker may be recycled |
| limit_memory_hard | ~750 MB | Worker is killed immediately |
| limit_time_cpu | 60 seconds | Request terminated if CPU time exceeded |
| limit_time_real | 120 seconds | Request terminated if wall-clock time exceeded |
Too Many Workers = Server Crash
A common pitfall is enabling more workers than necessary with the hope of achieving better performance. This will most likely lead to exhausting system memory and server failure. More is not always better — careful tuning based on your actual hardware and usage patterns is essential.
How to Configure Longpolling for Real-Time Features
Many Odoo systems rely on longpolling to provide live chat, bus alerts, and other real-time functionalities. If the configuration is off, these services can deliver delayed or inconsistent results. When you set up a dedicated longpolling_port, longpolling traffic is processed separately from standard HTTP traffic, ensuring real-time features always work responsively.
In the odoo.conf file, the longpolling_port should be set to a port that is not used by any other service. Port 8072 is the conventional choice, separate from Odoo's standard HTTP port 8069.
How to Set Up Nginx as a Reverse Proxy
Odoo running behind Nginx is how production systems should operate. Nginx serves as a reverse proxy to handle routing of incoming requests while ensuring that longpolling requests are kept separate from all other traffic. Below is an example of a correctly configured Nginx setup.
upstream odoo {
server 127.0.0.1:8069;
}
upstream odoo_longpolling {
server 127.0.0.1:8072;
}
server {
listen 80;
server_name your_domain.com;
proxy_read_timeout 720s;
proxy_connect_timeout 720s;
proxy_send_timeout 720s;
location / {
proxy_pass http://odoo;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /longpolling {
proxy_pass http://odoo_longpolling;
}
}
The configuration defines two upstream blocks: odoo for standard HTTP traffic on port 8069, and odoo_longpolling for real-time connections on port 8072. The /longpolling location block routes longpolling requests to the dedicated upstream, ensuring real-time features do not compete with standard request processing for worker resources.
Longpolling Separation Is Critical
The separation of real-time features from routine request processing is critical to ensure that routine requests continue to function without competing for resources, especially as your number of users increases. Without this separation, live chat and bus notifications can degrade overall system performance.
How to Restart Odoo After Configuration Changes
Odoo will not recognize modifications to the odoo.conf file until the Odoo service is restarted. This step may seem trivial, but missing it often leads to confusion when changes do not take effect.
sudo systemctl restart odoo
Real-World Performance Impact
Consider a scenario with 15 users working simultaneously on sales and accounting. Without workers configured, users experience delays while validating invoices and loading dashboards because each request is processed one at a time. When workers are configured properly, these actions all run in parallel, and the system stops feeling like a shared bottleneck and begins to function as a scalable platform.
Without Workers
Requests are processed sequentially. One slow report generation blocks all other users. The system becomes sluggish as concurrent user count increases, leading to frustrated users and lost productivity.
With Workers
Requests are handled in parallel. Each user gets their own worker process, so no single user blocks others. Background jobs run without issues, and routine transactions complete effortlessly.
Setting up workers is not about pushing your server to its limits — it is about understanding those limits and working within them. When done thoughtfully, it creates a system that not only performs well today but remains stable as your business grows. Odoo 19 requires performance to be built into the system from day one, and configuring workers is a foundational decision that directly affects Odoo's ability to perform in high-stress environments.
Frequently Asked Questions
What happens if workers are not configured in Odoo 19?
Without workers, Odoo operates in single-threaded mode processing one request at a time. As users increase, the system develops latency and lag due to slow response rates. Each user essentially blocks others until their request completes.
How can I determine the optimal number of workers for my Odoo 19 server?
Use the formula (CPU cores x 2) + 1, then cross-check against available memory. Reserve ~2 GB for the OS, divide remaining RAM by ~250 MB per worker, and choose the smaller number. Test different values without setting too high a figure initially.
Can too many workers negatively affect Odoo performance?
Yes absolutely. Too many workers can consume all available memory, causing the server to swap heavily or crash entirely. More workers is not always better. A well-balanced system with fewer workers outperforms an overloaded one with excessive workers.
Is longpolling required for Odoo workers to function?
Longpolling is not strictly required, but it is strongly recommended. Real-time features like live chat, bus notifications, and dashboard updates depend on longpolling. Configuring a dedicated longpolling_port ensures these features work responsively without competing with standard HTTP traffic.
Do I need to restart Odoo after changing worker configuration?
Yes. Any changes made to the odoo.conf file require restarting the Odoo service for them to take effect. Run sudo systemctl restart odoo after saving your configuration changes. Skipping this step is a common reason why configuration changes appear not to work.
Need Help with Odoo Performance Optimization?
Our Odoo infrastructure experts can help you configure workers, set up Nginx reverse proxy, tune PostgreSQL, and optimize your entire Odoo deployment for maximum performance and scalability.
About the author
Founder & Odoo Practice Lead, Braincuber Technologies
Founder of Braincuber. Has scoped and shipped 500+ Odoo implementations for US mid-market and global brands. Takes every founder call personally — no SDR layer between buyers and the people building the system.