Performance en Odoo - Como hacer el sizing del server y resolver problemas de performance

Gustavo Orrillo
- 05/01/2022 - 6 min. de lectura

Una duda que surge siempre en los proyectos son las características del server en el que va a estar corriendo Odoo. Odoo no es un sistema que consuma grandes recursos. No escuché historias de terror a nivel hardware como si escuché con otros ERPs o sistemas administrativos (me parece que la elección de Linux y PostgreSQL tienen mucho que ver con esto). Por eso, queremos compartir algunas de nuestras experiencias haciendo el sizing de los servers y luego como se resuelven problemas de performance que pueden surgir.

Mi primer consejo es... lea la documentación. Luego no escatime presupuesto en hardware. Escuché más de uno decir "consigo en tal VPS un server gratis o barato..." y esos servers eran tan baratos que ni siquiera podían instalar Odoo. Sepa que va a tener que hacer una inversión en hardware, menor. Pero inversión al fin.

Server on-premise o hosteado en un VPS?

Es un debate frecuente. Prefiero el VPS porque los tiempos de latencia son aceptables. Y porque los VPS por lo general brindan un muy buen servicio de backup y restore. Lo que en los ambientes limitados de personal como son los Odoo, es un alivio. Tambien tuve buenas experiencias con los servicios de backup y restore de diferentes VPS. Un punto bueno de los VPS, es la escalabilidad. Uno con poco esfuerzo puede agregarle recursos de memoria o CPUs a los servers. Esto muchas veces no es posible en los ambientes on-premise.

Con respecto a tenerlo on-premise, puede ser una buena idea. Solo tenga en cuenta que en ese caso usted debe administrar el server (backup, restore, performance, seguridad). Y eso no puede llegar a ser factible porque en mi experiencia, en las organizaciones que usan Odoo no abunda el personal para realizar estas tareas. 

Esto lleva tambien a la otra pregunta... corro Odoo solo o con otras aplicaciones? Por favor... en el server de Odoo solo corra Odoo y si puede... PostgreSQL. No instalé otras aplicaciones para ahorrar unos pocos dolares con los que podría comprar una Cajita Felix.

Cantidad de CPUs y cores

En este punto interviene la cantidad de usuarios concurrentes y su actividad. En mi experiencia, llegué a ver un Odoo versión 13 con cinco usuarios concurrentes (diez o quince en total) en un server con un CPU y dos gigabytes de RAM. Por lo general, el cálculo es

#cores = (cantidad de usuarios concurrentes) / 6

Y la cantidad de workers (tareas paralelas de Odoo) es igual a:

#workers = (#cores * 2) + 1 (para el thread de cron)

Deben tener en cuenta que   

Cantidad de RAM

Como calcular la cantidad de memoria de RAM que va a consumir Odoo? Para calcularlo (de acuerdo a la documentación), se puede decir que el 20% de los requerimientos al server van a ser intensivos y el 80% de los requerimientos van a ser livianos. Y por lo general (asumiendo que por sobre todo los campos computados estan bien diseñados) un worker que sirve requerimientos intensivos consume alrededor de un Gigabyte de RAM. Un worker que atiende requerimientos livianos tiende a consumir 150Mb de RAM. 

Entonces, el cálculo de la cantidad de RAM a consumirse por Odoo sería:

#RAM Odoo = #workers * (% requerimientos intensivos * cantidad RAM consumida por requerimientos intensivos + % requerimientos liviandos * cantidad RAM requerimientos livianos)

Eso es para Odoo. Para PostgreSQL, asuma que mínimo va a consumir la misma cantidad de RAM que Odoo. Por que? La base de datos hace uso intensivo de dos recursos; disco y RAM. Pero por sobre todo RAM. Una base de datos bien dimensionada va a buscar resolver la mayoría de sus requisiciones desde el cache. Una base de datos que hace intensivo de disco (porque no puede resolver sus requerimientos desde el cache) necesita ser reconfigurada para que ello no suceda.

La importancia de PostgreSQL y su relación con Odoo

