Confronto delle prestazioni per l'accesso a MSMQ/file di testo/database

Question

Abbiamo diverse opzioni per l'accesso alla nostra applicazione server .NET (C#). Utilizzeremo la libreria aziendale. Quindi, ecco i modi per andare:

1) Scrivere il log in MSMQ in modo sincrono, quindi leggere MSMQ con Win Service. La coda si trova sul computer locale per l'applicazione server.
2) Scrittura del registro su disco (vale a dire file di testo scorrevole) in modo sincrono.
3) Scrittura del registro nel database (Oracle, nella nostra applicazione) in modo sincrono.

L'importo del registro potrebbe essere abbastanza alto. Quindi qual è il più performante? Suppongo che l'ordine sia 1, 2, 3. Ho ragione? C'è qualche altro fattore di prestazione, oltre alla velocità di scrittura, in questo specifico scenario? Ci sono altre scelte, che non ho indicato qui, che potrebbe essere il modo migliore?

Answer 1

senza sentire esigenze dell'applicazione in termini di registrazione:

ho la sensazione che lo scenario registrazione MSMQ è un po 'di un grande martello per il problema.

MSMQ sarà sicuramente più veloce, poiché l'applicazione utilizzerà un protocollo di comunicazione di rete anziché gestire la latenza del disco e la creazione della connessione DB. &. Dato, tuttavia, che MSMQ utilizza il disco, il guadagno è probabilmente trascurabile. Quindi la domanda è se quella coda di destinazione/destinazione MSMQ si trova sul computer locale.

Stick con la registrazione del disco

consideri attaccare con la registrazione in un file sul disco con rollover appropriati (giorno/ora, come richiesto). Esistono soluzioni alternative se sei SUPER interessato alle velocità del mandrino - considera di scrivere quei file di registro su un disco RAM. Avere quindi un processo per copiare periodicamente quei file dalla RAM e sul disco come si ritiene opportuno.

misurare la vostra performance registrazione esigenze

Cue le battute su ottimizzazione prematura. Misura e misura di nuovo. Semplicemente non saprai di cosa hai bisogno fino a quando non misurerai quanto sta funzionando la tua soluzione. Si consideri che probabilmente si hanno mandrini da 10.000 giri/min, e probabilmente una soluzione di registrazione del disco funzionerà adeguatamente. Potrebbe insinuarsi un po 'di YAGNI se si decide di passare alla soluzione complessa di un componente "in outsourcing" come MSMQ o una scrittura di database. Dico questo con i tuoi bisogni dichiarati sulla velocità.

Answer 2

Penso che dovresti considerare "Scrivi registro nel database in modo asincrono". Ad esempio, per ogni elemento che si desidera registrare, accodarlo in memoria e scrivere un thread separato nel database. Non ha senso mantenere l'applicazione principale in attesa del completamento della registrazione, a condizione che l'ordine dei messaggi di registrazione sia mantenuto dal meccanismo di accodamento.

Inoltre, hai dato un'occhiata a log4net? Include numerose opzioni di registrazione tra cui un potente registro rotante su disco, registrazione UDP, ...

Si potrebbe anche voler guardare a Splunk come un modo per cercare i file di registro dopo averli creati.

Answer 3

La classifica di MSMQ, File e DB deve essere corretta in situazioni tipiche.

So che sei preoccupato per le prestazioni ma devo ancora incontrare uno scenario in una linea di applicazioni aziendali in cui mi sono rammaricato del meccanismo di registrazione utilizzato.Se confrontato con la quantità di tempo impiegato nell'esecuzione della logica aziendale, il tempo impiegato per la registrazione non era solo significativo.

Inoltre, se si è davvero preoccupati delle prestazioni, è consigliabile esaminare altre opzioni oltre a Enterprise Library. per esempio. log4net è storicamente più veloce.

Oltre alle prestazioni, prenderei in considerazione anche altri requisiti. per esempio. Hai bisogno di segnalare o interrogare sui log? Hai bisogno di un repository di log centralizzato (o sarebbe utile)? Se le risposte a una qualsiasi di queste domande sono sì, probabilmente vorrai andare con un database o MSMQ che alimenta un database.

Altre considerazioni potrebbero essere implementazioni o standard esistenti, complessità della soluzione complessiva (file MSMQ>), supportabilità delle varie opzioni (ad esempio, potresti non voler utilizzare MSMQ se non ci sono competenze operative).