12

Ich habe Probleme, dass der/Connect/Introspect Endpunkt meines IdentityServer manchmal sehr langsam ist (10 Sekunden für einen Anruf). Wie Sie unten sehen können, sind die meisten Anrufe (18k) schnell (< 250ms).Profiler BLOCKED_TIME in IdentityServer4/Newtonsoft.Json

Overview of request performance

Ich habe die neue Application Insights profiling aktiviert und die meisten der langsamen Spuren wie folgt aussehen:

Profiler trace of a slow operation

Wie gesagt auf dem Application Insights profiler page:

BLOCKED_TIME zeigt die Code wartet auf eine andere Ressource zu verfügbar sein, s Sie warten auf ein Synchronisationsobjekt, warten auf , damit ein Thread verfügbar ist, oder auf das Ende einer Anfrage.

Aber ich habe keinen Grund zu glauben, dass dies auf etwas warten sollte. Es gibt keine Spitzen an Anfragen, also glaube ich nicht, dass nicht genug Threads verfügbar sind oder so. Speicher scheint kein Problem für unseren App-Service-Plan zu sein, da er immer rund 40% beträgt. Ich habe auch in die Quelle von IdentityServer4 gegraben, konnte aber keine Ursache dafür identifizieren. Jetzt bin ich irgendwie festgefahren. Kann mir jemand auf mögliche Ursachen für diese langsamen Anfragen hinweisen? Oder weisen Sie mich in die gute Richtung, um eine Ursache zu bestimmen? Jede Hilfe wird sehr geschätzt!

Mit ein paar zusätzlichen Informationen bearbeiten: Wir verwenden IdentityServer4.EntityFramework, um Referenz-Token in einer SQL Azure-Datenbank zu speichern. Ich habe in Application Insights gesucht und die Abfragen in diesen langsamen Anforderungen in weniger als 50 ms durchgeführt. Also ich vermute, es ist nicht die Datenbank.

+0

Können Sie die Anrufanzahl sowie die in diesem Profilergebnis benötigte Zeit anzeigen? – dbc

+0

Ich sehe keine Option, um Anrufzählungen anzuzeigen, aber ich denke, es wäre nicht viel, da es das Token nur einmal serialisieren würde. – Zenuka

Antwort

2

Schauen Sie sich die Info an, alle Ihre Anfragen sind um 3222 ms, bis Sie beginnen, Ihre JSON zu serialisieren. Wenn Sie beginnen, Ihre Daten zu json JSON zu serialisieren, springt die Anfrage auf 5589 ms, beim Deserialisieren springt sie auf 8811ms.

Das Problem hier ist nicht die DB, die DB könnte die Daten schnell genug bekommen. Nicht die Spitze in der Anfrage, die Sie nicht haben, noch das Speicherproblem, das nicht existiert.

Das Problem ist die Tatsache, dass Sie eine Menge Daten abrufen, vermutlich und der Compiler hat seine Strafe beim Serialisieren und Deserialisieren der Daten, beide dieser Aktionen sind ziemlich teuer.

Sie müssen Ihre Liste als JSON anordnen und dann in ein Objekt deserialisieren, auf das Sie wieder zugreifen können.

Sehen Sie, was zwischen diesen Aufrufen passiert, die Menge der Daten, die Sie serialisieren und deserialisieren und was danach passiert.

Das ist Ihr Schlüssel.

+0

Ich habe den größten Token in der Datenbank nachgeschlagen und ihn 100 Mal serialisiert und der Durchschnitt (für die Gesamtzahl von 100 Serialisierungen) liegt bei 100ms. Also sehe ich nicht, wie das das Problem sein könnte. Das größte Token ist 33581 Zeichen lang. Fehle ich etwas in deiner Antwort? Serialisierung und Deserialisierung sollten synchron sein, oder? Das erklärt nicht die blockierte Zeit richtig? – Zenuka