Здравствуйте, только присоединился к группе, поэтому, возможно, дублирую вопрос, тем не менее. Не кажется ли вам странной технология вэбхука, реализованная в Алисе? (т.е. невозможность давать ответ отложено, в ответ на запрос должен лететь непосредственный ответ на него, на всё -про-всё даётся полторы секунды). Собственно, основной вопрос: "Представим себе, что ваш навык популярен и многофункциональный,т.е. требуется многоступенчатая обработка запроса, включающая подключения к бд,возможно, использование других сервисов для формирования динамического ответа и т.п. Как вы боретесь с тем, что Яндекс может закидать ваш сервер запросами, вызвать туево-тутуево скриптов хука и выжрать всю оперативу и цп" (подобные ситуации в других хуках (вк,тг и прочее) решаю тем, что хук выступает постановщиком реквестов в очередь, далее по крону запускается парсер запросов, дающий результирующий запрос ответа к серверу или урл этого запроса и так же в кроне работает очередь отдачи ответов). Мне просто абсолютно непонятно, как не дать Яндексу заспамить свой сервер. Заранее спасибо за ответы, извините за длиннопост.

Здравствуйте, только присоединился к группе, поэтому, возможно, дублирую вопрос, тем не менее. Не кажется ли вам странной технология вэбхука, реализованная в Алисе? (т.е. невозможность давать ответ отложено, в ответ на запрос должен лететь непосредственный ответ на него, на всё -про-всё даётся полторы секунды). Собственно, основной вопрос: "Представим себе, что ваш навык популярен и многофункциональный,т.е. требуется многоступенчатая обработка запроса, включающая подключения к бд,возможно, использование других сервисов для формирования динамического ответа и т.п. Как вы боретесь с тем, что Яндекс может закидать ваш сервер запросами, вызвать туево-тутуево скриптов хука и выжрать всю оперативу и цп" (подобные ситуации в других хуках (вк,тг и прочее) решаю тем, что хук выступает постановщиком реквестов в очередь, далее по крону запускается парсер запросов, дающий результирующий запрос ответа к серверу или урл этого запроса и так же в кроне работает очередь отдачи ответов). Мне просто абсолютно непонятно, как не дать Яндексу заспамить свой сервер. Заранее спасибо за ответы, извините за длиннопост.

Здравствуйте, только присоединился к группе, поэтому, возможно, дублирую вопрос, тем не менее. Не кажется ли вам странной технология вэбхука, реализованная в Алисе? (т.е. невозможность давать ответ отложено, в ответ на запрос должен лететь непосредственный ответ на него, на всё -про-всё даётся полторы секунды). Собственно, основной вопрос: "Представим себе, что ваш навык популярен и многофункциональный,т.е. требуется многоступенчатая обработка запроса, включающая подключения к бд,возможно, использование других сервисов для формирования динамического ответа и т.п. Как вы боретесь с тем, что Яндекс может закидать ваш сервер запросами, вызвать туево-тутуево скриптов хука и выжрать всю оперативу и цп" (подобные ситуации в других хуках (вк,тг и прочее) решаю тем, что хук выступает постановщиком реквестов в очередь, далее по крону запускается парсер запросов, дающий результирующий запрос ответа к серверу или урл этого запроса и так же в кроне работает очередь отдачи ответов). Мне просто абсолютно непонятно, как не дать Яндексу заспамить свой сервер. Заранее спасибо за ответы, извините за длиннопост.

так а в чем уменьшение нагрузки при постановке запросов в очередь? по сравнению с реалтайм режимом?!
или вы боитесь, что после публикации навыка он даст вам посетителей на 100fps?

реализация хука в Яндекс.Диалогах предполагает ВСЮ обработку непосредственно на хуке, постановка в очередь даёт возможность минимизировать нагрузку

реализация хука в Яндекс.Диалогах предполагает ВСЮ обработку непосредственно на хуке, постановка в очередь даёт возможность минимизировать нагрузку

Она копит технический долг)

распределить... скорее
но в любом пока ассинхронного протакола нет в алисе

Скорее сглаживает пики

например, 20 запросов в секунду, которые мне летят в ВК на пике за секунду,  я обрабатываю в среднем за секунду каждый в один поток, а запросы к Алисе я обязан обрабатывать моментально, т.е. по полной забивать ту же оперативную память

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

Ведь нужно ещё учитывать задержки на генерацию текста в речь и отправку клиенту, загрузку у клиента ответа и это ещё не учитывая задержки по самой сети в этой цепочке.

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

Ведь нужно ещё учитывать задержки на генерацию текста в речь и отправку клиенту, загрузку у клиента ответа и это ещё не учитывая задержки по самой сети в этой цепочке.

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

Если вы за ответом идёте куда нибудь ещё (внешний запрос к другому api к примеру) то такие вещи выгодней закешировать у себя.

А сообщение о обработке запроса портит ощущения у конечного потребителя.

У нас только новая страница появилась по нативным навыкам https://dialogs.yandex.ru/store/essentials
Пользователи Алисы просили. Больше изменений не было.

Но пользоваться таким не будут