WCF utilizza il ThreadPool per richiamare nuove istanze per un servizio PerCall?

Question

per un servizio WCF PerCall la cui limitazione è stata impostata su un valore elevato (ad esempio, 200 chiamate simultanee massime) WCF visualizza una nuova istanza e richiama la richiesta su un thread del threadpool?

In caso affermativo, ciò ha un impatto sul numero totale di chiamate simultanee consentite?

Chiedo perché non sembra che abbia mai raggiunto il numero massimo di chiamate simultanee impostate nel servizio di limitazione della configurazione ma invece una frazione di quel numero - fino a 50 su 100 Impostazioni di MaxConcurrentCalls e 160 su un 200 impostazioni MaxConcurrentCalls.

Grazie,

Answer 1

Sembra che WCF utilizza riuscito di I/O discussioni dal CLR ThreadPool alle richieste di servizio con l'avvertenza supplementare che è utilizza il proprio scheduler thread.

Da Wenlong Dong's Blog - Why Are WCF Responses Slow and SetMinThreads Does Not Work?

Prima di tutto, WCF utilizza gestita I fili/O per gestire le richieste. Il ThreadPool CLR mantiene un certo numero di thread I/O inattivi da distruggere. Quando sono necessari più thread I/O, vengono creati dal ThreadPool, che è piuttosto costoso.

Da Wenlong Dong's Blog : WCF Request Throttling and Server Scalability

In .NET 3.0 e 3.5, non v'è un comportamento speciale che si osserva per i servizi WCF IIS-hosted. Ogni volta che arriva una richiesta, il sistema utilizza due thread per elaborare la richiesta: un thread è il thread CLR ThreadPool, che è il thread di lavoro proveniente da ASP.NET. Un altro thread è un thread I/O gestito da WCF IOThreadScheduler (effettivamente creato da ThreadPool.UnsafeQueueNativeOverlapped).

Ci sono una miriade di impostazioni che influiscono sul rendimento della WCF. Perché WCF utilizza il ThreadPool gestito, le impostazioni MinIOThreads e MaxIOThreads del ThreadPool influiranno sul risultato. Dopo che tutti i thread I/O inattivi (o i thread di lavoro se si stavano utilizzando quelli) sono presi dal ThreadPool, il ThreadPool verrà ritardato per un periodo di tempo prima di generare un nuovo thread per soddisfare una richiesta in coda. Aumentando MinIOThreads, puoi evitare questo ritardo. Se stai colpendo il limite di MaxIOThread, questo potrebbe sicuramente limitare il numero di richieste concorrenti che vedresti; tuttavia, questo non sembra essere il caso nel test 50/100 perché il test successivo è riuscito a ottenere 160 richieste simultanee in esecuzione. Se ricordo correttamente, credo che l'ambiente di hosting che usi (IIS, WAS, self) possa dettare alcune delle impostazioni di ThreadPool. Inoltre, se si legge il post del blog dal secondo collegamento, verrà visualizzato il modo in cui i thread di lavoro IIS vengono bloccati quando WCF elabora una richiesta sul relativo thread I/O separato. In questo caso, le impostazioni del thread di lavoro e le impostazioni di IIS avranno un effetto sulla concorrenza WCF. Come stai ospitando questo servizio?

Il titolo cita un PerCall InstanceContextMode che renderà irrilevante il ConcurrencyMode. Tuttavia, con PerCall è necessario conoscere l'impostazione MaxConcurrentInstances e MaxConcurrentCalls. A seconda dell'associazione, potrebbe essere necessario occuparsi anche della proprietà MaxConcurrentSessions. Che legame stai usando per ospitare questo servizio?

Indipendentemente da quanto sopra, ciò che lascia perplessi è il test 160/200 che ha seguito il test 50/100.