Zpracování dat po odeslání odpovědi

DefenestrationPraha

Mám aplikaci, která zvenčí dostává data ke zpracování, a v těch datech je občas něco natolik kritického, že je nutno ihned uvědomit různé uživatele e-mailem, SMSkou, SIP zprávou atd.

Problém je v tom, že toto odesílání zpráv nějakou dobu trvá, některá z těch služeb (SMS brána atd.) může zrovna neodpovídat, navíc každý uživatel může potenciálně potřebovat jiný formát zprávy … čili toto rozesílání, které za optimálních okolností trvá jen třeba 100 milisekund, může ve špatném případě zabrat třeba půl minuty.

Chtěl bych proto nejdřív z prezentéru odeslat odpověď původnímu HTTP klientovi (třeba 200 OK) a pustit se do tohoto těžkého zpracování dat až potom.

Před dvěma měsíci mi ovšem Marek Bartoš psal, že „Tohle afaik nejde, celé php je stavěné tak, že po odeslání response chcípne.“

Napadá vás nějaká technika? Samozřejmě je ještě možnost neodesílat zprávy hned, jenom si je naštosovat do nějaké DB a mít pravidelný cron, který každých 15 vteřin zkontroluje frontu a pokud v ní něco přibylo, odešle to. Nevýhoda – po drtivou většinu času poběží tato kontrola naprázdno a bude zbytečně vytěžovat stroj.

DefenestrationPraha

Našel jsem toto, ale nevím, nakolik by tyto postupy komplikovaly život Nette samotnému:

https://stackoverflow.com/…ttp-response

Přece jen jde už o dost hluboké techniky.

Editoval DefenestrationPraha (25. 5. 2023 9:50)

F.Vesely

Tohle řeším přes RabbitMQ, je to lepší než mít frontu v db a pouštět crony.

Pavel Kravčík

F.Vesely napsal(a):

Tohle řeším přes RabbitMQ, je to lepší než mít frontu v db a pouštět crony.

Přesně to jsem chtěl napsat. Navíc, pokud je to důležité, tak to nemůže být zbytečné vytěžování stroje.

DefenestrationPraha

Zběžně jsem se podíval na RabbitMQ a přijde mi, že je to jako učit se japonsky kvůli třídenní cestě do Japonska… My bohužel máme nějakou existující infrastrukturu pro SMS, SIP apod., kde je to víceméně otázka zavolání jedné PHP funkce, a která podporuje šifrování pomocí GnuPG atd. Jenom jde o to, jak tu funkci zavolat z bezpečného kontextu. Těžiště té naší aplikace není v messagingu, je to boční funkce.

Nevím, kolik času by zabralo naučení se a integrace celého nového frameworku do naší aplikace, ale míň než cca 100 člověkohodin to asi nebude. Na to bohužel nemáme kapacitu.

Editoval DefenestrationPraha (25. 5. 2023 10:13)

Kamil Valenta

DefenestrationPraha napsal(a):

pravidelný cron, který každých 15 vteřin

Minimální interval pro cron je 1 min, takže bys musel startovat 4 procesy a 3 z nich by si aktivně počkali do 15., 30. a 45. vteřiny

Nevýhoda – po drtivou většinu času poběží tato kontrola naprázdno a bude zbytečně vytěžovat stroj.

To bude naprosto zanedbatelná zátěž a kdejaký crawler nageneruje mnohem větší traffic.

DefenestrationPraha

Kamil Valenta napsal(a):

DefenestrationPraha napsal(a):

pravidelný cron, který každých 15 vteřin

Minimální interval pro cron je 1 min, takže bys musel startovat 4 procesy a 3 z nich by si aktivně počkali do 15., 30. a 45. vteřiny

Jasně, to si rozumíme, nechtělo se mi vypisovat to do detailů.

>

Nevýhoda – po drtivou většinu času poběží tato kontrola naprázdno a bude zbytečně vytěžovat stroj.

To bude naprosto zanedbatelná zátěž a kdejaký crawler nageneruje mnohem větší traffic.

OK, proměřím si to. Asi by to chtělo udělat tak, aby se kvůli kontrole nestartovalo celé Nette. Možná přímým dotazem do DB pomocí nějakého dedikovaného skriptu.

F.Vesely

DefenestrationPraha napsal(a):

Zběžně jsem se podíval na RabbitMQ a přijde mi, že je to jako učit se japonsky kvůli třídenní cestě do Japonska… My bohužel máme nějakou existující infrastrukturu pro SMS, SIP apod., kde je to víceméně otázka zavolání jedné PHP funkce, a která podporuje šifrování pomocí GnuPG atd. Jenom jde o to, jak tu funkci zavolat z bezpečného kontextu. Těžiště té naší aplikace není v messagingu, je to boční funkce.

Nevím, kolik času by zabralo naučení se a integrace celého nového frameworku do naší aplikace, ale míň než cca 100 člověkohodin to asi nebude. Na to bohužel nemáme kapacitu.

Tak jasne, pokud se nechces ucit nic noveho, tak jdi cestou fronty v databazi. Ja osobne se treba nove veci v tomhle oboru rad ucim. Jinak RabbitMQ neni nic sloziteho a jediny rozdil v te aplikaci bude, ze misto do databaze to ulozis do RabbitMQ a misto z databaze ty data dostanes z RabbitMQ. Kod na samotne posilani tech SMS bude u ubou reseni stejny.

DefenestrationPraha

F.Vesely napsal(a):

DefenestrationPraha napsal(a):

Zběžně jsem se podíval na RabbitMQ a přijde mi, že je to jako učit se japonsky kvůli třídenní cestě do Japonska… My bohužel máme nějakou existující infrastrukturu pro SMS, SIP apod., kde je to víceméně otázka zavolání jedné PHP funkce, a která podporuje šifrování pomocí GnuPG atd. Jenom jde o to, jak tu funkci zavolat z bezpečného kontextu. Těžiště té naší aplikace není v messagingu, je to boční funkce.

Nevím, kolik času by zabralo naučení se a integrace celého nového frameworku do naší aplikace, ale míň než cca 100 člověkohodin to asi nebude. Na to bohužel nemáme kapacitu.

Tak jasne, pokud se nechces ucit nic noveho, tak jdi cestou fronty v databazi. Ja osobne se treba nove veci v tomhle oboru rad ucim. Jinak RabbitMQ neni nic sloziteho a jediny rozdil v te aplikaci bude, ze misto do databaze to ulozis do RabbitMQ a misto z databaze ty data dostanes z RabbitMQ. Kod na samotne posilani tech SMS bude u ubou reseni stejny.

Nejde o nic ve smyslu lenosti, čeká mě asi pět dalších API k naučení do konce roku. Čas a energie je prostě něco, s čím už musím úzce hospodařit.

mystik

V principu je možné odeslat response, zavřít spojení a pak až zpracovat něco dalšího. Viz https://stackoverflow.com/…ection-early

Ale mnohem lepší řešení je opravdu přes nějakou frontu – buď v DB nebo RabbitMQ.