Verwendet WCF das ThreadPool, um neue Instanzen für einen PerCall-Dienst aufzurufen?

Question

für einen PerCall WCF-Dienst, dessen Drosselung auf einen hohen Wert gesetzt wurde (z. B. max. 200 gleichzeitige Aufrufe), würde WCF eine neue Instanz aufrufen und die Anforderung für einen Threadpool-Thread aufrufen?

Wenn dies der Fall ist, hat dies Auswirkungen auf die Gesamtzahl der gleichzeitig zulässigen Anrufe?

Ich frage, weil ich nie die maximale Anzahl von gleichzeitigen Anrufen, die ich in der Dienstdrosselungskonfiguration festgelegt habe, aber stattdessen einen Bruchteil dieser Anzahl - bis zu 50 bei einer 100 MaxConcurrentCalls Einstellung und 160 auf einem 200 MaxConcurrentCalls Einstellung.

Danke,

Answer 1

Es scheint, dass WCF I/O-Threads aus dem CLR Threadpool auf Service-Anfragen mit dem zusätzlichen Vorbehalt verwaltet verwendet, die einen eigenen Thread Scheduler verwendet.

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

Zu allererst WCF verwendet verwaltete I/O-Threads Anfragen zu bearbeiten. Der CLR-ThreadPool verhindert, dass eine bestimmte Anzahl von Leerlauf-E/A-Threads zerstört wird. Wenn mehr E/A-Threads benötigt werden, werden sie vom ThreadPool erstellt, was ziemlich teuer ist.

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

In .NET 3.0 und 3.5, gibt es ein spezielles Verhalten, das Sie für IIS gehostete WCF-Dienste beobachten würde. Wenn eine Anforderung eingeht, verwendet das System zwei Threads, um die Anforderung zu verarbeiten: Ein Thread ist der CLR-ThreadPool-Thread, bei dem es sich um den aus ASP.NET stammenden Worker-Thread handelt. Ein anderer Thread ist ein E/A-Thread, der von WCF IOThreadScheduler verwaltet wird (tatsächlich erstellt von ThreadPool.UnsafeQueueNativeOverlapped).

Es gibt eine Vielzahl von Einstellungen, die zum WCF-Durchsatz beitragen. Da WCF den verwalteten ThreadPool verwendet, wirken sich die MinIOThreads- und MaxIOThreads-Einstellungen des ThreadPools auf das Ergebnis aus. Nachdem alle nicht benötigten I/O-Threads (oder Worker-Threads, wenn Sie diese verwendet haben) aus dem ThreadPool übernommen wurden, wird der ThreadPool für eine gewisse Zeit verzögert, bevor ein neuer Thread zum Bedienen einer in der Warteschlange befindlichen Anfrage gestartet wird. Durch Erhöhen von MinIOThreads können Sie diese Verzögerung verhindern. Wenn Sie das MaxIOThread-Limit erreichen, würde dies sicherlich die Anzahl gleichzeitiger Anfragen begrenzen, die Sie sehen würden. Dies scheint jedoch in Ihrem 50/100-Test nicht der Fall zu sein, da Ihr nächster Test 160 gleichzeitige Anfragen ausführen konnte. Wenn ich mich richtig erinnere, glaube ich, dass die von Ihnen verwendete Hosting-Umgebung (IIS, WAS, self) einige der ThreadPool-Einstellungen diktieren kann. Wenn Sie den Blogbeitrag von der zweiten Verknüpfung lesen, sehen Sie außerdem, wie IIS-Arbeitsthreads blockiert werden, wenn WCF eine Anforderung für seinen separaten E/A-Thread verarbeitet. In diesem Fall wirken sich die Worker-Thread-Einstellungen und IIS-Einstellungen auf die WCF-Parallelität aus. Wie hosten Sie diesen Service?

Ihr Titel erwähnt einen PerCall InstanceContextMode, der den ConcurrencyMode irrelevant macht. Mit PerCall müssen Sie jedoch die MaxConcurrentInstances-Einstellung sowie die MaxConcurrentCalls beachten. Abhängig von Ihrer Bindung müssen Sie möglicherweise auch mit der MaxConcurrentSessions-Eigenschaft befasst sein. Welche Bindung verwenden Sie, um diesen Service zu hosten?

Unabhängig von all dem, was verblüffend ist, ist der 160/200 Test, der Ihrem 50/100 Test folgte.