ARGOMENTO: odoo v.10

Vi ringrazio per la spiegazione approfondita sul tema. Mi serve un'ultima informazione sulla scalabilità di odoo e possibilità di gestire contemporaneamente un grande numero di utenti connessi.

L'architettura 2-tier di Odoo limita la scalabilità di questo, dico bene? Inoltre quanti utenti regge contempoaneamente prima di calare drasticamente dal punto di vista delle performance??

Grazie molte.

Alvise1994 ha scritto: Odoo ha un'architettura three tier perchè potenzialmente potremmo avere:

1. Presentation server
2. Application server
3. Database server

La scalabilità quindi è garantita.
Tuttavia non esistono case histories che consentano di dire a che punto le prestazioni calano, anche perchè bisognerebbe riferirsi a una release specifica definita come modello, il che per la natura della soluzione è operazione ardua.

Alvise1994 ha scritto:
L'architettura di odoo non è 2-tier ma 3-tier.

La parte presentazione è svolta da javascript
La parte di Business Logic è gestita da python con chiamate REST
La parte di storage su postgress

Odoo puo' essere scalato a livello orizzontale o verticale a seconda delle specifiche esigenze e carico.

Ad oggi a parte poche guide non esiste nulla di precostruito pertanto bisogna procedere a mano, in altre parola l'architettura "semplice" di odoo (chiamate rest) si presta magnificamente a far scalare il prodotto anche su migliaia di utenti ma non vi è nulla di pronto, nessuna installazione pensata per il cluster.

Nota personale, un'istallazione pensata per il cluster avrebbe poco senso visto la struttura di odoo ma delle linee guida non farebbero di certo male.

Giusto un esempio, per ottenere un cluster di odoo devi frapporre allo stesso (ma generalmente si fa) un server web (nginx o apache) e configurare su questo n-nodi su cui gira odoo con politiche di distrubuzione del carico e sessioni bloccate. Poichè odoo non implementa nulla per il cluster la situazione descritta prima va bene ma se cade un nodo sei costretto ad autenticarti. Esiste un modulo , ma non l'ho mai provato, che implementa le sessioni tramite redis e non con il classico filesystem come fa ore che dovrebbe risolvere il problema (a patto di implementare dei cluster basati su redis).

Il cluster sulla base dati lo fai con gli strumenti di postgress, con tutti i pregi ed i difetti di questo strumento.

Tutto questo per dire che creare un sistema scalabile con odoo è fattibile, ed anche meglio di altri sistemi aggiungerei, ma non è ne banale ne coperto dall'installazione base.

In questo stesso forum troverai qualche mio intervento inerente le configurazioni di produzione di odoo se ti servono altri spunti.

Grazie per avermi chiarito i dubbi, tuttavia non capisco a questo punto come mai tra NAV ,SAPB1, ODOO

SAPB1 sia l'unico con architettura 2-tier ,pur essendo tra tutti questi 3 il più costoso in assoluto.

Un'altra fonte mi aveva detto testualmente su odoo "Può essere classificato come un 2-tier architecture, multi-layer, tuttavia questo concetto è diventato obsoleto,da quando si parla di microservices, Tempo fa c'era 1 distinzione tra presentazione e logica, siccome il server e la componente web erano 2 servizi separati. Adesso invece la parte web è 1 modulo x il server , ergo i 2 layers sono lo storage Postgres e l'application server"

La tua fonte ti ha detto una strunzata per usare un eufemismo.

Dove gira una layer non è importante, pensa se fai girare odoo e postgress sulla stessa macchina e poi sempre dalla stessa macchina accedi tramite bowser allo stesso. Che diventa 1-layer? :d esempio forzato ovviamente.

Esistono 3 logiche distinte in odoo.

- quella implementata in javascript che viene eseguita sul browser. Questa logica, insieme al browser, si occupa di gestire il rendering dell'interfaccia, rispondere agli eventi utente etc etc

- quella implementata in python che gira sull'application server

- il DB server con, ma odoo non la usa, logica che potrebbe girare li.

Affinchè un'applicazione possa essere definita n-tier ogni layer deve poter girare in un ambiente a parte. Che poi lo faccia o meno non è importante.

Per farti un esempio, supponiamo di avere una applicazione implementata come una mega applet (ce ne stanno ti assicuro) e che questa acceda direttamente al DB. Il fatto che acceda al web server o che l'applet giri su di un browser non cambia nulla, l'architettura è 2-tier. L'applete si occupa dell'interfaccia e dell'esecuzione della business logic mentre il db è usato come dati.

Se in questa architettura (applet) stacco la business logic e la faccio girare sul "web server" l'applicazione diventa 3-tier (applet-business logic-db).

E fin qui le cose semplici perchè volendo andare oltre andrebbero scomodati design pattern, modelli MVC e via dicendo. Quando trattai questi argomenti il corso che tenevo era da 6 crediti mettere tutto in un post è abbastanza difficile

Posso solo farti notare questo, odoo in termini di pulizia è un po' incasinato. Il motivo principale sono le on_change. Questi metodi rispondono a cambiamenti nell'interfaccia e se vogliam essere puristi andrebbero eliminati dal modello (classe che rappresenta l'oggetto). Cio' non di meno odoo è 3 layer, puoi benissimo riscriverti tutta la parte di interfaccia tramite una app ad esempio ed invocare odoo solo ed esclusivamente tramite xml-rpc. Cosa perderesti, a meno di non farci attenzione? gli on_change

@Gigidn
per favore, evita di dire a qualcuno "hai detto una strunzata".


So che lo hai in modo scherzoso ma il destinatario potrebbe pensarla diversamente.

Rispettiamo i pareri di tutti, giusti o sbagliati che siano. Ci sono già abbastanze persone che portano la discussione in rissa.

Quale membro del direttivo e fonte autorevole, sei obbligato a frenare i tuoi istini molto più degli altri.

PS
Tecnicamente ha perfettamente ragione!