Prestazioni Gestionale su server diversi.

mercoledì 31 dicembre 2008 - 09.37
Elenco Threads
Stanze Forum
Aggiungi ai Preferiti
Cerca nel forum

Teo Profilo | Junior Member

61 messaggi | Data Invio: mer 31 dic 2008 - 09:37
Salve a tutti,
chiedo il vs. aiuto per ottenere qualche suggerimento per scoprire a cosa e' dovuta la differenza di prestazioni del ns. gestionale aziendale su server Diversi.

La situazione e' questa:
Macchina fisica Blade Server con tot. lame 32 processori e non so quanta ram. I dati sono su una SAN collegata in Fiber Channel.
Il tutto gestito con VMWare Infrastrucuture direttamente in data center, quindi non direttamente accessibile a me.

Il gestionale e' MagoXP 1.3.10 con db Microsoft SQL Server 2000 - 8.00.2039:
- Primo server virtuale con Win 2003 R2 Enterprise con 3 gb di Ram e un processore dual core dedicato.
- Secondo Server virtuale con Terminal Server Win 2003 R2 Enterprise, 6 gb di Ram, due processori dual core dedicati.
- Terzo Server virtuale con Terminal Server Win 2003 R2 Enterprise, 3 Gb di Ram e anche qui due processori dual core dedicati.

Il comportamento che trovo strano e' la differenza di prestazioni sui tre server diversi.
Se lancio dei report che utilizzano delle funzioni di MagoXP per calcolare dei dati (es. disponibilita' articoli per deposito, o anche un "semplice" mastrino contabile ho risposte molto diverse in termini di prestazioni sui tre server, dove in genere e' molto pi' veloce l'esecuzione dal server con SQL installato, ma meno performante in fatto di processori.
Es. di tempi di risposte con un semplice report sul magazzino che calcola la disponibilita' alla data per deposito:
- Primo Server con Sql 1 processore Dual Core e 3 Gb di Ram: 0' 38 "
- Secondo Server con TS 2 processor1 Dual Core e 6 Gb di Ram: 4' 14"
- Terzo Server con TS 2 processor1 Dual Core e 4 Gb di Ram: 1' 39"

La cosa mi lascia alquanto perplesso in quanto dovrebbe lavorare il processo Taskbuilder.exe in locale e sfruttare quindi le risorse in locale, fatto salvo ovviamente il fatto che l'esecuzione diretta sul server con sql dovrebbe essere leggermente piu' performante perche' viene bypassata la rete.

Scusate la lunghezza del post e ringrazio chiunque riuscira' a darmi qualche spunto per indagare su questo fatto.

Buon 2009 a tutti.

R3GM4ST3R Profilo | Junior Member

196 messaggi | Data Invio: mer 31 dic 2008 - 10:03
Ciao!
(parto dal presupposto che i vari SP siano stati installati)
cmq questa è proprio una bella domanda...ci possono essere svariate ragioni, la prima che mi viene in mente guardando i risultati è che ci deve essere qualche problema nella gestione delle priorità tra le comunicazioni dei server, il passaggio dai 40 secondi del primo server ai 4 minuti del secondo server mi sembra un tantino esagerata, considerate le risorse hardware a disposizione...L'altra cosa che mi viene in mente è che essendo dei Terminal Server non siano stati ottimizzati.
Ti consiglio di dare un'occhiata alla configurazione delle macchine virtuali che non sia impostata qualche limitazione su banda o risorse hardware...

Fammi sapere mi interessa questo argomento!

Ciao!
Tutti sanno che una cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. (Albert Einstein)

Teo Profilo | Junior Member

61 messaggi | Data Invio: mer 31 dic 2008 - 10:19

[b]Da Terminal Server 1 [/b]
Ciao,
il problema e' che no ho accesso direttamente a VmWare e nemmeno alle macchine come amministratore totale, essendo appunto in Data Center e gestite dal loro personale (gia' interrogati su questo aspetto, sto ancora attendendo una loro risposta )

Ho provato con dei ping:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

ping dbtake -t -l 36000

Pinging dbtake.takeuchi.int [10.100.100.9] with 36000 bytes of data:

Reply from 10.100.100.9: bytes=36000 time=4ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=2ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=5ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=2ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=5ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128

Ping statistics for 10.100.100.9:
    Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 5ms, Average = 0ms

[b]Da Terminal Server 2 [/b]
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

