Timeout 1000 seconden PHP

[Sr_Ogel]

Mijn vraag
Vanuit AJAX roep ik een PHP script aan die vanuit de database PDFjes moet genereren. Nu is het probleem dat hij er telkens bij 1000 seconden (16 minuten en 40 seconden) uit knalt omdat de sessie waarden verdwenen zijn.

Relevante software en hardware die ik gebruik
Apache php mysql

Wat ik al gevonden of geprobeerd heb

Door het scrip zonder reverseproxy ervoor te draaien heb ik al ontdekt dat het in de combi apache / php moet zitten. Verschillende clients geprobeerd maar daarin geen verschil kunnen ontdekken.

Als ik phpinfo() aanroep dan kan ik gene waarden meer vinden die op 1000 seconden staan.

de volgende instellingen heb ik gedaan:
Apache timeous 2400 sec
php max_execution_time 3600 sec
session.gc_divisor 10
session.GC_maxlifetime 3600

Heb al gekeken of de garbage collector een reden heeft om de sessie te einigen maar daarin kan ik ook niks ontdekken.

Het lijkt er dus op dat nog ergens een timeout op 1000 sec staat maar ik krijg hem niet boven water.

[jammo]

Wat bedoel je met 'er uit knalt omdat de sessie waarden verdwenen zijn'?
Wat is de foutmelding die je krijgt?

Heb je een specifieke reden om het script op deze manier te draaien? Aangezien het laten draaien van een script zolang er een verbinding is niet echt een betrouwbare manier is als het gaat om iets wat dusdanig lang duurt.
Waarom draai je het script niet op de achtergrond zodat je geen last hebt van proxies / webservers / browsers etc?

[Sr_Ogel]

Ik krijg onderstaande error

code:

PHP Fatal error:  Uncaught TypeError: gmdate(): Argument #2 ($timestamp) must be of type ?int, string given in

Ik reken met 2 timestamps die van elkaar afgetrokken worden. De eerste is de huidige tijd, de tweede is de start tijd opgeslagen in een variabele. Doordat de sessie verloopt komt de 2e variabele te vervallen en klapt daardoor het script eruit.

jammo schreef op woensdag 24 april 2024 @ 13:57:
Heb je een specifieke reden om het script op deze manier te draaien? Aangezien het laten draaien van een script zolang er een verbinding is niet echt een betrouwbare manier is als het gaat om iets wat dusdanig lang duurt.
Waarom draai je het script niet op de achtergrond zodat je geen last hebt van proxies / webservers / browsers etc?

Ik was in de veronderstelling dat doordat ik het script met AJAX aanroep het proces al in de achtergrond loopt maar dat is wellicht een fout aanname.

[ Voor 42% gewijzigd door Sr_Ogel op 24-04-2024 14:11 ]

[Mavamaarten]

Is het een harde requirement dat je per request na x minuten 1 response krijgt?

Over het algemeen worden taken die langer duren dan give or take een seconde afgehandeld met een soort job-systeem. Je doet een request om de taak te starten, die start dan op de achtergrond. Als antwoord krijg je een id om die taak uniek te identificeren. Op een ander endpoint kan je dan, met dat id, opvragen of een taak geslaagd is of nog bezig is. Op die manier hang je nergens vast aan hoe lang een http request in de lucht kan blijven en alle nadelen die daaraan verbonden zijn.

Aan de client-kant start je een job, poll je om de x seconden naar de status, en haal je het resultaat op als je doorkrijgt dat de job klaar is.

[Sr_Ogel]

Mavamaarten schreef op woensdag 24 april 2024 @ 14:21:
Aan de cliënt-kant start je een job, poll je om de x seconden naar de status, en haal je het resultaat op als je doorkrijgt dat de job klaar is.

Dank voor de andere kijk op het probleem. Ik ga hier mee aan de slag. Hiermee los ik niet het gevolg op maar zorg ik dat er juist geen probleem ontstaat.

Dank voor de trap in de goede richting.

[DexterDee]

Ik heb nog een andere kijk die ik je kan aanbieden.

In een wereld waar alles liefst zo compact mogelijk in een container moet draaien, zijn er voor PHP opties om de footprint en het aantal bewegende onderdelen sterk te reduceren:

https://roadrunner.dev/
https://frankenphp.dev/

Naast dat je hiermee geen aparte webserver, mod_php of PHP FPM meer hoeft te draaien om je PHP applicatie te hosten, heb je ook de mogelijkheid om worker processen te draaien die in principe oneindig lang mogen draaien.

Verder kun je hiermee dus zoals gezegd heel makkelijk en compact een PHP microservice "dockerizen".

[Toren]

Het zal toch niet zo zijn dat 1 PDF meer dan 1000 seconden nodig heeft? Kun je niet gewoon 1 proces starten per PDF en dan het result teruggeven als het klaar is?

[Sr_Ogel]

Toren schreef op dinsdag 30 april 2024 @ 16:34:
Het zal toch niet zo zijn dat 1 PDF meer dan 1000 seconden nodig heeft? Kun je niet gewoon 1 proces starten per PDF en dan het result teruggeven als het klaar is?

400 pdfjes variërend van een 0,5 tot 2 MB. Ik ben inderdaad nu het proces aan het opknippen naar een proces per rapport.

[Dido]

Sr_Ogel schreef op dinsdag 30 april 2024 @ 18:59:
400 pdfjes variërend van een 0,5 tot 2 MB. Ik ben inderdaad nu het proces aan het opknippen naar een proces per rapport.

Dat klinkt verstandig. Je zou eventueel kunnen kijken naar een mogelijkheid om dat dan ook meteen multithreaded te doen zodat je meerdere checks tegelijk uitvoert.

Hoewel ik (te) vaak zie dat mensen graag multithreaded willen werken omdat het cool is, lijkt dit een bij uitstek geschikte use-case ervoor.

Sowieso wil je connecties over het algemeen zo kort mogelijk open hebben, of het nu naar een web-server is of een database, al is het maar omdat je over het algemeen ergens in het proces anders iets erg lang aan het blokkeren bent. Als iets niet in kleine taken is op te knippen is asynchrone verwerking is meestal een voor de hand liggende oplossing.