¿Esta Odoo realmente optimizado para Web de media o alta carga?

[Gladiolo El Gladiador]

Me gustaría conocer otras opiniones.

Tuve experiencias con odoo y web chicas con pocos visitantes y funciono bien. En lo que respecta a vista y seo me resulto fantástico. 

Pero también tengo un cliente que tiene 30 usuarios recurrentes en la aplicación (en /web) en el horario de comercio (asistencia, presupuestos, crm, facturas, stock, Suplier portal, impresión de precios de góndola, etc) mas los visitantes a la pagina web y la experiencia fue diferente.

En general va todo viento en popa. Pero tuve que meter mano a varias cosas para que con 20 personas recurrentes (ni hablar de cibermoday) el website no se arrastre.

• Es necesario usar workers: Si algo sale mal (una búsqueda que consume mucho, un proceso muy pesado) no afectar la experiencia de todos los usuarios sino de solo un grupo.
  
• Tiene que estar detrás de un nginx o Apache (A mi me gusta nginx). No 0 por el SSL y los certificados.  Sino porque contás con mas herramientas para defenderte de ataques. Por ejemplo los ataques de sql injection. Que no afectan a odoo, pero consumen muchos recursos y terminan siendo casi de ddos.
  Para eso las expresiones regulares de nginx o el mod_security de apache van de perilla. Ademas es facil  bloquear buscadores rusos que indexan 30 o 40 paginas a la vez . 
  
  Tambien podes activar algunos caches a nivel del webserver o tener algunas app en angular que no pasen por odoo pero al compartir la URL y son mas faciles de implementar los logins y consumo de xmlrcp sin implementar cors.
  
• Hay veces que el esquema de seguridad (acceso a modelos y reglas) no es practico. Por ejemplo muestro el stock de un producto pero no me interesa que vía services alguien acceda a todo mi stock. 
  
• Muchas veces es más fácil mantener una vista completa que heredarla y modificarla. Eso implica que muchos cambios tienen que estar centralizados en un solo modulo. Arme un modulo xx_web y movi JS de varios módulos para no tener que mantener 15 módulos distintos que hacen pequeñas cosas.
  

Hay soluciones que implemente 'ad hoc'  :)

• Arme un cache de imágenes fuera de odoo servido directamente por ngnix. (Similar al esquema de Imagen cache de Drupal con el que había ya trabajado)
  
• Arme una serie de vistas nuevas para la administración de producto, menus, etc, para que los encargados de la web no tenga que pelear con el extenso formulario de producto y unificar todas las cosas referentes al website en un solo lugar.
• Cree un sistema de tags-categorias para los productos porque el sitio requería mas que categorías.

Hay cosas que me gustarían

• Que exista un modulo que cree partes de la web pre-procesadas (como en drupal o laravel) y no calcular todo en cada pagina que carga.
• Tener Redis o algo similar para acceder a las cosas más comunes más rápido
• Mejorar Optimización de imágenes

Por todo esto creo que, si bien soporta carga, no sale andando de primera y no es para cualquiera. Hay que dedicarle Tiempo

[Gustavo Orrillo]

Veamos... yo lo que creo es que Odoo a nivel performance se puede mejorar. Un ejemplo es un problema que tuve semanas atras en un cliente que necesitaba crear miles de nro de serie en forma rápida. Cuando creaba los nros de serie  usando el ORM, la performance era malisima. Por ejemplo para crear 100 o 500 nros de serie tardaba media hora. Cuando cambie el metodo de creación a actualizar directamente usando SQL, pude crear 1,000 nros de serie en cuestión de seguros.

A lo que voy es... primero hay que tener cuidado  con el ORM de Odoo.

Igual lo que te esta penalizando a vos es otro tema. El primer lugar  donde miraría es en tener en servers separados el e-commerce y el ERP. No solo por una cuestión de seguridad, sino ademas porque la  configuración del PostgreSQL para el ERP puede llegar a ser diferente a la configuración del e-commerce. Fijate que en el e-commerce vas a necesitar mas cache en la base de datos y menos actividad de escritura (por ende menos checkpoints). En el ERP es diferente. Si bien vas a necesitar cache a nivel base de datos, tambien vas a necesitar que el server este configurado para tener checkpoints más frecuentes debido a que la actividad de los writes es superior a la del e-commerce. Aparte de los workers, yo tuve que tocar el postgresql.conf, sobre todo por aspectos como los checkpoints. 

Más alla de eso, creo  que el e-commerce deberia separarse en dos grandes areas. Una que sea la navegación anónima de los usuarios, la otra es para cuando los usuarios se autentican y procesan sus compras. La última parte ahi sería con Odoo, porque lo necesitas y es más como un ERP a nivel base de datos. Pero la capa del catálogo del producto o navegación anónima por parte del usuario, lo que haría sería con una aplicación web que tome los datos de un MongoDB o un CouchDB.

My two cents,

--
Recuerda siempre poner la mayor cantidad de datos para que se entienda bien que necesitas y que respondes. Algunos errores comunes:
 
- Siempre mencionar en que versión de odoo trabajas.
- Siempre mencionar si el servidor esta en LINUX o en windows y en que versión.
- No alcanza con colocar el debug del error, debes indicar que necesitas que haga el código.
- Comparte tu código en un servidor abierto como Github, Launchpad u otro.
- Si haces un manual, tutorial o algo de interés comunal, trata de usar google docs.
 
Tu tiempo es tan valioso como el de cualquiera de la comunidad. Aquí se valora el aporte que hagas. Cuanto mas ayudes mas ayuda recibirás.
 
Nuestras normas mínimas de convivencia puede leerlas en https://groups.google.com/d/forum/odoo-argentina?hl=es-ES
---
Has recibido este mensaje porque estás suscrito al grupo "odoo-Argentina - Preguntas y respuestas para personalizadores" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-argentin...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a odoo-ar...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Gustavo Orrillo

Consultor Odoo

https://www.moldeointeractive.com.ar/blog/moldeo-interactive-1

[Damian Rotta]

