1. Mailing Lists
  2. Contributors
  3. Workers on odoo.sh

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Reducing the size of a database

Can we improve our 2024 OCA Membership numbers in the next few days and set a new record?

Avatar

Workers on odoo.sh

by
Therp, Tom Blauwendraat
- 21/01/2024 23:17:49

Hi community,

I have something that's puzzling me.

We migrated an Odoo instance from odoo.sh to our server, in multiprocessing mode with workers=8. A thing with multiprocessing mode is that each of these 8 workers has their own cache, so that whenever Odoo is restarted or cache gets otherwise cleared, it takes 8 HTTP calls for all caches to be filled again, so only from the 9th call things can start getting faster. I've always thought that this is a necessary evil in Odoo. Fabien seems to have done some tests with shared cache, but AFAIK these are just tests.

Now I've checked their previous odoo.sh instance which is configured with 5 workers. Long ago I read "somewhere" (can't find it anymore) that SH workers are not really workers, which intrigued me; at that time I thought they must be threads, or (gunicorn?) WSGI threads, but I didn't pay any more attention to it. But my tests reveal that on their instance, any second RPC call is already quicker, and on shell, I see Odoo is started with workers=0, so in multithreaded mode. I see no sign of gunicorn anywhere.

In Odoo's documentation however, they explicitly warn against workers=0 because of the GIL:

https://www.odoo.com/documentation/17.0/administration/install/deploy.html

What am I looking at here? Did odoo.sh find a magic cure for the GIL, or are they just not following their own advice and preferring the memory frugality and cachiness of workers=0 above possible GIL-induced performance hits ?

-Tom