Профайлер BLOCKED_TIME в IdentityServer4/Newtonsoft.Json

У меня возникают проблемы с конечной точкой /connect/introspect моего IdentityServer, иногда очень медленной (10 секунд для одного вызова). Как вы можете видеть ниже, большинство вызовов (18k) выполняются быстро (< 250 мс).

Обзор производительности запроса

Я включил новый профиль профайла приложений, и большинство медленных трасс выглядит следующим образом:

Трассировка профайлера медленной операции

Как сказано на странице "Статистика профайлов приложений" :

BLOCKED_TIME указывает, что код ожидает другого ресурса быть доступным, например, ждать объекта синхронизации, ждать для того, чтобы поток был доступен или ожидал завершения запроса.

Но у меня нет причин полагать, что это должно что-то ждать. В запросах нет всплесков, поэтому я не думаю, что доступных потоков нет или что-то еще. Память, по-видимому, не проблема для нашего плана обслуживания приложений, поскольку она всегда составляет около 40%. Я также выкопал источник IdentityServer4, но не смог определить причину этого. Так что теперь я застрял. Может ли кто-нибудь указать мне на возможные причины этих медленных запросов? Или указать мне в правильном направлении, чтобы определить причину? Любая помощь будет высоко оценена!

Изменить с дополнительной информацией: мы используем IdentityServer4.EntityFramework для хранения токенов ссылок в sql azure db. Я просмотрел Application Insights, и запросы в этих медленных запросах выполняются менее чем за 50 мс. Поэтому я предполагаю, что это не база данных.

Ответы

Ответ 1

Посмотрите на информацию. Все ваши запросы составляют около 3222 мс, пока вы не начнете сериализовать свой JSON. Когда вы начинаете сериализовать свои данные в json JSON, запрос перескакивает до 5589 мс, когда вы десериализуете его, он перескакивает до 8811мс.

Проблема здесь не в БД, БД может получить данные достаточно быстро. Не всплеск в запросе, которого у вас нет, или проблема с памятью, которая не существует.

Проблема заключается в том, что вы извлекаете много данных, предположительно, и у компилятора есть штраф при сериализации и десериализации данных, причем оба этих действия довольно дорогостоящие.

Вы должны упорядочить свой список как JSON, а затем десериализовать его в объект, к которому вы можете получить доступ снова.

Посмотрите, что происходит между этими вызовами, количеством данных, которые вы сериализуете и десериализуете, и что происходит после.

Это ваш ключ.