Tut WCF verwenden den ThreadPool, um neue Instanzen für eine PerCall service?

für eine PerCall WCF-Dienst, dessen Drosselung festgelegt wurde, zu hoch sein (sagen wir, 200 max concurrent calls) wäre WCF eine neue Instanz und ruft die Anfrage auf einem threadpool-thread?

Wenn es funktioniert, dann hat dies Auswirkungen auf die Anzahl der gleichzeitigen Anrufe erlaubt?

Ich Frage, weil ich nicht scheinen, um jemals treffen Sie die maximale Anzahl der gleichzeitigen Anrufe, habe ich in der service-Drosselung config, aber statt mit einem Bruchteil dieser Anzahl - bis zu 50 auf 100 Einstellung und 160 auf 200-Einstellung.

Dank,

  • Soweit ich weiß, WCF verwendet einen separaten pool von threads, die für seine Anforderungen. Es nicht, Tippen Sie in den "normalen" .NET-ThreadPool.
InformationsquelleAutor theburningmonk | 2010-05-14
  1. 17

    Scheint es, dass die WCF verwendet verwalteten I/O-threads, die von der CLR-ThreadPool-service-Anfragen-mit der zusätzlichen Einschränkung, dass ist, verwendet einen eigenen thread scheduler.

    Vom Wenlong Dong ' s Blog - Warum Sind WCF Antworten Langsam und SetMinThreads Nicht Funktioniert?

    Zunächst WCF verwendet verwalteten I/O-threads, um Anfragen zu Bearbeiten. Der CLR-ThreadPool-hält eine bestimmte Anzahl von Leerlauf-I/O-threads zerstört wird. Wenn mehr I/O-threads benötigt werden, Sie sind erstellt von der ThreadPool, die ist etwas teuer.

    Vom Wenlong Dong ' s Blog : WCF-anforderungsdrosselung und serverskalierbarkeit

    In .NET 3.0 und 3.5 gibt es eine spezielle Verhalten, das Sie beobachten würden für IIS gehostete WCF-Dienste. Wenn eine Anfrage eingeht, wird das system verwendet zwei threads, die Anforderung zu verarbeiten: Ein thread ist der CLR-ThreadPool-thread, das ist der worker-thread, der kommt aus ASP.NET. Einem anderen thread ist ein I/O thread, der verwaltet wird durch die WCF-IOThreadScheduler (eigentlich erstellt von ThreadPool.UnsafeQueueNativeOverlapped).

    Gibt es eine fülle von Einstellungen, die Faktor in WCF-Durchsatz. Da WCF verwendet die verwalteten ThreadPool, der ThreadPool MinIOThreads und MaxIOThreads werden die Einstellungen auf das Ergebnis auswirken. Nach all Leerlauf I/O-threads (oder worker-threads, wenn Sie wurden mit diesen) sind aus dem ThreadPool, der ThreadPool-Verzögerung für einen Zeitraum vor dem drehen einen neuen thread, um eine Anfrage in der Warteschlange. Durch die Erhöhung MinIOThreads, können Sie verhindern, dass diese Verzögerung. Wenn Sie auf die MaxIOThread limit, das wäre sicherlich Obergrenze für die Anzahl der gleichzeitigen Anfragen, die Sie sehen würden; aber dies scheint nicht der Fall zu sein, in Ihrem 50/100 test, da Ihre nächste test geschafft, 160 gleichzeitige Anfragen ausführen. Wenn ich mich Recht erinnere, glaube ich, dass die hosting-Umgebung (IIS, WAR, selbst) diktieren können einige der ThreadPool-Einstellungen. Auch, wenn Sie Lesen Sie den blog-post aus dem zweiten link sehen Sie, wie Sie IIS worker-threads werden blockiert, wenn der WCF ist die Verarbeitung einer Anforderung auf seine separate I/O-thread. Also in diesem Fall, worker-thread-Einstellungen und IIS-Einstellungen haben eine Auswirkung auf die WCF-Parallelität. Wie hosten Sie diesen service?

    Ihrem Titel erwähnt, ein PerCall InstanceContextMode, die den ConcurrencyMode irrelevant. Jedoch, mit PerCall Sie müssen sich bewusst sein, der MaxConcurrentInstances Einstellung sowie die MaxConcurrentCalls. Je nach Bindung, Sie kann auch notwendig sein, die sich mit der MaxConcurrentSessions Eigenschaft. Welche Bindung Sie zu diesem host Dienst?

    Unabhängig von allen oben genannten, was verwirrend ist, ist die 160/200 test, die folgte Ihr 50/100 test.

    InformationsquelleAutor Dan Terry
Schreibe einen Kommentar