Un gran problema que existe en la relación entre Odoo y PostgreSQL es que la base de datos out-of-the-box se encuentra configurada con parámetros muy conservadores. Es por ello que lo primero que debe hacerse es revisar la configuración de la base de datos y modificar los parámetros de shared memory y de los buffers para que tengan valores más realistas para el uso de la misma. Modifique los valores de los parámetros shared_buffers (la cantidad de RAM que va a usar PosgreSQL) a 25% de la cantidad de memoria RAM del server. Y setee el parámetro effective_cache_size (la cantidad de espacio en disco que usará para cache) a la mitad del tamaño de la RAM.

Soy de la opinión que muchos problemas de performance en Odoo se solucionan entendiendo como se mejora la performance de PostgreSQL (en parte eso se debe a mi experiencia trabajando en Informix). Es por ello que vamos a hablar más de PostgreSQL en las siguientes líneas. 

Identificando los problemas de performance en Odoo

Solucionar lo problemas de performance en Odoo es un trabajo que requiere paciencia y mucha observación. Si bien es posible que mejorando las características del server junto con la modificación de la configuración de la base de datos se mitiguen los problemas de performance; las chances que sigan con problemas es alta. Y esto se debe a que hay trozos de la aplicación que pueden ser problemáticos y cuellos de botella para el servidor. Es por ello que es fundamental comprender como trabaja el usuario y monitorear el uso de recursos del sistema para entender donde estan los cuellos de botella.

Un buen punto de inicio es observar físicamente el uso diario del sistema por parte de los usuarios. E identificar donde estan las areas de la aplicación donde se producen las demoras. Al mismo tiempo, se debe agregar al archivo de configuración de PostgreSQL los siguientes parámetros

log_statement = none
log_min_duration_statement = 1000 #(o la cantidad de milisegundos que desee)

Y reiniciar la base de datos. Esto lo que hará es en el archivo de log de PostgreSQL, identificar las sentencias de SQL que duren más de un segundo (cada sentencia de SQL de Odoo debería durar menos de 750ms). Inmediatamente apenas las identifique, analize porque las mismas duran mucho (SQL mal construido, falta de índices, problemas en la aplicación, etc). Y aplique los cambios necesarios.

Otra buena herramienta para identificar problemas de performance en el server es pg_statistics (ya hablamos de ella anteriormente). Por favor, instalela en el server donde está ejecutando PostgreSQL.

Los campos computados son muy bonitos, pero abusar de ellos (o al menos no almacenarlos) solo lleva a problemas de performance (cada vez que un usuario quiere ver una vista, por cada registro se computa cada uno de los campos). Es por ello que los mismos deben ser usados con juicio y conocimiento. Otro punto a tener en cuenta es que el ORM de Odoo es hasta ahí nomás de rápido, y hay áreas en las que es particularmente lento. Es por ello que muchas veces conviene reescribir algunos módulos para que utilicen SQL en lugar del ORM.

Por último, hay que saber lo siguiente. La mejora de la performance de Odoo es un trabajo continuo, no es una tarea de dos días y se acabó. Requiere de mucha paciencia y tiempo. Ya que requiere el monitoreo de la actividad de los usuarios, e ir resolviendo de los problemas de a uno (para saber cuales son los cambios que funcionan y cuales no). 

En lo posible, implemente la última versión de Odoo

Odoo es un sistema que a lo largo de los años (y sus versiones) va evolucionando. Se introducen muchas mejoras al ORM y a la performance de las aplicaciones. Por ejemplo en la versión 13 hubo un importante refactoring del ORM que incrementó en forma notable la performance del sistema. Y todos los días se ven cambios que aunque pequeños, mejoran la performance de las decenas de módulos que usamos todos los días. Es por ello que en lo posible, si implementa Odoo hagalo con la última versión (y si no es posible por problemas de la localización, migre la localización).

Acerca de:

Gustavo Orrillo

Passionate about programming, he has implemented Odoo for different types of businesses since 2010. In Moldeo Interactive he is a founding Partner and Programmer; In addition to writing on the Blog about different topics related to the developments he makes.