WCF - Zufälliger Client-Timeout bei mehreren Anrufen
Ich habe einen WPF -Kunden, der Daten über WCF -Dienst in IIS 7 anfordert. Die Service-Methode ruft eine gespeicherte Prozedur ( SQL 2012 ) mit EF auf, um einige Daten abzurufen.
Es gibt eine Menge zu ladender Daten, so dass der Client mehrere Aufrufe an die Service-Methode macht, um das Laden der Daten "aufzulösen" und große Payloads und Timeouts zu vermeiden.
Wir verwenden die generierten Service-Proxies, die von System.ServiceModel.ClientBase<T>.
Wir verwenden auch eine benutzerdefinierte HTTP-Bindung mit binärer Codierung (aus hier ) ) - tatsächliche Umsetzung hier gezeigt:
%Vor%
Außerdem ist die dynamische Komprimierung in IIS aktiviert. Ich kann die Anfragen in Fiddler anzeigen, und die Größe des Nachrichtentexts ist in Ordnung (~ 50KB) und 99% der Anfragen werden in einer Sekunde oder zwei zurückgegeben. Perfekt!
Allerdings gibt es bei fast jeder Iteration einen Anruf im Bündel, der Minuten in Anspruch nimmt, und ich weiß nicht warum ... Mein sendTimeOut auf dem Client war bei 1 Minute und natürlich würde dieser Anruf auch erfolgen Scheitern. Ich habe es auf 10 Minuten verlängert, und der Anruf scheint in etwas mehr als 2 Minuten abgeschlossen zu sein - obwohl es manchmal noch länger dauern würde. Das Problem erscheint sehr zufällig - es könnte der erste Anruf sein, es könnte der 30. Anruf sein. Aber es ist sehr reproduzierbar.
Ich habe eine Protokollierung um den Aufruf der gespeicherten Prozedur in der WCF-Servicemethode vorgenommen und führt sie aus und ruft Daten unter einer Sekunde zurück. Also, ich denke nicht, dass es ein Datenbankproblem ist.
Mit Fiddler erzeugt der problematische Aufruf eine Ausgabe ähnlich der folgenden:
%Vor% Beachten Sie die signifikante Zeit zwischen ServerBeginResponse und GotResponseHeaders . Dies scheint auffallend ähnlich zu dem hier .
Ich habe WCF Service Tracing aktiviert, und auf den ersten Blick gibt es keine Fehler oder Warnungen, aber ich kann nicht wirklich viel Sinn aus dem machen, was ich über die Grundlagen hinaus ansehe.
Wie kann ich herausfinden, wo und wo das Problem liegt? Ist es Serialisierung? Ist es ein Netzwerkproblem? Kann der Server nicht mithalten, dass der Client so viele Anfragen sendet?
Ich habe versucht, die WCF-Drosselung in der Konfigurationsdatei anzupassen, indem ich die entsprechende serviceBehaviors hinzufüge, aber das hat keinen Unterschied gemacht.
Ich sollte erwähnen, dass ich dies über eine VPN-Verbindung mache, aber andere Dinge wie Dateiübertragungen, Remote-Desktop-Verbindungen funktionieren gut. Es scheint ziemlich zuverlässig.
Ich kann bei Bedarf weitere Details angeben.
Bearbeiten (6.10.2013): Nicht sicher, ob das verwandt ist oder nur ein Zufall, aber ein paar Mal habe ich bemerkt, dass die Körpergröße beim problematischen Anruf deutlich geringer ist als die Anderen. Dies ist nicht immer der Fall, aber es kann Hinweise geben. Hier ist eine Bildschirmaufnahme von Fiddler, um Ihnen zu zeigen, wie konsistent die Körpergröße bei jedem Anruf sein sollte. Der ausgewählte Eintrag (# 21) ist viel kleiner als die anderen, dauert jedoch mehr als 2 Minuten.
Seltsamerweise habe ich diesmal eine Ausnahme erhalten. Die Ausnahme passiert nicht jedes Mal.
%Vor%2 Antworten
Wie ich in den Kommentaren vorgeschlagen habe, versuchen Sie bitte, den Transfermodus auf "streamed" zu setzen, um auszuschließen, dass dies ein Problem im Zusammenhang mit dem Speicherdruck ist (da der stream mode dazu führen sollte, dass weniger Speicherplatz benötigt wird).
Als ich dieses Problem vermutete, könnte dies das Problem sein, denn es scheint Ihnen nur zu passieren, wenn Sie viele Serviceanrufe in schneller Folge machen. Nach meiner Erfahrung ist dies oft eines von zwei Problemen: Entweder werden die Proxies vom Client nicht ordnungsgemäß geschlossen, oder der Server führt wegen Speicherdruck GCs aus.
Wenn der Transfermodus gepuffert ist, lädt WCF das gesamte Dataset für die Nachrichtenantwort in den Speicher, bevor es an den Client zurückgesendet wird. Gestreamt sendet einfach die Daten ohne Pufferung zurück. Bei großen Datenmengen ist es meist sehr viel schneller, bei kleinen Datenmengen etwas langsamer und benötigt immer weniger Speicher (sowohl auf dem Server als auch auf dem Client).
Um herauszufinden, was Ihre Timeouts verursacht, sollten Sie verfolgen, was in WCF vor sich geht. Wenn Sie Ihren Konfigurationsdateien Folgendes hinzufügen, wird auf Ihrem Client und Server eine Trace-Datei generiert:
%Vor%Normalerweise wird Ihnen die Datei genau sagen, was vor sich geht und was nicht. Stellen Sie sicher, dass Sie über das Verzeichnis C: \ logs verfügen und der Benutzer Schreibrechte für das Verzeichnis hat.