Prestazioni di WCF con net.tcp

Question

Ho un servizio WC.Net.tcp ospitato con il ServiceHost incorporato e quando eseguo alcuni test di stress ottengo uno strano comportamento. La prima volta che invio una serie di richieste, vengono risposte rapidamente da 5 a 10 richieste e il resto restituisce a intervalli di circa 2 secondi. La seconda volta che invio le richieste, 10 - 20 vengono restituite rapidamente e riposano con 2 intervalli di sencond.

Le ripetizioni sopra riportate consentono di ottenere oltre 100 richieste restituite rapidamente, ma se aspetto circa un minuto l'utilizzo della memoria del servizio diminuisce e le richieste tornano indietro a 5-10.

Il servizio che sto testando ha un piccolo ritardo, in modo da poter ottenere molte connessioni aperte allo stesso tempo, se questo ritardo viene rimosso le richieste ritornano così velocemente che ho forse 2-5 connessioni aperte allo stesso tempo . Questo ritardo è quello di simulare le connessioni DB e altre cose in uscita.

Dal comportamento sembra che ServiceHost stia allocando qualcosa, thread, istanze di classe, ma non riesco a capire di cosa si tratta.

Potrei avere un timer nel client che chiama il servizio per mantenerlo funzionante, ma sembra una cattiva soluzione.

Se ho un carico elevato sul servizio, il sistema scricchierà tutte le richieste rapidamente, ma se ho un periodo di bassa attività e quindi si verifica un aumento delle connessioni il servizio sarà lento.

Suppongo che la mia domanda sia: COSA è l'allocazione ottenuta durante il carico elevato del servizio WCF e COME posso configurare il servizio per preallocare più delle cose che vengono allocate.

EDIT: ho fatto un po 'di test, e guardando il taskmgr per il processo che posso vedere che quando la ServiceHost è 'riposando' ci sono 10 le discussioni aperte, ma quando inizio l'invio di richieste, il threadcount sale. Finché il threadcount è alto, il servicehost può elaborare rapidamente le richieste in arrivo, ma se sospetto l'invio delle richieste, il threadcount aperto diminuisce e le richieste successive iniziano a richiedere più tempo per l'elaborazione.

Ora, come posso dire al servicehost di mantenere aperto un gruppo di thread? O più del 10-12 che mantiene di default?

Answer 1

La cosa che determina come possono essere gestite le richieste simultanee è ServiceThrottlingBehavior. Esistono diverse serie di minacce che limiteranno la quantità di richieste elaborate. Ciò dipende anche dal legame che stai usando, per esempio wsHttpBinding fa riferimento alle sessioni on mentre basicHttpBinding non usa sessioni e il limite di sessione predefinito di 10 non è un problema.

Vedere http://msdn.microsoft.com/en-us/library/ms735114.aspx per ulteriori dettagli.

Answer 2

Bene, dopo un sacco di google, sembra che il problema è il threadpool. Il threadpool CLR assegna alcuni thread e, quando vengono utilizzati, riduce la creazione di nuovi thread e, dopo un po ', rilascia anche i thread inutilizzati.

C'è una certa confusione riguardo a un bug che significa che ThreadPool non ha rispettato la chiamata SetMinThreads.

http://www.michaelckennedy.net/blog/PermaLink,guid,708ee9c0-a1fd-46e5-8fa0-b1894ad6ce0f.aspx

io non sono sicuro se questo bug è risolto, o che cosa, perché quando modifico le impostazioni ThreadPool, il problema persiste.

Answer 3

Il bug a cui si fa riferimento è stato risolto in .NET 3.5 SP1.Questo potrebbe aver avuto qualcosa a che fare con il problema, penso che sia più probabile (molto più probabile) che il throttling sia il tuo problema piuttosto che il filo conduttore di Maurice.

<system.serviceModel> 
    <service name="???" > 
    <endpoint ... /> 
    </service> 
</system.serviceModel> 

Qual è il limite di throttle per questa configurazione "vuota"? 10 sessioni, 16 chiamate simultanee! Attenzione.

Ecco più su filettatura: http://www.michaelckennedy.net/blog/2008/08/20/ThreadPoolBugInNET20SP1IsFixed.aspx

Answer 4

Questo si sente come un hack, ma sembra risolvere il problema. Il problema è che il threadpool impiegherà del tempo per avviare un nuovo thread, quindi quello di cui hai veramente bisogno sono i thread in attesa sullo standby. Aggiungi un costruttore al tuo servizio e imposta il numero minimo di thread che desideri.

public YourService() 
    { 
     int workerThreads; 
     int portThreads; 
     ThreadPool.GetMinThreads(out workerThreads, out portThreads); 
     ThreadPool.SetMinThreads(200, portThreads); 
    }