2

我们已经看到在 Azure A2 Basic VM 上运行的 kestrel 实例出现了一些有趣的行为。随着呼叫之间的时间增加,响应时间似乎越来越恶化。例如...

加载时间

在 5 分钟左右,它表现得好像操作系统或 Kestrel 进程已经回收了一些资源,但是线性的5 分钟后响应时间的增加让我们陷入了一个循环。

此外,这似乎在本地开发时会间歇性地发生,这就是为什么没有消除 Kestrel 可以做某事的想法的原因。

有人对 5 分钟退化和随后恶化的退化有想法吗?这仅仅是使用 A2 虚拟机的症状吗?

那么时间的线性增长呢? 我知道数据点的数量是有限的,而且从快速浏览来看,增加很可能是一种异常情况,但这似乎是日常开发中常见的情况。 因缺少数据点而被删除

4

1 回答 1

0

在使用额外的跟踪进行一些测试后,大部分性能下降可以追溯到建立与 Azure SQL 的连接。Azure 门户中生成的默认连接字符串中未指定“最小池大小”。这将导致使用默认值 0。

将“最小池大小”设置为 5 后,不活动期后的响应时间得到改善。在 21 分钟不活动后,加载时间仍然只有 400 毫秒。

然后我们没有指定“最小池大小”(应用默认值 0,导致没有连接保持打开状态)。使用此设置,加载时间会在 5 分钟不活动后增加到 4 或 5 秒。

于 2016-05-06T16:36:21.263 回答