WCF aumento l'utilizzo della CPU del 25% per ogni cliente

Question

Come dice il titolo, ho ottenuto un server WCF avere questo comportamento del servizio definito:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)] 

I' utilizzando una named pipe vincolante ei miei clienti si connette in questo modo:

NetNamedPipeBinding binding = new NetNamedPipeBinding(); 
const int maxValue = 0x40000000; // 1GB 
binding.MaxBufferSize = maxValue; 
binding.MaxReceivedMessageSize = maxValue; 

binding.ReaderQuotas.MaxArrayLength = maxValue; 
binding.ReaderQuotas.MaxBytesPerRead = maxValue; 
binding.ReaderQuotas.MaxStringContentLength = maxValue; 

// receive timeout acts like a general timeout 
binding.ReceiveTimeout = TimeSpan.MaxValue; 
binding.SendTimeout = TimeSpan.MaxValue; 

ChannelFactory<IDatabaseSession> pipeFactory = new ChannelFactory<IDatabaseSession>(binding, new EndpointAddress("net.pipe://localhost/DatabaseService")); 

IDatabaseSession dbSession = pipeFactory.CreateChannel() 

ogni cliente comincio esegue il codice di cui sopra, e per ogni cliente l'utilizzo della CPU aumenta del 25% (in realtà non per il cliente 5., ma a questo punto l'execteable servizio copre quasi un 100 % dell'intera capacità della CPU).

Quello che sto cercando è un tipo di risorsa (sito Web/elenco o solo la TUA conoscenza potente) che mi dice cosa effettivamente fa CreateChannel (riguardo ai problemi di allocazione delle risorse).

suggerimento: l'utilizzo della CPU aumenta anche se non viene effettivamente effettuata alcuna comunicazione, viene creato solo il canale.

Answer 1

È improbabile che la stessa WCF stia utilizzando molte risorse, soprattutto perché hai detto che questo accade anche quando non c'è comunicazione. La mia ipotesi è che si tratta di un problema con il servizio e non con i clienti. Guarda il costruttore di servizi se ne hai uno. Sperimentare anche con diversi valori di InstanceContextMode e ConcurrencyMode.

Answer 2

Mettere in pausa il debugger e vedere dove si sono fermati tutti i thread. Questa è probabilmente la parte più calda del tuo codice. Guarda lo stack delle chiamate.