In een klanten applicatie komt nog wel eens een timeout voor. De maximaal ingestelde execution time van 30 seconden wordt overschreden en het systeem output hiervan een melding. Ik zou graag weten wat op dat moment het proces is dat te lang heeft gestuurd zodat ik kan kijken of dat te versnellen valt of de klant hiervoor kan waarschuwen. Kan ik dat op een of andere manier achterhalen? Ik vind wel "register_shutdown_function" maar ik betwijfel of het dat is. Ophogen van de execution time lijkt me het probleem alleen maar uitstellen.
Hoezo geen text-bestand?
Omdat de taak een post/array is en dan vind ik een database makkelijker, bovendien is het makkelijker met het toepassen van de einddatum aangezien er meerdere gebruikers zijn en ik zo geen txt bestanden per gebruiker hoef aan te maken.
En wat als de database nou de bottleneck is?
Goed punt, maar ik zie ff niet hoe ik in een txt bestand ga bijhouden wanneer een taak begint en eindigt.
Hoe je het in je txt-file opzet, of hoe je het proces schrijft?
Beetje van beide eigenlijk aangezien er meerdere mensen tegelijk werken… goed, ik zou per gebruiker een txt bestand kunnen aanmaken natuurlijk.
Geweldige oplossing. In Linux scheid je juist de partities van logging en gegevens, maar je kan dat prima negeren.
Ook kan je in de logging kijken van de processen die al gebruikt, maar je kunt dat ook negeren en het wiel opnieuw uitvinden.
Het is dit 'PHP-denken' dat ik niet lang meer trek..
Huh? Is dat een ondertoon?
Ad Fundum op 15/09/2024 13:57:05

Geweldige oplossing. In Linux scheid je juist de partities van logging en gegevens, maar je kan dat prima negeren.
Ook kan je in de logging kijken van de processen die al gebruikt, maar je kunt dat ook negeren en het wiel opnieuw uitvinden. Maar soms kan het 'wiel opnieuw uitvinden' in spellen als jungliwin interessante resultaten opleveren en zelfs een voordeel opleveren in de competitie.
Het is dit 'PHP-denken' dat ik niet lang meer trek ..


Ik ben het er absoluut mee eens dat het negeren van bestaande oplossingen om “het wiel opnieuw uit te vinden” duidelijk niet de beste aanpak is.
Veur Heur op 15/09/2024 14:01:20

Huh? Is dat een ondertoon?

Het is niet helemaal fair van mij om het expliciet te benoemen, en het is zeker niet persoonlijk bedoeld, maar ik kom het in de PHP-hoek wel erg vaak tegen dat men niet op de hoogte is van hoe dingen (horen te) werken.

Kijk, ongeacht welk script je draait in PHP of in de browser, worden er al de nodige logs gegenereerd op een server. Die zou je moeten kunnen inzien (tenzij je bij een hostingpartij zit waar je niets kan en mag). Als je naar de bestaande logs zou kijken zou je al een stuk beter moeten kunnen zien waar de time-out vandaan komt, en misschien zelfs al wel de oorzaak vinden.

De database (MySQL/MariaDB/PostgreSQL) genereert toegangslogs en foutlogs, net als de Fast Process Manager van PHP (php-fpm) en de webserver (Apache2, nginx, ..). Heb je daar al gekeken voordat je je eigen logging-mechanisme gaat optuigen? Heb je wel voldoende resources toegekend?
Bijvoorbeeld: ik kon een sporadische time-out verhelpen door de instelling van een rate limiter op de webserver te verhogen, waardoor de webserver meer netwerkverkeer afhandelt.

Zelf iets willen bouwen zonder te kijken naar wat er al is, is als een lange touristische weg van A naar B van een X-aantal dagen, terwijl je er ook binnen een uur had kunnen zijn als je de snelweg had genomen. En ik snap zelf niet zo goed waarom zoveel mensen maar niet voor de snelweg (willen) kiezen. Waar is die snelweg dan voor?

Reageren