Hej, potrzebuje rady nt dostepnych narzedzi w azure. Mam appke ktora wykonuje sie kilka - kilkanascie minut. Bedzie ona wywolywana przez rest API jako pierwotnie to widzialem azure function. Na forach odnosnie Azure Functions mam mieszane informacje, w jednych pisza, ze maksymalny timeout to 230s, natomiast w innych, ze po wyborze planu na Premium nawet timeout moze byc nielimitowany. Nie mam innego pomyslu jak rozwiazac problem timeoutow, czytalem tez o App Service ale one tez maja maksymalny timeout 230s i nie wiem, ew co moge wybrac innego by problemu z timeoutami sie pozbyc
- Rejestracja:ponad 4 lata
- Ostatnio:2 dni
- Postów:41
Microsoft Azure - Rejestracja:ponad 10 lat
- Ostatnio:12 miesięcy
1
Jeśli to ma być request-response HTTP to wtedy rzeczywiście limity po stronie Azure to często 230s. Na pewno tak jest w przypadku App Service i z tego co czytam wynika, że w przypadku funkcji HTTP jest tak samo.
Tylko jeśli to jest coś co się wykonuje kilka-kilkanaście minut to chyba standardowy synchroniczny request-response nie jest najlepszym rozwiązaniem...
Użytkownik przez te kilkanaście minut ma czekać na odpowiedź, czy to jednak bardziej procesowanie w tle, gdzie za pomocą HTTP robisz trigger i zwracasz informację, że przyjęto do realizacji, a później procesujesz w tle i ew. w jakiś sposób informujesz użytkownika, że procesowanie się zakończyło?
Jeśli mowa o procesowaniu w tle - np. funkcja triggerowana wyzwalaczem czasowym, albo wiadomościami z kolejki, timeout na Azure Function jest konfigurowalny i w planach niekonsumpcyjnych chyba rzeczywiście nieograniczony (jak dobrze pamiętam niekoniecznie to musi być plan premium).
edytowany 2x, ostatnio: some_ONE
Undo
Uzytkownik przez te kilkanascie minut sobie pracuje nad czyms innym. To bedzie sie procesowalo w 'tle'
- Rejestracja:około 3 lata
- Ostatnio:8 dni
- Postów:809
2
Do takich rzeczy nie używa się synchronicznego request-response tylko asynchronicznej komunikacji opartej o wiadomości https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#event-driven-triggers.
Azure do tego ma dedykowaną usługę WebJobs https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#azure-web-apps-and-webjobs
Co do Azure Functions to MS pisze w dokumentacji wyraźnie
You can use functions for background jobs that don't run for a long time.
Używaj zawsze usług w tych use case'ach do których zostały stworzone a nie na siłę próbuj używać czegoś co się do danego zadania nie nadaje. A Azure Functions do twojego przypadku nie pasują.
edytowany 1x, ostatnio: markone_dev
- Rejestracja:około 3 lata
- Ostatnio:8 dni
- Postów:809
0
Azure Webjobs maja swoje API https://github.com/projectkudu/kudu/wiki/WebJobs-API#invoke-a-triggered-job
- Rejestracja:ponad 10 lat
- Ostatnio:12 miesięcy
1
markone_dev napisał(a):
Do takich rzeczy nie używa się synchronicznego request-response tylko asynchronicznej komunikacji opartej o wiadomości https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#event-driven-triggers.
Azure do tego ma dedykowaną usługę WebJobs https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#azure-web-apps-and-webjobs
Z tymi WebJobami to dyskusyjna sprawa. Jeśli mowa o asynchronicznej komunikacji opartej o wiadomości to według mnie jednak dedykowaną i nowoczesną usługą do tego przeznaczoną jest Azure Functions, a nie WebJoby.
Co do Azure Functions to MS pisze w dokumentacji wyraźnie
You can use functions for background jobs that don't run for a long time.
Używaj zawsze usług w tych use case'ach do których zostały stworzone a nie na siłę próbuj używać czegoś co się do danego zadania nie nadaje. A Azure Functions do twojego przypadku nie pasują.
To ciekawy wątek, bo z kolei w innym miejscu dokumentacji:
Azure Functions offers more developer productivity than Azure App Service WebJobs does. It also offers more options for programming languages, development environments, Azure service integration, and pricing. For most scenarios, it's the best choice.
Here are two scenarios for which WebJobs may be the best choice:
- You need more control over the code that listens for events, the JobHost object. Functions offers a limited number of ways to customize JobHost behavior in the host.json file. Sometimes you need to do things that can't be specified by a string in a JSON file. For example, only the WebJobs SDK lets you configure a custom retry policy for Azure Storage.
- You have an App Service app for which you want to run code snippets, and you want to manage them together in the same Azure DevOps environment.
For other scenarios where you want to run code snippets for integrating Azure or third-party services, choose Azure Functions over WebJobs with the WebJobs SDK.
Ja osobiście zazwyczaj nie rekomenduję używania WebJobów, bo:
- wspiera je tylko App Service w wersji Windowsowej (2x droższy od Linuksowego :]), masz App Service na Linuksie to już WebJobów nie odpalisz,
- działają w dziwnym sandboxie, tak jak i wszystko na App Service'ach Windowsowych, który może powodować problemy - poblokowane porty, niektóre libki nie działają, np. kiedyś nie dało się w sandboxie generować PDF z HTMLa za pomocą Puppeteera, bo coś tam było zablokowane,
- traktuję Azure Functions jako następce WebJobów, próżno szukać aktualizacji dotyczących WebJobów, a przy Azure Functions co chwilę coś nowego się pojawia
Przy triggerowanych workloadach nie widzę żadnej przewagi WebJobow nad Functions, szczególnie, że w funkcjach na planach dedykowanych i premium można ustawić timeout wykonania na nieograniczony i efekt jest taki sam jak w przypadku WebJobów.
Jedyne co mają WebJoby, a czego nie mają Azure Functions to możliwość uruchomienia zadania w tle działającego bez przerwy - np. jakiś listener na Rabbita, czy cokolwiek. Wtedy rzeczywiście Azure Functions się do tego nie nadają i tutaj z Functions trzeba na siłę kombinować co jest bez sensu.
edytowany 1x, ostatnio: some_ONE
- Rejestracja:około 3 lata
- Ostatnio:8 dni
- Postów:809
2
Generalnie serverlessy nie nadają się na długo trwające batch joby i to niezależnie od vendora. Przykładowo AWSowe Lambdy mają limit czasu wykonania do 15 minut i to nie bez powodu.
Dlatego w takich sytuacjach jak ma op lepiej jest użyć innych usług.