Analysieren, warum WCF wesentlich langsamer ist als der WSE-Webservice
Wir haben einen Webdienst mit WSE 3.0-Endpunkten und den neueren WCF-Endpunkten unter .NET Framework 4.5.
WCF verwendet basicHttpBinding .
Das Problem ist, dass die neuen WCF-Bindungen deutlich langsamer (~ 3x) erscheinen . Verwendet es den gleichen Mechanismus unter der Haube?
Ich habe viel über das Aktivieren der WCF-Ablaufverfolgung gelesen. Aber wenn ich das bei der Produktion aktiviere, komme ich zu vielen Informationen und weiß nicht wirklich, wie z. die Zeitleiste in Microsoft Trace Viewer.
Ich würde jede Hilfe schätzen
- Tipps zum Auffinden von Ursachen für den Leistungsunterschied
- Idee von einem theoretischen Standpunkt, z. Gibt es große Unterschiede unter der Haube bei der Verarbeitung einer Anfrage durch WCF?
- Alle Tools, die beim Profilieren des WCF-Servers helfen können
Anmerkungen:
Das Problem besteht in der Produktion; Auf den Testservern geht alles fein. Zuerst haben wir vermutet, dass der Load Balancer ein Faktor sein könnte, Das Deaktivieren des Lastenausgleichs ändert jedoch die Leistung überhaupt nicht
Die Langsamkeit könnte natürlich auf unsere Anwendungs- / Domänenebene zurückzuführen sein. Vielleicht blockiert ein Thread / Verbindungspool und Nachrichten werden gesendet Schlange deswegen.
In diesem Fall hat jemand eine Idee, warum das Verhalten so ist unterscheidet sich von WSE (die auf dem gleichen Anwendungspool ausgeführt wird)? Hat irgendwas getan Warteschlangengrößen / gleichzeitige Verarbeitung Standardkonfigurationen ändern dramatisch zwischen WSE3.0 und WCF?
Gibt es eine Möglichkeit herauszufinden, wann das passiert? Z.B. einige
perfmon-Zähler zum Ansehen ? Inperfmonverliere ich einfach die Wahl zwischen der riesigen Anzahl verfügbarer Leistungsindikatoren
Aktualisieren
Hier ist eine anonymisierte Version unseres Dienstes Web.config:
%Vor%4 Antworten
Ihre Konfigurationsdatei für den WCF-Dienst scheint keine explizit festgelegten Einschränkungswerte zu enthalten. Vielleicht möchten Sie den Performance-Monitor verwenden, um die WCF-Ressourcen zu verfolgen und / oder die Standardwerte anzupassen, um sicherzustellen, dass Sie nicht das voreingestellte Gaslimit erreichen.
Mit der Dienstbeschränkung ( serviceThrottling ) können Sie die Belastung Ihrer Back-End-WCF-Server ausgleichen und die Ressourcenzuweisung erzwingen. serviceThrottling-Verhalten für Back-End-WCF-Dienste wird konfiguriert, indem die Werte für die Parameter maxConcurrentCalls , maxConcurrentSessions und maxConcurrentInstances in der Konfigurationsdatei für den WCF-Dienst geändert werden.
Die Verwendung von WCF-Diagnosen ist großartig, aber soweit ich weiß, können Sie keine ähnlichen Diagnosen vom Web-Service erhalten, so dass Sie nichts Vergleichbares haben. Die Diagnose, die Sie in Ihrer Antwort vorbereiten, gibt Ihnen jedoch einen Hinweis auf die relative Zeit, die in jeder Phase des Serviceaufrufs verbracht wird.
Ich werde eine Alternative vorschlagen, die sehr einfach sein sollte, da Sie in beiden Fällen http / text verwenden. Fangen Sie einfach beide Antworten mit Fiddler oder Ihrem bevorzugten Proxy-Tool ab und vergleichen Sie. Und kritisch - stellen Sie sicher, dass Sie auf den http-Header schauen, nicht nur auf den Körper. Fiddler wird dir die Umlaufzeit und die Größe der Antwort sagen, was genug sein sollte.
Was könnte das sein? Die offensichtlichen Dinge:
- Ich habe bei der Verwendung der Windows-Authentifizierung mit WCF einen enormen Leistungs-Overhead (ja, etwa 3x) erlebt. Ich habe gesehen, dass die Größe der Nachricht bei Verwendung der Windows-Authentifizierung aufgrund eines großen verschlüsselten Blobs in der Kopfzeile (aus dem Speicher) überspringt. Dies kostet viel Zeit in der Übertragung allein.
- Auch bei der Sicherheit wird die WCF-Anfrage verschlüsselt? Wenn Sie Nachrichtensicherheit verwenden, wird diese auf der Serverseite gepackt und auf der Clientseite entpackt. Dies ist auch nicht kostenlos.
- Mehrere Dienstinstanzen Sie sollten Ihren Service für mehrere Instanzen einrichten, dh jede Operation erstellt eine eigene Service-Instanz. Dies ist das Standardverhalten. Konfiguriert als Attribut für die Serviceklasse selbst, wie
[System.ServiceModel.ServiceBehavior(ConcurrencyMode = System.ServiceModel.ConcurrencyMode.Multiple)]
Sie haben Recht damit, dass es viele Leistungsindikatoren für WCF gibt. Sie sind nach Dienst, Endpunkt und Vorgang gruppiert. Sie möchten wahrscheinlich die Service-Zähler, da sie mehr Informationen haben. Überprüfen Sie die Kategorie ServiceModelService 4.0 und sehen Sie sich
- Anrufe (natürlich)
- Anrufe pro Sekunde
- Instanzen
- Instanzen pro Sekunde erstellt
Ich würde vorschlagen, dies auf folgende Weise zu debuggen:
-
Entfernen Sie vorübergehend alle Authentifizierungs- und Sicherheitslogik von beiden Diensten und prüfen Sie, ob das Problem weiterhin besteht
-
deaktivieren Sie vorübergehend jede Geschäftslogik und vereinfachen Sie das Schema möglicherweise auf eine einzelne Variable
-
Wenn Sie sagen, dass die Leistung langsamer ist, meinen Sie eine einzelne Benutzerleistung oder einen Auslastungstest? Wenn Sie einen einzelnen Benutzer überprüfen, stellen Sie sicher, dass der Server warm ist?
-
Wenn Sie die Ausführungsdauer Ihrer Logik (z. B. vom Anfang bis zum Ende der Implementierung Ihrer Servermethode) zeitlich anpassen - ist es dasselbe?
-
Vergessen Sie nicht, während des Benchmarking irgendwelche Protokollierung / Verfolgung zu löschen
-
Sie können versuchen, den WCF zu mit XmlSerializer
anstelle von DataContract
Entschuldigung für die Antwort, ich habe nicht genug Ruf für Kommentare.
Welche spezifischen Informationen (Spuren) möchten Sie sehen? Wenn Sie Schwierigkeiten beim Einrichten der Ablaufverfolgung haben, würde ich Ihnen das Tool namens SvcConfigEditor.exe empfehlen. Darin können Sie die App.Config-Datei Ihres WCF-Dienstes öffnen und unter "Diagnose" die Ablaufverfolgung aktivieren. Danach können Sie wählen, ob Sie bestimmte Informationen verfolgen möchten - so genannte "Trace-Level" (mehr Informationen über bestimmte Ebenen - Konfigurieren der Ablaufverfolgung ). Siehe Screenshot des Tools:
Nachdem Sie die erforderlichen Informationen verfolgt haben, können Sie das Protokoll in Microsoft Trace Viewer öffnen - darin können Sie die Dauer jeder Aktion ansehen: Betrachten Sie zum Beispiel dieses Beispiel (sorry - einige Bezeichnungen sind in tschechischer Sprache):
Leider konnte das Bild nicht gelesen werden, hier ist der Link zu einem größeren: Trace Viewer
Auf der linken Seite können Sie bestimmte Aktivitäten auswählen. Wenn Sie das Panel strecken, können Sie sogar die Start- und Endzeit sehen. Außerdem sehen Sie die Gesamtdauer dieser Aktivität. Nachdem Sie es ausgewählt haben, können Sie im oberen linken Bereich alle Anrufe sehen, die zu dieser Aktivität gehören, und Sie können auch sehen, welcher Anruf die meiste Zeit zum Auflösen benötigte (in der Spalte "Zeit").
Tags und Links wcf c# performance web-services wse