2010-09-17 13 views
9

Ho un'applicazione composta da diversi servizi WCF, alcuni dei quali sono implementati in Workflow Foundation (.NET 3.5), altri semplicemente C#. Questi servizi comunicano tra loro su un netNamedPipeBinding per motivi di prestazioni. Il guaio è che vedo sempre più CommunicationException e le PipeException sottostanti non appena il carico del sistema aumenta. La cosa divertente è che queste transazioni sembrano finire alla fine. Una delle ragioni è che abbiamo un meccanismo di riprova nei flussi di lavoro, ma anche le chiamate dai normali servizi C# riescono anche se vedo questi errori nelle tracce WCF. C'è qualche meccanismo di riprova nel sottosistema di pipe denominato di Windows o qualcosa del genere?Come si risolvono PipeExceptions e CommunicationExceptions in WCF?

Tuttavia, voglio correggere questi errori o almeno comprendere il problema sottostante. Sento che stanno influenzando le prestazioni e la stabilità dell'applicazione. Come faccio a diagnosticare correttamente la causa principale di questi errori se non vedo altre eccezioni provenienti dai servizi stessi?

Ecco alcune delle eccezioni che ricevo:

PipeException:Si è verificato un errore durante la lettura dal tubo: Il tubo è stato terminato. (109, 0x6d).

E:

PipeException:L'operazione non può essere completata perché il tubo è stato chiuso. Questo potrebbe essere stato causato dall'applicazione all'altra estremità della pipa in uscita.

entro un TimeoutException:Il raccordo è stato interrotto poiché una lettura asincrono dal tubo non è stato completato entro il timeout assegnato di 00:02:00. Il tempo assegnato a questa operazione potrebbe essere stato una parte di un timeout più lungo.

Ora l'eccezione di timeout sembra provenire dal fatto che il sistema ha problemi a gestire il carico. Queste operazioni sono abbastanza piccole normalmente ma la quantità di esse sembra essere il problema. Oppure questo potrebbe essere il risultato di precedenti connessioni di tubi che sono state interrotte e non restituite al pool?

Ho provato a sperimentare con un servizio di controllo del comportamento nella configurazione di WCF per aumentare la quantità di istanze ecc. Ma questi errori continuano a emergere. Qualche consiglio?

/EDIT: ho attivato sia la traccia WCF che la registrazione dei messaggi. È lì che vedo le PipeExceptions e le CommunicationExceptions. L'applicazione stessa non mostra errori. Abbiamo strumentato i servizi WCF un bel po 'in modo che tutte le eccezioni vengano registrate usando log4net e non vedo alcun errore in quei log. Tutto sembra accadere a livello di WCF.

+4

Alla fine abbiamo scoperto che ci sono problemi nello stack net.pipe della WCF. Siamo passati a un binding Http di base e oltre a far scomparire tutti gli errori, le chiamate di servizio sono diventate almeno due volte più veloci. Molto strano. – Roy

+0

come lo hai scoperto alla fine?Sto incontrando problemi simili ma non sono ancora pronto per saltare la nave ancora su basic HTTP. –

+0

@ColeW whoo, questa è una vecchia domanda, devo tornare nella mia memoria. Penso che abbiamo ottenuto un feedback sulla mailing list dei Regional Director, il mio collega è un RD che lo stack net.pipe non era stabile sotto carichi elevati e dopo aver testato con basicHttp, abbiamo ottenuto un throughput molto migliore e servizi più stabili. Ho abbandonato da tempo la WCF quindi non sono sicuro dello stato attuale. Triste per sentire che stai ancora avendo gli stessi problemi. – Roy

risposta

2

È possibile attivare la registrazione e la tracciabilità dell'attività sul servizio. Quindi utilizzare il Visualizzatore Traccia di servizio per avere una visione chiara della sequenza di eventi.

Ciò fornirà un'enorme quantità di dati da esaminare, quindi suggerisco di attivarlo solo per un test case e quindi disattivarlo. Questo dovrebbe limitare il volume dei dati.

+0

Grazie, in effetti l'ho già fatto. Questo è in realtà dove vedo le PipeException e non necessariamente nella mia applicazione. – Roy

Problemi correlati