Триггер Http Azure Функция v2 (python) выполняет все логи c в соответствии с ожиданиями, но дает 504 тайм-аут шлюза через 4 минуты по веб-запросу

Question

Я создал функцию Http-Triggered Python Azure, которая занимает 3-10 минут для обработки всей бизнес-логики c в зависимости от размера данных.

При запуске этой функции с помощью почтальона или python веб-запрос, он ожидает ответа только до 4 минут. Если функция выполняется к тому времени, она дает ожидаемый ответ, в противном случае она возвращает ошибку 504 Gateway Time-out. Даже при том, что на стороне запроса выдается ошибка 504, функция azure обрабатывает всю нагрузку в соответствии с ожиданиями и не дает сбоя.

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

Может кто-нибудь помочь мне решить эту проблему?

Answer 1

Наконец, я нашел решение проблемы, с которой столкнулся.

Позвольте мне повторить мой полный сценарий здесь:

Полный сценарий : у меня был конвейер ADF, и функция Azure является одним из его компонентов, за которым следуют различные другие. Первоначальная проблема возникла, когда моему AF требуется около 30 минут для выполнения бизнес-логики c, и ответ на тайм-аут по умолчанию генерируется AF через 4 минуты автоматически, что прерывает поток и не выполняет следующие элементы в конвейере AF, которые должны запустить после успешного завершения компонента AF в идеальном сценарии.

Решение: Я разорвал один конвейер до 2 и соединил два конвейера с помощью приложения azure logi c. Позвольте мне теперь объяснить связь между точками.

Я преобразовал функцию azure для обработки всех трудоемких задач в потоке демонов и возвратил ответ на мой HTTP-запрос. Это решило мою 4-минутную проблему тайм-аута. Теперь вторая проблема заключается в запуске следующих компонентов в конвейере после выполнения функции Azure (отнимающие время задачи). Поэтому я создал приложение http триггера logi c и запустил его в конце выполнения задачи в функции Azure. Это приложение logi c, в свою очередь, запускает следующий конвейер и выполняет компоненты в каскадном порядке.

Answer 2

Как указано здесь :

Независимо от настройки времени ожидания приложения функции, 230 секунд - это максимальное время, которое триггерная функция HTTP может занять для ответа на запрос , Это из-за тайм-аута по умолчанию Azure Load Balancer. Для более длительного времени обработки рассмотрите возможность использования асинхронного шаблона c Durable Functions или отложите реальную работу и верните немедленный ответ.

То есть время ожидания истекает не для вашей функции, а потому, что это http-триггерный, это LB впереди.

Вы должны реализовать свой длительный процесс иначе. Например, получить данные через http-триггер. Этот берет данные и помещает их в очередь. Затем у вас есть вторая, запускаемая в очередь, функция, которая не обрабатывает долго и записывает результат куда-нибудь, например, в хранилище больших двоичных объектов.