Profiler BLOCKED_TIME w IdentityServer4/Newtonsoft.Json

Question

Mam problemy, że punkt końcowy/connect/introspect mojego serwera tożsamości jest czasami bardzo wolny (10 sekund na jedno połączenie). Jak widać poniżej, większość połączeń (18k) działa szybko (< 250ms).

mam włączony nowy Application Insights profiling i większość powolnych śladów wyglądać następująco:

Jak powiedział na Application Insights profiler page:

BLOCKED_TIME wskazuje kod czeka na inny zasób do być dostępny, s ucha oczekującego na obiekt synchronizacji, oczekujący , aby wątek był dostępny lub oczekiwanie na zakończenie żądania.

Ale nie mam powodu, aby sądzić, że to powinno na coś czekać. Nie ma spodziewanych żądań, więc nie sądzę, że nie ma wystarczającej liczby wątków lub czegoś takiego. Pamięć nie jest problemem w naszym planie usług aplikacji, ponieważ zawsze wynosi około 40%. Również wykopałem źródło IdentityServer4, ale nie mogłem zidentyfikować żadnej przyczyny tego. Więc teraz utknąłem. Czy ktoś może wskazać mi możliwe przyczyny tych powolnych wniosków? Lub wskazać mi w dobrym kierunku, aby ustalić przyczynę? Każda pomoc będzie doceniona!

Edycja z dodatkowymi informacjami: używamy IdentityServer4.EntityFramework do przechowywania tokenów referencyjnych w bazie danych sql azure. Sprawdziłem Statystyki aplikacji, a zapytania w tych powolnych żądaniach wykonują w czasie krótszym niż 50 ms. Zgaduję, że to nie jest baza danych.

Answer 1

Spójrz na informacje, wszystkie twoje żądania wynoszą około 3222 ms, aż do rozpoczęcia serializowania JSON. Po rozpoczęciu serializowania danych do Json JSON żądanie przeskakuje do 5589 ms, po deserializacji przeskakuje do 8811ms.

Problem tutaj nie jest DB, DB może uzyskać wystarczająco szybko danych. Nie wzrost żądań, których nie masz, ani problem z pamięcią, który nie istnieje.

Problem polega na tym, że pobierasz dużo danych, prawdopodobnie i gdy kompilator ma swoją karę podczas serializowania i deserializacji danych, oba te działania są dość kosztowne.

Musisz uporządkować listę jako JSON, a następnie przekształcić ją w obiekt, do którego możesz uzyskać dostęp ponownie.

Zobacz, co dzieje się między tymi połączeniami, ilość danych, które serializujesz i deserializacji, i co dzieje się później.

To jest twój klucz.