ProfileServer BLOCKED_TIME在IdentityServer4/Newtonsoft.Json
我遇到的问题是,我的IdentityServer的/ connect/introspect端点有时非常慢(一次调用10秒)。正如您在下面看到的,大多数呼叫(18k)执行得很快(< 250ms)。ProfileServer BLOCKED_TIME在IdentityServer4/Newtonsoft.Json
我已经启用新的Application Insights profiling,最慢的痕迹看起来像这样:
由于在Application Insights profiler page说:
BLOCKED_TIME
指示代码正在等待另一个资源 可用,s如等待同步对象,等待 使线程可用,或等待请求完成。
但我没有理由相信这应该在等待什么。请求没有秒杀,所以我不认为没有足够的线程可用或什么。对我们的应用服务计划来说,内存似乎没有问题,因为它总是在40%左右。我也挖掘了IdentityServer4的来源,但无法找到任何原因。所以现在我有点卡住了。任何人都可以指出我对这些缓慢请求的可能原因吗?或者指出我确定一个原因的好方向?任何帮助都感激不尽!
用一些额外的信息编辑:我们使用IdentityServer4.EntityFramework来将参考标记存储在一个sql azure数据库中。我查看了Application Insights,那些慢速请求中的查询在50ms以内执行。所以我猜这不是数据库。
查看信息,您的所有请求都在3222毫秒左右,直到您开始序列化您的JSON。 当你开始将你的数据序列化到JSON JSON时,请求跳转到5589毫秒,当你反序列化它时,它跳转到8811毫秒。
这里的问题不是数据库,数据库可能会获得足够快的数据。不是请求中的尖峰,你没有,也不存在不存在的内存问题。
问题是,您正在获取大量数据,据推测,编译器在序列化和反序列化数据时会受到惩罚,这两个操作都非常昂贵。
您必须将您的列表安排为JSON,然后将其反序列化为可以再次访问的对象。
看看这些调用之间会发生什么,您正在序列化和反序列化的数据量以及之后会发生什么。
这是你的钥匙。
我查了数据库中最大的令牌,并将其序列化了100次,平均值(总共100次序列化)大约为100ms。所以我不明白这可能是什么问题。最大的代表是33581个字符。我在你的回答中遗漏了什么?序列化和反序列化应该是同步的吗?这并不能解释被阻止的时间是正确的吗? – Zenuka
你可以显示呼叫计数以及该配置文件结果中所用的时间吗? – dbc
我没有看到显示调用计数的选项,但我猜它不会太多,因为它只会序列化一次令牌。 – Zenuka