ping dbtake -t -l 36000

Pinging DBTAKE.takeuchi.int [10.100.100.9] with 36000 bytes of data:

Reply from 10.100.100.9: bytes=36000 time=4ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=2ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128

Ping statistics for 10.100.100.9:
    Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 4ms, Average = 0ms

[b]Dal server con SQL verso se' stesso [/b]
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

ping dbtake -t -l 36000

Pinging dbtake.takeuchi.int [10.100.100.9] with 36000 bytes of data:

Reply from 10.100.100.9: bytes=36000 time=11ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=3ms TTL=128
Reply from 10.100.100.9: bytes=36000 time=1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128
Reply from 10.100.100.9: bytes=36000 time<1ms TTL=128

Ping statistics for 10.100.100.9:
    Packets: Sent = 28, Received = 28, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 11ms, Average = 0ms

R3GM4ST3R Profilo | Junior Member

196 messaggi | Data Invio: mer 31 dic 2008 - 10:56
Escluso il problema di rete/banda rimane il problema di configurazione delle macchine virtuali/terminal server.
Mi sa che devi aspettare maggiori informazioni da chi configura e gestisce il tutto...
Chiedi all'amministratore se può "dedicarti" una macchina virtuale per un paio di giorni nella stessa rete del server con sql così fai ulteriori test di connessione bypassando lo step del terminal server...
Con le poche info a disposizione non mi viene in mente altro al momento...

