Botframework-solutions: BeginDialogAsync требует больше времени для выполнения при первом запросе

Привет @GustavoMoreiraPT

Это просто тестирование / отладка локально с эмулятором? Или из развернутого бота в лазурном с ngrok?

У других пользователей такое же поведение? (при тестировании с эмулятором, запуск вторичного эмулятора и начало нового разговора в качестве нового пользователя)

Привет @dmvtech!

Большое спасибо за ваш ответ.

Это происходит при развертывании из Azure без ngrok и с ngrok при локальном запуске.

Это просто случается с первым пользователем.
Второй пользователь не ждет 5 секунд ответа бота.

Не уверен, что это поведение, которое мы можем контролировать со своей стороны.
Рад помочь со всем, что нужно.

Привет @GustavoMoreiraPT

Судя по поведению, которое вы объяснили, и умеренному тестированию с моей стороны, я думаю, вы видите запуск / загрузку основного приложения .net и запуск сервера пустельги. Когда бот запущен, ему больше не нужно делать это снова.

Чтобы помочь смягчить это в среде Azure, вы можете убедиться, что служба приложений всегда включена. Чтобы служба не закрывалась, когда она не используется активно (и, следовательно, ее не нужно перезапускать).

Кроме того, если вы что-то делаете с непрерывным развертыванием, вы можете настроить что-то, что будет сообщать боту после развертывания. Чтобы убедиться, что первоначальный запуск произойдет до того, как к нему дойдут какие-либо реальные пользователи.

Привет @dmvtech!

Еще раз спасибо за ответ.
Чтобы быть ясным, у нас есть собственное решение, основанное на структуре ботов, но уже расширяющее его.
Мы уже пытались смягчить проблему, прогревая конвейер перед выполнением первого запроса.

Эти разогревающие задачи, о которых я говорю, помогли нам сократить время ответа на первый запрос примерно на 50%. До этих действий выполнение первого запроса занимало от 10 до 15 секунд. Нам удалось сократить это время в среднем до 5 секунд, плюс-минус.

Мы также включили "всегда включен" в AppService. Поскольку у нас включена аналитика приложений для AppService, мы можем контролировать количество поступающих запросов, и мы заметили, что после короткого периода без каких-либо запросов (5-10 секунд) выполнение первого следующего запроса занимает больше времени, чем следующих. .

Хотя 5 секунд - не самая большая проблема в мире, мы хотели бы избежать этого узкого места в нашем решении, и пока никаких новых открытий сделано не было.

Принимая во внимание действия по разминке, которые я упомянул в первом посте по этой проблеме, можете ли вы увидеть некоторые дополнительные задачи, которые могут иметь отношение к действиям?

Спасибо

Привет снова @dmvtech ,

Я проводил сеанс отладки, чтобы разобраться в сообщенной проблеме.
Я нашел то, что определенно занимает больше времени в первом запросе.

При вызове BeginDialogAsync один из внутренних вызовов метода происходит на SkillWebSocketTransport , ForwardToSkillAsync

Хотя я до сих пор не измерил время выполнения для конкретной красной части кода, поскольку это объявление файла pdb, у меня есть ограничения на то, как его измерить, ясно, что первый вызов занимает от 1,5 до 2 , В среднем 5 секунд, при этом второй звонок прерывается мгновенно.

Конечно, это может быть связано с каким-то кешем, который происходит внутри метода, но это действительно влияет на наш пользовательский опыт.

Можем ли мы взглянуть на это? И, пожалуйста, дайте мне знать, чем я могу помочь

А пока я обновлю этот пост, как только у меня будет время, чтобы поделиться им.

С наилучшими пожеланиями

Привет еще раз,

Итак, основываясь на предыдущих сообщениях, мы продолжали изучать проблему, и при запуске приложения мы теперь просматриваем каждый из необходимых нам диалогов и создаем фиктивный вызов, который инициализирует весь конвейер с точкой входа в SkillDialog. BeginDialogAsync метод.
Таким образом, у нас уже есть кэшированный токен, когда мы выполняем нашу первую настоящую активацию диалога. Применяя эту инициализацию при запуске, мы смогли восстановить от 1 до 2 дополнительных секунд по первому запросу.

Так что это не конкретная проблема в структуре ботов, она скорее находится в пакете, который используется фреймворком ботов.

В зависимости от используемой версии, Microsoft.Bot.Builder.Solutions 4.7.0, одна из зависимостей этого пакета - Microsoft.IdentityModel.Clients.ActiveDirectory, Version = 5.2.4.0 , которая представляет собой сборку, в которой выполняется запрос токена. .
Там есть http-вызов, который занимает больше времени, и по этой причине мы наблюдали дополнительную задержку.