Muy interesante todo lo que mencionás. Mi granito de arena es que hace poco estuve trabajando en un problema relacionado con la performance usando módulos custom de Odoo. Si bien con el equipo teníamos varias hipótesis sobre lo que podría estar saliendo mal, el uso de una herramienta de profiling linea a linea fue fundamental para aclararlas. A veces una operación que uno jamás imaginaría está llevándose una buena porción del tiempo total: por sutilezas de implementación, por errores de diseño, etc. La herramienta que usamos se llama line-profiler (https://github.com/rkern/line_profiler/) e implica algunas vueltas para instalarla pero se integra de lo más bien con Odoo.

[Jose Luis Bossio]

Gracias Damian por el aporte.

Saludos Cordiales / Best regards / Mit freundlichen Grüßen

Jose Luis Bossio Basistech Global Services p:(+54) 3489 430974 | m:(+54 911) 5108 5137  e:joselui...@basistech.com.ar w:http://www.basistech.com.ar

El vie., 16 nov. 2018 a las 10:41, Damian Rotta (<dip...@gmail.com>) escribió:

Muy interesante todo lo que mencionás. Mi granito de arena es que hace poco estuve trabajando en un problema relacionado con la performance usando módulos custom de Odoo. Si bien con el equipo teníamos varias hipótesis sobre lo que podría estar saliendo mal, el uso de una herramienta de profiling linea a linea fue fundamental para aclararlas. A veces una operación que uno jamás imaginaría está llevándose una buena porción del tiempo total: por sutilezas de implementación, por errores de diseño, etc. La herramienta que usamos se llama line-profiler (https://github.com/rkern/line_profiler/) e implica algunas vueltas para instalarla pero se integra de lo más bien con Odoo.

--

[Gladiolo El Gladiador]

Se la ve buena, voy a pegarle una mirada.

¿Las evaluaciones las hiciste en desarrollo?, ¿no es para ponerlo en producción?

¿Este modulo lo probaste?si es asi ¿que te pareció?

https://github.com/Vauxoo/odoo-profiler/

[Damian Rotta]

Sí, las evaluaciones las hice en Desarrollo porque los métodos a inspeccionar tienen que estar decorados con @profile y, además, mientras se está ejecutando el profiling la performance se ve un poco degradada. No parecía buena idea ponerlo en producción, pero, por lo demás es transparente al usuario.

Por otro lado, probé el módulo de Vauxoo que mencionás. Lo bueno es que no requiere mucho para ponerlo a punto. Básicamente lo que describen en el README del repo. Lo malo es que los resultados no tienen el nivel de detalle de la herramienta que te mencionaba. La salida obtenida (te lo cuento porque en el repo no lo v), es la que devuelve pstats_print2list, esto es:

• nombre del método
• cantidad de llamadas al método
• tiempo promedio de ejecución en cada llamada
  
• tiempo total de ejecución del método (en todas las llamadas)
  
• tiempo acumulado de ejecución (tiempo del método + tiempo de los métodos invocados desde allí)
• nombre del script y línea en donde se define el método
• unos campos factor y rcalls que no recuerdo que significan.
  

[Andrés]

Hola nuevamente,

Consulta para Gustavo... Me dio curiosidad lo que decias de separar los servers? Como se suele hacer? Tener dos instancias conectadas de alguna manera o tener una aplicacion ecommerce que interactue con Odoo?

Saludos!

[Gustavo Orrillo]

mi granito de arena con este tema... fijense en la performance de la vista sale_report. Apenas crece el volumen de Odoo es terriblemente lenta, y es consultada cada vez que Odoo levanta el campo sales_count del product.template

My two cents,

[Jean-Paul Turcaud]

Holà Gustavo !

As-tu reçu ma communication.  Désolé,  je parles pas (encore)  espagnol. 

Bien visa, amigo.  JP

[Gladiolo El Gladiador]

Que coincidencia!!!, vos sabes que justo estoy con  esa vista, buscándole la vuelta.

Lo que mas consume parece que es el tema de currency, tengo ganas de transformarla en una materialized view.

Lo que decís de compartimentar la web y el ERP, es correcto, pero depende el escenario.
En este caso con 5 bases de datos en 4 motores diferentes la idea es unificar y no seguir "interoperando" y agregando procesos de auditoria automatica sobre la sincro.  Porque problemas tienden a ocurrir, con una conectividad que no es mala pero lejos de perfecta.

[Gustavo Orrillo]

yo lo que hice fue:

- deshabilitar el acceso a los usuarios a dicha vista

- modificar el campo "sales_count" o algo asi del product. product para que no consulte la vista.

Lo que termine haciendo es una consulta más sencilla en la que se que tengo que hacer el join de dos tablas (sale_order_line y sale_order). No necesito saber el monto de la moneda.

[Gustavo Orrillo]

El otro tema sobre que hacer con respecto a la arquitectura... da para debate y la verdad es que no existen "silver bullets"

a todo esto, con que versión estas corriendo?

[Gladiolo El Gladiador]

BA sigo en 8, No tengo por ahora planificado migrarlo.

Tengo otros proyectos mas chicos en producción en 9.

El 11 me esta gustando, para futuros proyectos, la verdad es que no conozco el roadmap de python 2 y ya arrancar con 3 me da mas seguridad.

[Gustavo Orrillo]

no vale la pena migrarlo... sigue andando bien la versión 8

[Gustavo Orrillo]

che... sacale el sale.report de la vista de productos, porque estoy revisando el log de PostgreSQL y la unica consulta que realmente tarda, es esa

[Gladiolo El Gladiador]

Si me esta matando. Ya lo vi la semana pasada. estaba intentando cosas en desarrollo, pero voy por lo que decís vos que es lo mejor. 

[Gustavo Orrillo]

tambien habilita el logging de los queries lentos en el PostgreSQL, porque tambien te va a indicar que queries estan tirando abajo el sistema

[Gustavo Orrillo]

Y siguiendo con la lista... yo sacaria los dashboards de ventas (por ejemplo). Son re-copados y re-vistosos, pero seria mejor que tome los valores de tablas con los datos ya sumarizados