Skalierung eines WCF-Dienstes, der Http-Aufrufe tätigt

Question

Ich habe einen WCF-Dienst in IIS gehostet, die ein Adapter für verschiedene ThirdParty APIs ist. Alles was dieser Dienst tut ist: - einen synchronen Operationsaufruf von der GUI akzeptieren - eine synchrone Http-Anfrage an einen Drittanbieter senden - Konvertierung des Ergebnisses in ein kanonisches Format - Rückkehr zur GUI

In der Praxis verbringt er die meiste Zeit damit, auf den Abschluss der Netzwerk-Eingabe/Ausgabe zu warten. Was ist das beste Muster, um einen solchen Dienst zu skalieren und gleichzeitig eine synchrone Schnittstelle für die grafische Benutzeroberfläche zu erhalten? Ich weiß, dass für ASP.NET-Anwendungen, die eine Menge von i/o haben es wird empfohlen, async-Handler zu verwenden, um den Thread ausführen Anforderung freizugeben.

Gibt es ein gutes Muster für WCF?

Danke, Piotr

Answer 1

Wie Sie beschrieben haben, ist dies ein potenzielles Problem der Skalierbarkeit.

ASP.NET verfügt über einen Thread-Pool, der (als ich das letzte Mal nachgesehen habe, waren es 250, aber er kann sich auf bis zu 1000 erhöhen - konfigurierbar, aber über 1000 nicht wirklich empfehlenswert) Anfragen bedient. HTTP-Anfragen in ASP.NET haben thread-affin Es besteht also eine Eins-zu-Eins-Beziehung zwischen diesen Threads und den Anfragen.

Wenn Sie externe Dienste aufrufen, bleibt der Anfrage-Thread hängen, und wenn Sie keine Threads mehr haben, erhält Ihr Client einen 503-Fehler.

Lösung für die Skalierung dieses Dienstes würde normalerweise eine Anfrage des Kunden an Start die Operation und dann würde der Client kontinuierlich Umfrage den Dienst, um zu sehen, ob er beendet ist. Wenn Sie diese Dienste als leichtgewichtig und effizient implementieren, Sie verlieren ein wenig an Leistung, gewinnen aber so viel Skalierbarkeit .

Sie müssen auch darüber nachdenken:

• Speichern des Ergebnisses, damit der Kunde es abrufen kann.
• Verwerfen des Ergebnisses, wenn der Client nicht zum Server zurückkehrt, um das Ergebnis zu erhalten.

Answer 2

Ich bin auf dieses "AsyncPattern" gestoßen, das möglicherweise die Lösung für dieses Problem ist ( http://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.asyncpattern.aspx )

Es sieht nach einer Möglichkeit aus, den Dienst-Thread "freizugeben", während er auf den Abschluss der E/A wartet, und gleichzeitig die synchrone Natur des Vorgangs aus Sicht des Aufrufers zu erhalten (d. h. dies ist ein rein dienstseitiges Implementierungsdetail). Der Nachteil scheint die Code-Komplexität auf der Dienstseite zu sein: alle externen Aufrufe müssen die Begin/End-API verwenden.

Einige nützliche Links: Was ist die Verwendung der Eigenschaft "AsyncPattern" von "OperationContractAttribute" + wcf? WCF - AsyncPattern Leistung http://blogs.msdn.com/b/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx