WebAPI aplikační server a dlouhotrvající operace rubrika: Programování: .Net

4 pilif
položil/-a 18.8.2017

Zdravím ve spolek,
popíšu situaci:

  • mám desktop aplikaci (WPF), která se připojuje přes WebAPI (http/s) na aplikační server
  • aplikační server běží na IIS jako WebAPI (ASP.NET/MVC)
  • je potřeba implementovat nějakou dlouho trvající úlohu (desítky minut až jednotky hodin)
  • desktop WPF vyvolá zpracování této úlohy, požadavkem na aplikační server
  • desktop WPF se může nyní klidně vypnout a zpracování úlohy na app. serveru musí pokračovat
  • desktop WPF musí mít možnost dotázat se app. serveru na stav úlohy = neběží, běží, hotovo,...

Uvažuji o tomto řešení:
desktop -> app. server -> "working server"
Kde "working server" je můj pracovní název na aplikaci typu windows service, čekající na požadavky z "app. serveru".
App. server by tedy v případě této dlouhodobé úlohy pouze předal požadavek (WCF) ke zpracování na "working server". Ten by pak ve vlákně začal pracovat. V případě potřeby, může spustit další vlákna s dalšími dlouhodobými úlohami. Bude také schopen odpovídat na dotazy o stavu zpracovávaných úloh.
Důvody tohoto řešení:

  • myslím si, že aplikační pool IIS není pro takovéto úkoly vhodný
  • nebudu zbytečně vytěžovat aplikační pool IIS
  • potřebuji zajistit zpracovávání úlohy i v případě ukončení/odpojení klientské aplikace
  • mohu tímto způsobem delegovat dlouhé a náročné operace třeba i na jiný stroj

Co si o tom myslíte?
Máte nějaké jiné návrhy, zkušenosti?

Díky za info.

odkaz Vyřešeno
7 harrison314
odpověděl/-a 18.8.2017
 
upravil/-a 20.8.2017

Ja s tym mam skunosti.

  1. IIS by to malo teoreticky zvladat no musis na nom zakazat recyklovanie AppPoolu (zvladalo tasky v desiatkach minut).
    Ale uz len kvoli bezpecnosti a moznosti rozlozenia zataze by som na IIS nechal len WebApi a tie dlhotrvajuec ulohy spustal na windows sluzbe.

  2. Na komunikaciu medzi web serverom a windows sluzbou pouzi nejaku message Queue, vo Windose mas rovno MSMQ, alebo vies pouzit MS SQL Service Brooker.
    Na frontu uloh vies pouzit aj tabulku v datbaze, ale na to treba trochu dovtipu a pohrat sa s SQL-kom.

Moje rienie nepouzivalo fronty ale databzu, do ktorej si aplikacia ktora spracovala ulohy znacila, ktore ulohy uz spracovala a v akom su stadiu (databaza patrila web serveru). Web Server tieto data len serviroval pouzivatelovi (pollovanie). Dnes by som rozhodne siel bud do MSMQ (alebo odboby v Azure), ci nejakej kniznice na spravu uloh - napriklad Hangfire (aj ked tie su skor pre kratsie ulohy).

Plus urcite bude niekto namietat re nemas pouzit REST ale websokety, no myslim si, ze na ulohy trvajuce desiatky minut to nie je potreba.

Komentáře

  • Honza Břešťan : Souhlas. IIS na to neni moc dobre stavene, takze je dobry napad to offloadovat. Nejaka MQ pak navic pomuze vyresit problem, co delat, pokud se behem processingu nevypne jenom ta WPF aplikace, ale neco se vysype na webserveru nebo tom "working serveru" a je potreba zajistit retry. 18.8.2017
  • harrison314 : Napisl som to dost choticky, keby chces daco dovisvetlovat, pytaj sa. 18.8.2017
  • ivoszz : Message Queue je přirozená odpověď na tento typ problémů, navíc to významně zjednodušší řešení (pokud se dobře navrhne). 21.8.2017
  • pilif : Ten MSMQ se mi jeví jako ideální. Zvlášť pokud vezmu v potaz, že tyto požadavky na "dlouhotrvající operace" mohou být vyvolány nejen z IIS aplikace, ale klidně z libovolného klienta neběžícího na .NET platformě. 21.8.2017
  • harrison314 : Plus MSMQ nemusis pouzivat nativne, ale mozes pomocou WCF, co robotu ulahcuje. Ano mozes ich vyvolavat priamo pocou MSMQ, ale aj tak, by som pred tym nehcal nejaku WS/REST/cokolvek fasadu. 21.8.2017
  • Petr Voneš : Z pohledu uživatele aplikace by každá dlouhotrvající operace měla zobrazovat nějaký progres, alespoň mě vždy naštve, když něco takového nedělá :-) Message queue mi nepřijde jako ideální řešení, navíc nakonfigurovat security u MSMQ není někdy zcela snadné. 21.8.2017
  • harrison314 : Ved nic nebrani tomu, aby windows service pri dlhotrvajucom procese posielal cez qeueu spravy o stave spet do aplikacie prezentacnej vrstvy (WebApi), ktora si ich bude perzistovat a na poziadanie povie pouzivatelovi - tvoje spracovanie je hitove na 40%. To nie je ziaden problem s Message Qeueu. 22.8.2017
  • harrison314 : Tu sa nejaka fronta z architektonickeho hladiska hodi, riesi mnoho problemov, ktore by vznikly, ak by si pouzil iba databazu a nejakym watcherom, ktory by sledoval stavy entit v DB a podla toho spustal tasky. Nemusi to byt prave MSMQ, je mnoho alternatov (MS SQL Brooker - v MS SQL od 2005), warprov, MQ pre socky https://geteventstore.com/ ci spominany https://www.hangfire.io/ 22.8.2017

Pro zobrazení všech 3 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.