Кто-нибудь еще сталкивался с этим?
Мне действительно любопытно узнать, потому что я нигде не видел, чтобы об этом сообщалось.

Пожалуйста, дай мне знать,

Густаво

Привет @GustavoMoreiraPT

Первоначальное извлечение токена было известным узким местом при запуске в течение некоторого времени. В ноябре 2017 года мы предоставили некоторые рекомендации, аналогичные тому, что вы описали: https://blog.botframework.com/2017/11/02/optimizing-latency-bot-framework/ Это не было обновлено для V4 sdk, но вы можете увидеть аналогичную схему получения токена при запуске и периодического его обновления в фоновом режиме.

Привет, @EricDahlvang!

Спасибо за ваш ответ.
Мы применили аналогичный подход, инициализировав фиктивный вызов DialogContext.BeginDialogAsync, и, как таковой, токен будет кэшироваться перед первым запросом.
Помогло, но все еще не идеально.

А пока нашли ли вы какие-либо дополнительные улучшения, не упомянутые в статье?

Спасибо.

@GustavoMoreiraPT Я перенес это в репозиторий botframework-solutions, где находится этот пакет: Microsoft.Bot.Builder.Solutions

Команда @solutions , есть ли у вас какие-либо другие рекомендации для GustavoMoreiraPT, которые могут помочь сократить время запуска?

Хорошим первым шагом будет переход на новую версию Skills GA, которая устраняет зависимость от Websockets.

У нас есть несколько простых шагов для изменения VA здесь и для любых пользовательских навыков здесь .

GA Skills использует другой подход к аутентификации, и я не знаю о подобных проблемах с производительностью. Если у вас есть какие-либо проблемы с обновлениями вашего виртуального устройства, сообщите нам об этом, и мы расскажем, как это вам поможет.

В зависимости от изменений, которые вы внесли в VA, другим подходом было бы создание нового VA и перенос изменений, но если вы внесли много изменений, приведенные выше шаги помогут вам.

Привет @darrenj!

Спасибо за ответ.

Мы заметили новую версию V0.8, и мы уже вносим изменения, чтобы выполнить миграцию, но эта работа еще не завершена.

Я буду держать вас в курсе об этом.

Еще раз большое спасибо.

Привет @GustavoMoreiraPT!

Просто следите за тем, чтобы узнать, есть ли что-то еще, что вам нужно от нас в настоящее время для решения этой конкретной проблемы? Судя по вашему последнему комментарию, у вас есть путь вперед через переход на v0.8.

Если активной потребности в помощи нет, то пока закрою вопрос. Если в какой-то момент у вас возникнут дополнительные проблемы по этому поводу, не стесняйтесь повторно активировать, и мы сразу же вернемся, чтобы помочь.

Дайте мне знать, если у вас есть какие-либо возражения или вам нужна активная помощь в чем-либо!

Привет @peterinnesmsft!

Спасибо за ваш ответ.
Я ждал, когда будут доступны метрики, которыми можно будет поделиться с вами после миграции V0.8, но, к сожалению, из-за нехватки времени миграция была приостановлена.

Итак, в настоящее время мы в основном создали провайдер Fake Turn Context во время инициализации, который принудительно получает токен и действительно увеличивает время ответа на первый запрос.
Хотя он и работает, он не идеален (он все же медленнее, чем следующие запросы), но после всего этого нам удалось сократить начальное время ответа с 10/15 секунд до 2/3 секунд.

Я отвечу на этот комментарий, как только я переведу проект на V0.8.
А пока я думаю, что это можно закрыть, хотя проблема кажется реальной.

Спасибо за вашу помощь, и давайте скоро поговорим! :)

Привет @GustavoMoreiraPT!

Не беспокойтесь о задержке миграции. Я рад, что вам удалось сократить первоначальное время ответа, но я согласен с тем, что мы, вероятно, поможем найти способы его дальнейшего сокращения.

Я сейчас закрою проблему, но давайте вернемся к ней снова, когда вы сможете вернуться к ней, и мы с радостью поможем разобраться, какие улучшения мы можем внести.

С нетерпением ждем ответа от вас в ближайшее время! :)

Привет @GustavoMoreiraPT!

Не беспокойтесь о задержке миграции. Я рад, что вам удалось сократить первоначальное время ответа, но я согласен с тем, что мы, вероятно, поможем найти способы его дальнейшего сокращения.

Я сейчас закрою проблему, но давайте вернемся к ней снова, когда вы сможете вернуться к ней, и мы с радостью поможем разобраться, какие улучшения мы можем внести.

С нетерпением ждем ответа от вас в ближайшее время! :)