Newsgroup: it.comp.lang.delphi
Titolo: Suggerimento per modello di logging

Devo implementare un sistema di logging che abbia la principale
caratteristica di essere performante.
Riguardo l'architettura ho pensato ad una parte client ed una server:
quella server resta in ascolto su una porta socket e logga su db tutti i
messaggi speditegli, dopo averli eventualmente bufferizzati in code, e
quella/e client spedisce al server il messaggio di log.
Secondo voi qual'è il miglior modello di spedizione che sia il più
performante? Spedisco messaggi di windows, oppure una struttura record?
Devo essere il più veloce possibile, perchè il sistema di logging verrà
utilizzato per loggare una GUI particolare, dove si scatenano numerosissimi
eventi, e non deve essere appesantito da un log che "mangia" preziosi
millisecondi.
Esperienze in merito di qualcuno ce ne sono?
Ciao a tutti e buon inizio settimana.
-- 
Morde

 performante? Spedisco messaggi di windows, oppure una struttura record?
Se il server di log ascolta su socket, scrivi su socket. Comunque, fai dei
test, perché l'IPC potrebbe non essere performante come pensi.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 test, perché l'IPC potrebbe non essere performante come pensi.
Attualmente, riempio una struttura di tipo record di 1k con i dati che mi 
serve loggare, e ad ogni send istanzio gli indy per collegarmi al server 
via socket, mi connetto e spedisco il messaggio.
Se tutto questo ha portato ad una stabilità accettabile del server,(facendo 
degli stress test con svariati milioni di invii in parallelo il server non 
è mai caduto e nessuna perdita dei dati si è mai verificata) tuttavia 
sembra che questo modello implementativo sia poco performante sulla 
velocità.
Se vengono effettuati decine di invii al secondo (siamo in una GUI) il 
client subisce un rallentamento di circa due terzi del tempo totale.
Tempistica con log attivo e server in ascolto, ad es. 10 secondi. Con 
server log spento, 3 secondi. (c'e' un if che controlla se il server è 
attivo, nel caso non lo fosse salta la parte di connessione al socket).
Secondo la tua opinione, a livello di progettazione, devo spedire un altro 
tipo di messaggio al server, ad esempio un messaggio custom di windows? In 
questo caso potrei crearmi un proxy che riceve messaggi di windows e 
instrada via socket al server (che non verrebbe modificato).
Queste sono le mie esigenze: scaricare il più possibile il client che logga 
dai tempi di connessione socket, che credo sia il responsabile di questi 
rallentamenti.
-- 
Morde

 instrada via socket al server (che non verrebbe modificato).
Secondo la mia opinione, c'è un problema di progettazione a monte: decine
di invii al secondo è un log senza senso. 
A che serve?
Chi analizzerà mai una mole così imponente di dati?
In ogni caso ti scontri con il database che deve memorizzare quelle
informazioni e, si sa, l'I/O è sicuramente un collo di bottiglia per le
performance. Il fatto di comunicare via messaggi o via socket non cambia
di molto le cose (i messaggi, anche se non te ne accorgi, richiedono
comunque a monte una fase di sincronizzazione, per natura lenta, gestita
dal sistema operativo). Dovresti, a mio parere, inquadrare meglio il
problema iniziale.


 problema iniziale.
Il concetto base è che il log, essendo multilivello (error,warning, test,
info),ci permette di testare e collaudare l'interfaccia utente, nonchè di
poter indagare allo stesso tempo sull'accaduto in fase di segnalazione di
bug.
Tante righe di log,si,ma filtrabili per categoria e processo: questo ci
permette di ricostruire e tracciare qualsiasi istante di vita di un form,
di un processo, di una costruzione di una stampa, nonchè dell'operatività
di un utente che si lamenta di anomalie/bug.
Si era scelto la strada dei socket pur sapendo che la connect ad ogni
evento appesantisce, perchè i tentativi di usare un solo socket per tutti
gli invii davano risultati scoraggianti, con frequenti blocchi del
componente di log.. non ho codice sottomano perchè è stato scartato più di
un anno fa, ricordo a grandi linee che la criticità era rappresentata dal
fatto di bombardare un socket con decine di messaggi contemporaneamente che
causava blocchi idesiderati dei client. Non ho forti skills di tcp/ip
programming, ma ricordo che si incontravano problemi di flooding..
Tuttavia condivido le tue opinioni, soprattutto sulla revisione del modello
utilizzato: purtroppo ora siamo in corsa, e rimetter mano alla
progettazione di un componente scritto più di un anno fa è al momento
improponibile.
Dal mio punto di vista, cercherò di capire come bypassare i ritardi imposti
dalle connect.. Ma non esiste in rete qualche esempio di codice robusto che
sfrutta un invio massivo di paccehtti ai socket? 
Ciao
-- 
Morde

 bug.
