12

我遇到的问题是,我的IdentityServer的/ connect/introspect端点有时非常慢(一次调用10秒)。正如您在下面看到的,大多数呼叫(18k)执行得很快(< 250ms)。ProfileServer BLOCKED_TIME在IdentityServer4/Newtonsoft.Json

Overview of request performance

我已经启用新的Application Insights profiling,最慢的痕迹看起来像这样:

Profiler trace of a slow operation

由于在Application Insights profiler page说:

BLOCKED_TIME指示代码正在等待另一个资源 可用,s如等待同步对象,等待 使线程可用,或等待请求完成。

但我没有理由相信这应该在等待什么。请求没有秒杀,所以我不认为没有足够的线程可用或什么。对我们的应用服务计划来说,内存似乎没有问题,因为它总是在40%左右。我也挖掘了IdentityServer4的来源,但无法找到任何原因。所以现在我有点卡住了。任何人都可以指出我对这些缓慢请求的可能原因吗?或者指出我确定一个原因的好方向?任何帮助都感激不尽!

用一些额外的信息编辑:我们使用IdentityServer4.EntityFramework来将参考标记存储在一个sql azure数据库中。我查看了Application Insights,那些慢速请求中的查询在50ms以内执行。所以我猜这不是数据库。

+0

你可以显示呼叫计数以及该配置文件结果中所用的时间吗? – dbc

+0

我没有看到显示调用计数的选项,但我猜它不会太多,因为它只会序列化一次令牌。 – Zenuka

回答

2

查看信息,您的所有请求都在3222毫秒左右,直到您开始序列化您的JSON。 当你开始将你的数据序列化到JSON JSON时,请求跳转到5589毫秒,当你反序列化它时,它跳转到8811毫秒。

这里的问题不是数据库,数据库可能会获得足够快的数据。不是请求中的尖峰,你没有,也不存在不存在的内存问题。

问题是,您正在获取大量数据,据推测,编译器在序列化和反序列化数据时会受到惩罚,这两个操作都非常昂贵。

您必须将您的列表安排为JSON,然后将其反序列化为可以再次访问的对象。

看看这些调用之间会发生什么,您正在序列化和反序列化的数据量以及之后会发生什么。

这是你的钥匙。

+0

我查了数据库中最大的令牌,并将其序列化了100次,平均值(总共100次序列化)大约为100ms。所以我不明白这可能是什么问题。最大的代表是33581个字符。我在你的回答中遗漏了什么?序列化和反序列化应该是同步的吗?这并不能解释被阻止的时间是正确的吗? – Zenuka