Ciauz
Tutti sanno che una cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. (Albert Einstein)

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: gio 1 gen 2009 - 16:36
Il motore di reportistica di TaskBuilder (Woorm) esegue l'estrazione dati nello stesso Thread di UI, mantenendo attiva l'interfaccia grafica con un pump dei messaggi (dovresti vedere il processore che sale dovuto proprio al pump dei messaggi e non all'estrazione dati).
Nella 3.0 di Mago.Net il tutto avverrà in un thread dedicato (tutto l'applicativo diventa multithread) quindi tutta un'altra storia.
Per esperienza personale, mi è capitato non poche volte che il "ritardo" di elaborazione dipende dal refresh a video in TS. Se provi ad iconizzare le maschere e a tirarle su ogni tanto dovresti vedere un incremento di prestazioni non banale.
Credo questo dipenda dal pump forzato per tenere attiva la ui mentre si leggono i dati; probabilmente le continue notifiche di refresh sono mal gestite da TS.


PS: Mago.XP è spaventosamente vecchio.... credo sia il caso di fare l'upgrade a Mago.Net...

Teo Profilo | Junior Member

61 messaggi | Data Invio: gio 1 gen 2009 - 18:49
Ciao Andrea,
grazie della risposta e benvenuto.
Posso chiederti cosa intendi esattamente con pump dei messaggi?
Per il trucchetto di iconizzare e reingrandire la sessione di Terminal Server, provo e ti faccio sapere.
Cmq le risorse vengono occupate localmente da Woorm, perche' la lancio un report basato su una view, o anche su una sp, questo e' praticamente immediato.

Per Mago.Net, migrerei molto volentieri, se fossero pronti i verticali che usiamo abitualmente in azienda: purtroppo temo che dovro' migrare verso fine 2009. :-(

Interessante questa info sulla 3.0, che mi sembra in beta da un bel po' ormai e quindi dovremmo quasi esserci, immagino. Sara' anche totalmente web based? :-D
Lavori in MA?

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: gio 1 gen 2009 - 20:01
Pump significa che taskbuilder.exe per simulare il multithreading (usando odbc con una unica connessione non erano percorribili altre strade) c'e' un ciclo while che legge i messaggi dalla coda di applicazione e li dispatcha (simula la winmain) per evitare di avere la ui bloccata fino a che l'elaborazione è in corso. Motivo per cui la cpu va a palla.

Non lavoro in MA ma è quasi se lo fosse, alcune parti di TB le ho scritte io; sviluppo verticali su mago da più di 10 anni, tant'è che ho aperto una sw house ad hoc

parolo.guido Profilo | Newbie

2 messaggi | Data Invio: mar 10 feb 2009 - 12:46
Scusate se approfitto degli interlocutori di questo post, per porre una nuova domanda. Qualcuno ha provato ad installare il client di MagoXp o MagoNet in una Virtual Machine gestita tramite WmWhare. L'idea sarebbe di testare a fondo una VM e distribuirla (copiarla periodicamente) su un numero elevato di Client, ben dotati di memoria e processori. Vi sono problemi o limitazioni di Microarea ?

Grazie
Guido

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: mar 10 feb 2009 - 12:53
Sinceramente credo non sia economicamente conveniente: per ogni VM dovresti avere una licenza extra del sistema operativo -> due licenze di OS per singolo client.

In rete locale ogni virtualizzazione dovrebbe avere un SSID nuovo (cosa che ti obbliga a modificare la VM per ogni client).

Mago.Net e Mago.Xp sono due prodotti differenti, con policy (sia tecniche che commerciali) di installazioni differenti.

Ti conviene sentire il rivenditore che ti segue per farti consigliare al meglio, credo tu stia andando fuori strada.

parolo.guido Profilo | Newbie

2 messaggi | Data Invio: mar 10 feb 2009 - 15:17
Grazie per il 'tempo reale'. Purtroppo il rivenditore ha risposte 'classiche'.

Pensavo di partire da una base Linux e quindi il numero di licenze onerose per Client tornerebbe ad essere uno. Rigenerando la VM 'pulita' ad ogni riavvio potremmo mantenere le prestazioni pari a quelle del sistema neoinstallato. Inoltre potremmo limitare l'invasivita' dell'antivirus e dei vari sistemi di protezione con ulteriore risvolto positivo sulle prestazioni . In passato abbiamo fatto qualcosa di simile copiando e rigenerando periodicamente l'image su PC identici. Ma tante' ... mi pare di che finiamo in un binario morto a causa del SSID.

Centralizzare i processi Client su uno o piu' server puo' essere un'altro percorso, tuttavia da alcune osservazioni, la complessita' e i tempi di risposta sono talmente ampi da giustificare tale soluzione solo se e' necessario impostare una soluzione 'geografica' del gestionale.

Qualcuno ha avuto esperienze positive che vuole condividere ?

L'obiettivo e' ridurre all'osso i costi di manutenzione di un numero elevato di Client con configurazione identica e contemporaneamente mantenere le prestazioni del sistema neoinstallato.


Cordiali saluti
Guido

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: mar 10 feb 2009 - 15:37
Credo ti convenga usare Terminal Server. Ci dovrebbe essere anche un client linux, così il costo dell' os sparisce proprio.

Per quello che riguarda l'antivirus ti basta escludere le cartelle di mago sul client e quelle del server (compreso db).
Mago.Net ha l'aggiornamento automatico, per cui i client sono sempre in sync con il server. Praticamente sparisce il costo di aggiornamento su un elevato numero di client (che cmq con terminal server non avresti).

Teo Profilo | Junior Member

61 messaggi | Data Invio: mar 10 feb 2009 - 21:28
Scusatemi per l'assenza e per il ritardo nella risposta.

@Andrea: Della tua spiegazione del 1 gennaio, non essendo io un programmatore, ci ho capito ben poco , comunque il problema non si e' risolto.
Le prestazioni nei due server continuano ad essere diverse, ancora a favore del primo con risorse hw dedicate inferiori. Forse perche' uno e' configurato per ottimizzare i servizio in background (quello con SQL), mentre l'altro con solo TS no?
Se non ti dispiace, ti disturbero' in privato, giusto per scambiarci due contatti. Viste le tue competenze, non si sa mai che in futuro non mi rivolga a te come cliente. :-D


@Per Paolo: quando facevo il tecnico gestionale di Mago usavo parecchie macchine con VmWare installato, dove facevo girare sia SQL che Mago nelle varie versioni (XP, NET, verticali). Non ho ben capito cosa vorresti mettere in piedi, ma mi sentirei comunque di concordare pienamente con Andrea e suggerirti di usare Terminal Server.
Considera anche che puoi riciclare i vecchi pc e, facendogli fare il boot via rete, gli puoi caricare una mini disro linux con il supporto alle connessioni RDP, facendogli fare cosi' da puri Thin Client.

Ah dimenticavo: tutta la mia attuale struttura gira in Data Center su un blade server con VM Ware Infrastruscture, ovviamente non gestito da me (fortunatamente! :-) )

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: mar 10 feb 2009 - 21:47
@Teo: una volta caricato in memoria TaskBuilder il "carico sul sistema" è tutto sulla memoria, processore e rete. Potresti provare con i performance counter e vedere che succede sulle due macchine.

In casi particolari ho modificato Mago inserendo dei trace su file per profilare le performance ed individuare i colli di bottiglia. Sono casi veramente al limite ed è un investimento in termini di tempo non banale (quindi lo sconsiglio se non è strettamente necessario).

Per quello che riguarda la collaborazione sono lusingato ma per scelta aziendale non seguiamo i clienti finali, lavoriamo solo con i partner Microarea (in tutto il territorio) a cui diamo supporto e per cui realizziamo personalizzazioni e verticali.

@Teo, @Guido: Microarea ha aperto da poco un forum dedicato agli utenti, potreste iscrivervi e segnalare li le vostre problematiche. http://www.microarea.it/Portal/ita/it/Servizi/MicroareaCommunity.aspx

Teo Profilo | Junior Member

61 messaggi | Data Invio: mar 10 feb 2009 - 22:13
Andrea, grazie, sei veramente un mito.
Non sapevo che MA avesse aperto un forum, ora gli do subito un'occhiata.
Peccato per l'eventuale collaborazione, mi spiace molto: sono sicuro che avrei potuto apprendere molte cose utili dalle tue competenze.
Per i perfmon, direi che e' l'unica strada: quando ho un po' di tempo lo dedico a fare queste verifiche.
P.S. Due chiacchere eventualmente sui miei attuali partner, verticali e possibili future versioni multipiattaforma le possiamo fare? Mi piacerebbe molto migrare a Net, ma purtroppo al momento non e' possibile e non dipende da me.

Infine, faccio lo sfrontato e ti chiedo un suggerimento su un'idea che mi e' venuta stasera.
Avendo la necessita di gestire il processo di autorizzazione degli ordini a fornitore, e potendo lavorare come utente finale solo su Woorm e SQL, ho pensato che potrei costruire un report che lancia una banale SP, dove gli opportuni utenti autorizzati inseriscono una password e vanno a fare l'update di un nuovo campo logico su OffFor che chiamero' autorizzato.
Per Woorm e SQL tutto ok, ho un'opportuna funzione esterna di Woorm che mi permette di eseguire comandi T-SQL sul db.
La mia domanda e': riesco nelle regole di richieste di Woorm a far comparire gli asterischi mentre l'utente digita la password? Non credo proprio; hai qualche suggerimento?
La SP, ovviamente, la creerei WITH ENCRYPTION.
Se hai tempo, voglia e possibillita' di rispondermi... GRAZIE. :-D

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: mar 10 feb 2009 - 23:51
potendo fare operazioni solo "da utente finale" ti basterebbe mettere il singolo report sotto security e far chiedere a woorm solo la conferma prima di lanciare l'update. Così solo gli utenti autorizzati potrebbero cambiare lo stato dell'odf.
Non avresti bisogno di far inserire nessun password, bastano un paio di check di conferma per evitare di lanciare per sbaglio il report.

E comunque se qualcuno ha l'ordine in editazione rischi di perdere le modifiche... i dati vengono caricati in un buffer di memoria durante l'editazione e salvati in fase di conferma -> se aggiorni durante l'editazione di un altro utente che salva l'odf ti perdi l'update. Solitamente per questo tipo di gestione si personalizza in base alle policy aziendali.

Teo Profilo | Junior Member

61 messaggi | Data Invio: mer 11 feb 2009 - 09:20
Grazie 1000 del consiglio: in effetti avendo OSL ed inserendo un paio di Message e di IF su Woorm posso gestire brillantemente la cosa in questo modo.

Se ci incontreremo, avanzi un paio di spritz.

Teo Profilo | Junior Member

61 messaggi | Data Invio: gio 12 feb 2009 - 09:12
OSL su XP non permette di proteggere i fincati come il Net.
Proteggendo un fincato, li protegge tutti allo stesso modo.

Ho messo un IF sull'always che verifica il nome utente, pero' e' molto poco elegante. :-(

andrea.balducci Profilo | Newbie

7 messaggi | Data Invio: gio 12 feb 2009 - 10:14
Magari sbaglio, ma se non ricordo male la protezione del fincato dipende dal GUID presente nel .wrm. Se sei partito da un report preesistente c'e' il rischio che il GUID sia lo stesso e quindi la protezione viene "ereditata". Sono anni che ho abbandonato xp, quindi vado a memoria
Torna su
Stanze Forum
Elenco Threads
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5