Ma scusa, a che pro loggare i singoli click o i movimenti del mouse o
qualsiasi altro evento si scateni nel breve intervallo di un secondo?
Decine di invii al secondo mi fa pensare a questo e considerando che
un'applicazione utente è per gran parte del tempo "idle" non ha molto
senso. Significa che stai loggando oggettivamente più di quanto ti serve
per scoprire un problema. Semplificati la vita individuando i passi
cruciali dell'applicazione e logga solo questi. In ogni caso, avere la
necessità di un log così capillare mi fa pensare che abbiate qualche
problema: non può essere così inaffidabile, un'applicazione, da non avere
neanche un macroblocco che non necessita monitoraggio.


 neanche un macroblocco che non necessita monitoraggio.
Condivido le tue vedute architetturali e apprezzo il fatto che nonostante
le poche informazioni che ti ho dato sei riuscito comunque a farti un'idea
del piccolo framework che sta dietro al programma.
Infatti non ho nessuna necessità di tracciare l'input dell'utente quale i
click o le mouse gestures, quanto quella di loggare lo stato dei managers
GUI che pilotano l'interfaccia utente stessa.
Dare ora ulteriori dettagli sul framework risulterebbe prolisso e
superfluo: è giusto però, visto che ti ho coinvolto e hai speso del tempo
per rispondermi, chiarirti che alla base della mia richiesta c'era una
necessità funzionale: la GUI oggetto del log, di per sè, è stabile. E' il
log ad avere problemi di performance (se utilizzato al fine di debugging e
tracing nella GUI) perchè vorrei utilizzarlo anche per ricostruire certe
situazioni che il cliente potrebbe scatenare. 
Come già hai scritto anche tu,e hai sicuramente intuito il modello OOP
della GUI, i log di tipo informativo sono già in essere e ci informano già
se un GUI manager è attivo e ha caricato tutti i dati. 
Forse lo sbaglio, come hai già capito, è che vorrei utilizzare il log anche
per un fine per cui non è stato progettato: il tracing degli stati
applicativi della GUI.
Tutto questo,purtroppo, è vanificato dall'implementazione del log che fa
uso di connect atomiche ad ogni send.
Ecco perchè avevo parlato all'inizio del thread di implementare un log che
fosse il più performante possibile.
Ciao
-- 
Morde

 applicativi della GUI.
Perdonami, ma in tutti gli anni che programmo ho sentito spesso parlare di
log che devono essere "performanti" e la cosa non mi ha mai convinto
troppo.
Mi sembra spesso un vile palliativo per approssimare lo sviluppo di un
progetto (tanto poi c'è il log). Non mi convince, cioè, il tracciamento a
run-time delle operazioni come metodo per individuare gli errori. A parte
che un log troppo fitto è ingestibile, a parte che ricostruire una
situazione da un log è abbastanza complicato (specie in contesti
multi-user), io ritengo che lo sforzo deve compiersi a livello di
progettazione dell'applicazione. Se il log serve per individuare gli
errori compiuti dagli utenti, bisognerebbe sforzarsi di progettare
un'interfaccia a prova d'errore; se il log serve a tracciare gli errori
dell'applicazione, allora si utilizzi massicciamente lo unit-testing.
In sostanza, il log mi sembra più il punto di partenza per la cura, che
non la prevenzione e, come si sa, "prevenire è meglio che curare"...


 non la prevenzione e, come si sa, "prevenire è meglio che curare"...
Condivido pienamente quello che dici: consapevole del fatto che non hai la
visione totale del framework e quindi puoi limitarti a darmi consigli molto
validi che tra l'altro trovano gia' applicazione nel nostro applicativo.
Abbandono la strada della performance, che ci avrebbe assicurato un plus ma
di cui ne possiamo tranquillamente farne a meno.
ciao
-- 
Morde