ZotSell
Wizard Home |
I livelli di ottimizzazione dei DB transati e la modalità per migliorare le prestazioni devono essere valutati su più livelli .
I DB verso i device mobili vengono filtrati di default dal server in base alle risorse base destinate all'utente in funzione del suo Codice Utente ( User code).
La limitazione per Usercode (salvo setting particolari di bypass) agisce su:
- Schede clienti esportate (Clienti e destinazioni legati all'utente anagrafiche_agenti.csv)
- Risorse anagrafiche disponibili
- Ordini esportati
- Schede articoli disponibili (se utilizzato articoli_agente.csv )
- Risorse articolo disponibili
- Struttura catalogo disponibile (se utilizzato articoli_agente.csv )
Di base non vengono effettuate altre limitazioni o ottimizzazioni di sistema che possono però essere valutate in base a specifiche esigenze, questo per il fatto che filtri aggiuntivi vanno ad influenzare i tempi di elaborazione server per la predisposizione di DB personalizzati utente al momento dell'elaborazione tracciati e della richiesta utente delle sincronizzazioni di allineamento.
Evitare quindi di inserire nei tracciati:
- Anagrafiche non assegnate ad agenti attivi
- Listini e scontistiche non utilizzate dai clienti transati
- Dati di disponibilità o frequenti di articoli non più attivi o di clienti non in uso
- Risorse fisiche (file e immagini) non in utilizzo
- Dati aggiuntivi di anagrafiche o di articoli non più in uso
Molte volte si può evitare una proliferazioni di listini (Un listino per cliente) quando ad esempio le casistiche possono ridursi a pochi listini base da utilizzare per più anagrafiche. Si prediligano sempre dei listini base a cui applicare per piccole differenze di specifici prezzi personalizzati per specifici clienti
Altri esempi sono il ripetersi di scontistiche identiche per insiemi di articoli per tutti i clienti quando sia altresi possibile attribuire sconti specifici a gruppi di articoli per gruppi clienti.
Il più delle volte questi piccoli accorgimenti permettono di ridurre di migliaia di elementi il numero di righe presenti nei tracciati.
E' sempre necessario valutare queste ottimizzazioni dato che le capacità computazionali dei device mobili sono risorse sempre delicate e non hanno le capacità dimensionali dei server ove risiedono i gestionali.
Anche alle risorse (file) che vengono resi disponibili ai device è sempre bene prestare attenzione.
Particolare cura alla loro dimensione e alle effettive esigenze di utilizzo nei device. Popolare ad esempio le icone degli articoli con immagini di grosse dimensione non conforme alle esigenze può portare ad inutili rallentamenti e a crash dell'applicazione.
Bisogna inoltre tenere conto delle dimensioni complessive del Repository file dato che per il funzionamento online andranno ad occupare lo spazio del device che non sempre è abbondante oltre ai necessari tempi di download degli stessi per gli utenti . Messa a disposizione di filmati di centinaia di migliaia di Mb devono sempre essere valutati attentamente e valutarne la conversione in versioni a più bassa risoluzione e ottimizzati per i device mobili.
Il nostro personale è disponibile a supportarvi nell'analisi di eventuali ottimizzazioni in tutti i livelli di servizio previo specifica richiesta per una attività di consulenza al fine di individuare le aree critiche di ottimizzazione ed eventuali possibili punti di intervento.
| Cod. | Ultima revisione | Wiki | Note |
| 729 | 2018/07/15 - PG |
|
Ottimizzazione dei DB
Ottimizzazione base verso i device
I DB verso i device mobili vengono filtrati di default dal server in base alle risorse base destinate all'utente in funzione del suo Codice Utente ( User code).
La limitazione per Usercode (salvo setting particolari di bypass) agisce su:
- Schede clienti esportate (Clienti e destinazioni legati all'utente anagrafiche_agenti.csv)
- Risorse anagrafiche disponibili
- Ordini esportati
- Schede articoli disponibili (se utilizzato articoli_agente.csv )
- Risorse articolo disponibili
- Struttura catalogo disponibile (se utilizzato articoli_agente.csv )
Di base non vengono effettuate altre limitazioni o ottimizzazioni di sistema che possono però essere valutate in base a specifiche esigenze, questo per il fatto che filtri aggiuntivi vanno ad influenzare i tempi di elaborazione server per la predisposizione di DB personalizzati utente al momento dell'elaborazione tracciati e della richiesta utente delle sincronizzazioni di allineamento.
Ottimizzazione tracciati entranti
E' sempre opportuno ottimizzare i dati presenti nei tracciati entranti al fine di velocizzare i tempi di esecuzione delle procedure di elaborazione server.Evitare quindi di inserire nei tracciati:
- Anagrafiche non assegnate ad agenti attivi
- Listini e scontistiche non utilizzate dai clienti transati
- Dati di disponibilità o frequenti di articoli non più attivi o di clienti non in uso
- Risorse fisiche (file e immagini) non in utilizzo
- Dati aggiuntivi di anagrafiche o di articoli non più in uso
Ottimizzazione dei dati entranti
Particolare attenzione per l'ottimizzazione del dato dovrebbe essere prestata alla modalità di composizione delle politiche commerciali (listini e prezzi) al fine di evitare la presenza di dati ridondanti o inutilmente ripetitivi. L'algoritmo prezzi e sconti è appositamente strutturato per premettere un raggruppamento di articoli e anagrafiche da utilizzare per limitare il numero di righe transate.Molte volte si può evitare una proliferazioni di listini (Un listino per cliente) quando ad esempio le casistiche possono ridursi a pochi listini base da utilizzare per più anagrafiche. Si prediligano sempre dei listini base a cui applicare per piccole differenze di specifici prezzi personalizzati per specifici clienti
Altri esempi sono il ripetersi di scontistiche identiche per insiemi di articoli per tutti i clienti quando sia altresi possibile attribuire sconti specifici a gruppi di articoli per gruppi clienti.
Il più delle volte questi piccoli accorgimenti permettono di ridurre di migliaia di elementi il numero di righe presenti nei tracciati.
E' sempre necessario valutare queste ottimizzazioni dato che le capacità computazionali dei device mobili sono risorse sempre delicate e non hanno le capacità dimensionali dei server ove risiedono i gestionali.
Ottimizzazione risorse
Anche alle risorse (file) che vengono resi disponibili ai device è sempre bene prestare attenzione.
Particolare cura alla loro dimensione e alle effettive esigenze di utilizzo nei device. Popolare ad esempio le icone degli articoli con immagini di grosse dimensione non conforme alle esigenze può portare ad inutili rallentamenti e a crash dell'applicazione.
Bisogna inoltre tenere conto delle dimensioni complessive del Repository file dato che per il funzionamento online andranno ad occupare lo spazio del device che non sempre è abbondante oltre ai necessari tempi di download degli stessi per gli utenti . Messa a disposizione di filmati di centinaia di migliaia di Mb devono sempre essere valutati attentamente e valutarne la conversione in versioni a più bassa risoluzione e ottimizzati per i device mobili.
Ambienti di sviluppo e di test
In certe situazioni può essere utile dotarsi di un ambiente di sviluppo parallelo all'ambiente di produzione al fine di predisporre politiche di ottimizzazione nel tempo e poterle testare prima di renderle disponibile in produzione. Vedi questa scheda per i dettagli: Attivazione ambiente di TestIl nostro personale è disponibile a supportarvi nell'analisi di eventuali ottimizzazioni in tutti i livelli di servizio previo specifica richiesta per una attività di consulenza al fine di individuare le aree critiche di ottimizzazione ed eventuali possibili punti di intervento.