Implementazione di un TraceListener personalizzato in .NET

Question

Sto cercando le migliori pratiche per implementare uno TraceListener che scriverà i registri all'interno del server SQL da un'applicazione ASP.NET.

Quali sono le cose che dovrebbero essere prese in considerazione quando si implementa tale classe al fine di evitare una riduzione delle prestazioni?

Le stored procedure saranno più veloci delle semplici istruzioni ADO.NET INSERT?

Mi piace molto l'idea di scrivere i registri in un buffer temporaneo in memoria e scaricarlo nel database in un secondo momento da un thread in background, ma quale struttura dati è più adatta per tale scenario? Queue<T> sembra un buon candidato ma non posso aggiungere elementi senza un meccanismo di sincronizzazione.

Ho trovato su Internet un article che mostra un esempio di TraceListener personalizzato che scrive sul server SQL ma prima di inserirlo nel codice di produzione vorrei avere più feedback.

Answer 1

Stored Procedure non sarà più veloce di SQL paramteized. Preferisco una stored procedure su SQL hardcoding nella mia applicazione, ma se avessi intenzione di generare le istruzioni di inserimento, allora è ancora meglio.

L'utilizzo di un buffer è una buona idea se si sta bene con l'idea che si potrebbero perdere dati. Se si desidera disaccoppiare il client dall'inserto e si desidera che sia durevole, è possibile utilizzare MSMQ. Quindi è possibile scrivere un servizio Windows che elabora la coda e che sarà completamente disaccoppiato dall'applicazione. Potrebbe inoltre aggregare i registri da più server se si dispone di una server farm.

Answer 2

log4net scaricherà traccia in un db SQL con un mucchio di opzioni a filo, ecc controllare: http://logging.apache.org/log4net/release/features.html

log4net è provata. se puoi evitare di "riscrivere la ruota" va bene?

Answer 3

Non riesco a parlare se gli SP sono più veloci degli inserti ADO, ma suggerirò sempre di mantenere i querys/nonquerys nella tua applicazione, NON nel datastore. come ora, il datastore è per i dati, non per la logica. evitare le SP

MS SQL Server è un componente complesso di macchinari e non penso che la tua applicazione possa causare il blocco del codice da troppa registrazione al tuo db. ovviamente questo è soggetto alla tua particolare implementazione e dal tuo interesse per le prestazioni posso presumere che tu voglia sostenere un volume elevato. quello che sto dicendo è che non penso tu abbia bisogno di una coda o di un servizio in memoria per completare il processo di registrazione. scarica la traccia nel db nell'app di aspnet e dimentica il caching/flushing. SQL si occuperà di mantenere in memoria le query di registrazione e si prenderà cura di scriverle su disco, infatti gestisce molto bene. Il buffer di query di SQL assicurerà che il tuo codice non blocchi quando scarichi la traccia. se non mi credi, prova con i timestamp nella finestra di debug o qualcosa del genere. se hai bisogno di modificarlo, il tweaking dovrebbe essere nelle impostazioni della memoria del tuo db. Non hai bisogno di inventare un wrapper qui, usare SP o avviare un altro servizio sul tuo server (come MSMQ), questo mangerà solo più della tua preziosa CPU e mem.