AS
По идеи я.ф всегда должна быть быстрее.
Size: a a a
2020 May 23
VP
Не понял. Это ведь не может говорить о том, что нода засыпает. Вы перегрузили запросами - это ведь другое.
Если глобальная переменная затерлась, значит нода заснула
AS
Если глобальная переменная затерлась, значит нода заснула
Аа, глобальная. Понял. Так она так и данные пользователя потеряет промежуточные.
Через сколько вы заметили засыпание?
Через сколько вы заметили засыпание?
AS
Я начинаю понимать почему ввели переменные в отправляемый джейсон)
ПК
У меня замеры такие: функция в среднем отрабатывает за 300-400мс, сам ответ от хероку у меня приходит за +- 150мс
это если на стороне хероку навык горячий, а если нет, хероку его выгрузил, то, в контексте нашей дискуссии про проксирование, получим таймаут.
AS
Нет никакого ограничения по времени, мой бот в ВК висит уже несколько месяцев без сбоев
А хостинг интересный.
Не вижу только каких-нибудь графиков нагрузки или использования памяти при запуске функции. Не предусмотрено да?
Не вижу только каких-нибудь графиков нагрузки или использования памяти при запуске функции. Не предусмотрено да?
VP
это если на стороне хероку навык горячий, а если нет, хероку его выгрузил, то, в контексте нашей дискуссии про проксирование, получим таймаут.
Это да. Но пинги от яндекса автоматом держат навык на хероку горячим.
ПК
Так суть идеи проксирования была в том, чтобы убрать пинги с хероку и отвечать на них проксей.
VP
Так суть идеи проксирования была в том, чтобы убрать пинги с хероку и отвечать на них проксей.
Для меня главная цель проксирования в другом: чтобы при апдейте приложения на хероку всех пользователей навыка не выкидывало по таймауту.
AZ
Так суть идеи проксирования была в том, чтобы убрать пинги с хероку и отвечать на них проксей.
ну так кидаем запрос на внешний сервис через я-функцию с таймаутом ответа 2 секунды... если не успел за 2 секунды отвечаем в я-функции, что мол. спасибо что разбудили, повторите ваш запрос я не услышал
ПК
Т.е. сейчас пользователь получает ошибку если навык не ответил за 3с, а будет получать аналогичную по бесполезности заглушку, если он не ответит за 2? Это же ухудшение пользовательского опыта. В чем смысл?
AZ
Т.е. сейчас пользователь получает ошибку если навык не ответил за 3с, а будет получать аналогичную по бесполезности заглушку, если он не ответит за 2? Это же ухудшение пользовательского опыта. В чем смысл?
ну смысл как я понял разбудить сервис, если придумать как контролить, что он не спит то и не нужно 2 секунды, уже просто прокси.
с учетом сохранения состояния, уже не проблема особо будет... просто на первом запросе и запуске навыка проверять спит или нет
ну и пинги обрабатывать на функции. ну, а часы на херохосте не тратятся
с учетом сохранения состояния, уже не проблема особо будет... просто на первом запросе и запуске навыка проверять спит или нет
ну и пинги обрабатывать на функции. ну, а часы на херохосте не тратятся
ÐХ
А хостинг интересный.
Не вижу только каких-нибудь графиков нагрузки или использования памяти при запуске функции. Не предусмотрено да?
Не вижу только каких-нибудь графиков нагрузки или использования памяти при запуске функции. Не предусмотрено да?
Нет, но нам этого пока не надо.
AS
Для меня главная цель проксирования в другом: чтобы при апдейте приложения на хероку всех пользователей навыка не выкидывало по таймауту.
Погодите. То есть пользователь может находиться в любом месте локации внутри навыка, вы подгружаете обновление - переменные окружения сбрасываются и достижения теряются. Какой смысл ему слать типа - подождите мы обновляемся или я вас не расслышал.
AS
ну так кидаем запрос на внешний сервис через я-функцию с таймаутом ответа 2 секунды... если не успел за 2 секунды отвечаем в я-функции, что мол. спасибо что разбудили, повторите ваш запрос я не услышал
Даа, можно промежуточный ответ по сценарию подготовить)
AZ
Даа, можно промежуточный ответ по сценарию подготовить)
Ну да в этом и смысл. Чтобы не говорило, мол навык не отвечает. уже лучше
AS
Ну да в этом и смысл. Чтобы не говорило, мол навык не отвечает. уже лучше
Кстати, идея для яндекс диалогов сделать это на уровне платформы. Так же в вебинтерфейсе - дефолтный ответ навыка вместо - навык не ответил. Даже можно расширить - по переданным в контексте данным последний раз отвечать по разному если навык не ответил. Хороший кейс)
AS
Можно даже в джейсоне выделить отдельное свойство для ответа если в следующий запрос навык не ответил. Как вам такое Павел Капля?)
AS
Т.е. сейчас пользователь получает ошибку если навык не ответил за 3с, а будет получать аналогичную по бесполезности заглушку, если он не ответит за 2? Это же ухудшение пользовательского опыта. В чем смысл?
Предлагаю в джейсоне выделить отдельное свойство (тхт, ттс) для ответа в случае если в следующий запрос не пришел ответ.
AZ
Кстати, идея для яндекс диалогов сделать это на уровне платформы. Так же в вебинтерфейсе - дефолтный ответ навыка вместо - навык не ответил. Даже можно расширить - по переданным в контексте данным последний раз отвечать по разному если навык не ответил. Хороший кейс)
выглядит ужасно... вот кнопка повторить запрос и флаг replay какой... вот это было бы круто
Но есть проблема с совместимостью...
Но есть проблема с совместимостью...