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 回答