Botframework-solutions: BeginDialogAsync 在第一次请求时需要更长的时间来执行

嗨@GustavoMoreiraPT

这只是使用模拟器在本地测试/调试吗？ 还是从使用 ngrok 在 azure 中部署的机器人？

其他用户是否有相同的行为？ （如果使用模拟器进行测试，则启动辅助模拟器并以新用户身份开始新对话）

嗨@dmvtech ，

非常感谢您的回复。

当从没有 ngrok 的 azure 部署时发生这种情况，在本地运行时使用 ngrok。

它只会发生在第一个用户身上。
第二个用户不会等待机器人回复 5 秒。

不确定这是否是我们可以从我们这边控制的一些行为。
乐于帮助任何需要的东西。

嗨@GustavoMoreiraPT

从你解释的行为和我最后的适度测试来看，我认为你看到了 .net 核心应用程序启动/引导和 kestrel 服务器启动。 一旦机器人开始运行，它就不必再做任何事情了。

为了帮助在 Azure 环境中缓解这种情况，您可以确保将应用服务设置为always on 。 以便服务在未主动使用时不会关闭（因此不必重新启动）。

此外，如果您正在使用持续部署做一些事情，您可以配置一些在部署后向机器人发送消息的内容。 确保初始启动发生在任何实际用户使用它之前。

嗨@dmvtech ，

再次感谢你的回复。
需要明确的是，我们有一个基于机器人框架的自定义解决方案，但已经对其进行了扩展。
我们已经尝试通过在执行第一个请求之前预热管道来缓解这个问题。

我正在谈论的热身任务帮助我们将第一个请求响应时间至少缩短了 50%。 在此操作之前，第一个请求需要 10 到 15 秒的时间来执行。 我们能够将这个时间减少到平均 5 秒，无论是给予还是接受。

我们还在 AppService 上启用了“始终开启”。 因为我们为 AppService 启用了应用洞察，所以我们可以控制到达的请求数量，我们注意到在没有任何请求的短时间内（5-10 秒）后，第一个请求比后面的请求执行时间更长.

虽然 5 秒并不是世界上最糟糕的问题，但我们希望在我们的解决方案中避免这个瓶颈，到目前为止还没有新的发现。

考虑到我在关于此问题的第一篇文章中提到的热身操作，您能看到一些可能与操作相关的其他任务吗？

谢谢

再次嗨@dmvtech ，

我一直在进行调试会话以找出报告的问题。
我发现在第一个请求中肯定需要更长的时间。

调用 BeginDialogAsync 时，内部方法调用之一发生在SkillWebSocketTransport 、 ForwardToSkillAsync 上

虽然我仍然没有测量代码特定红色部分的执行时间，但由于这是一个 pdb 文件广告，我对如何测量它有我的限制，很明显第一次调用需要 1,5 到 2 ,5 秒平均，而第二个呼叫立即终止。

当然，这可能是由于方法内部发生了某种缓存，但这确实影响了我们的用户体验。

我们可以看看这个吗？ 请让我知道我能提供什么帮助

与此同时，一旦有时间分享，我会更新这篇文章。

此致

你好，我们又见面了，

因此，基于之前的消息，我们一直在调查问题，在应用程序启动时，我们现在正在浏览我们需要的每个对话框，并创建一个虚拟调用，该调用使用SkillDialog上的入口点初始化整个管道
这样，当我们进行第一次真正的对话激活时，我们已经缓存了令牌。 通过应用此启动初始化，我们能够在第一次请求时恢复 1 到 2 秒的额外时间。

因此，这不是 bot 框架上的特定问题，而是位于 bot 框架正在使用的包上。

基于我们使用的版本 Microsoft.Bot.Builder.Solutions 4.7.0，此包依赖项之一是Microsoft.IdentityModel.Clients.ActiveDirectory, Version=5.2.4.0 ，这是正在执行令牌请求的程序集.
那里有一个 http 调用需要更长的时间，这就是我们看到额外延迟的原因。

其他人遇到过这种情况吗？
我真的很想知道，因为我没有在其他任何地方看到过这种报道。

请告诉我，

古斯塔沃

嗨@GustavoMoreiraPT

一段时间以来，初始令牌检索一直是已知的启动性能瓶颈。 2017 年 11 月，我们提供了一些类似于您所描述的指导： https :

嗨@EricDahlvang ，

感谢您的回复。
我们做了一个类似的方法，通过初始化对 DialogContext.BeginDialogAsync 的虚拟调用，因此，令牌将在第一个请求之前被缓存。
它有所帮助，但仍然不理想。

同时，您是否发现了文章中未提及的任何其他改进？

谢谢。

@GustavoMoreiraPT我已将其转移到 botframework-solutions 存储库，该程序包所在的位置：Microsoft.Bot.Builder.Solutions

@solutions团队，您对 GustavoMoreiraPT 有什么其他建议可以帮助缩短启动时间吗？

一个好的第一步是迁移到新的 GA 版本的 Skills，它消除了对 Websockets 的依赖。

我们有一些VA直线前进的步骤改变这里和任何自定义技能在这里。

GA 技能有不同的身份验证方法，我不知道类似的性能问题。 如果您对 VA 的更新有任何问题，请告诉我们并有兴趣了解这对您有何帮助。

根据您对 VA 所做的更改，另一种方法是创建新的 VA 并迁移更改，但如果您进行了大量更改，则上述步骤将指导您。

嗨@darrenj ，

谢谢回复。

我们已经注意到新版本 V0.8，我们已经在处理更改以进行迁移，但这是一项正在进行的工作。

我会及时通知您有关此事的最新消息。

再次非常感谢。

嗨@GustavoMoreiraPT ，

只是跟进看看您目前是否需要我们针对此特定问题提供更多信息？ 听起来基于您的最后一条评论，您有一条通过迁移到 v0.8 的道路。

如果没有积极的帮助需要，那么我现在将关闭该问题。 如果您在任何时候遇到有关此的更多问题，请随时重新激活，我们可以直接返回以提供帮助。

如果您有任何异议或需要任何积极帮助，请告诉我！

嗨@peterinnesmsft ，

感谢您的回复。
我一直在等待在 V0.8 迁移后有可用的指标与您分享，但不幸的是，由于时间限制，迁移被搁置了。

所以目前我们基本上在初始化时创建了一个 Fake Turn Context 提供者，这会强制获取令牌，这确实会影响第一个请求响应时间。
虽然它有效，但并不完美（它仍然比以下请求慢），但毕竟，我们设法将初始响应时间从 10/15 秒减少到 2/3 秒。

一旦我将项目迁移到 V0.8，我将回复此评论。
现在我认为它可以关闭，尽管问题似乎是真实的。

感谢您的帮助，让我们尽快说话！ :)

嗨@GustavoMoreiraPT ，

不用担心迁移延迟。 我很高兴你在缩短初始响应时间方面取得了一些成功，但我同意我们可能会帮助找到进一步降低它的方法。

我将暂时关闭该问题，但是当您能够重新访问时，让我们再次选择这个问题，我们可以很乐意帮助挖掘，看看我们可以做出什么样的改进。

期待很快收到您的回音！ :)

嗨@GustavoMoreiraPT ，

不用担心迁移延迟。 我很高兴你在缩短初始响应时间方面取得了一些成功，但我同意我们可能会帮助找到进一步降低它的方法。

我将暂时关闭该问题，但是当您能够重新访问时，让我们再次选择这个问题，我们可以很乐意帮助挖掘，看看我们可以做出什么样的改进。

期待很快收到您的回音！ :)