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.
Misschien een traag reagerende database? Ik raad aan om een hoop tijden en acties te loggen. Als de log ergens ophoudt, of vertraging laat zien, zit je op het goede spoor
Je kunt misschien timers inbouwen in je script waarbij je aangeeft:
<?php echo 'dit is line '. __LINE__ .' van script ' . __FILE__ ' timing is ' . $x ; ?>
Waarbij $x dat staat voor hoeveel tijd je script inmiddels gespendeerd heeft sinds de start.
Eventueel kun je de timeout ophogen naar meer, bijvoorbeeld 60 sec, om te zien of de timeout veroorzaakt wordt door een proces dat wat te traag is, of dat je mogelijk in een oneindige loop zit.
Maar als er geen goede reden is aan te wijzen, is het ophogen van de limiet omdat het anders niet werkt, geen goed idee.
Als duidelijk is dat je moet connecten met een service die er altijd 10 sec over doet en dat je moet wachten tot een printer fysiek 10 pagina's heeft afgedrukt: ja.
maar wachten omdat een crappy query de database laat zwoegen: dan is het wachten tot nog meer data de volgende limiet bereikt en je nog een keer moet ophogen.
Het probleem is dat ik er niet altijd ben om de boel te monitoren. Misschien is het dan ook beter om te gaan doen wat Ariën zegt... Ik zal dan een tabelletje aanleggen met taak, begintijd, eindtijd... Als er geen eindtijd verschijnt, weten we soort van waarop het is vastgelopen, toch?
Dat monitoren doe je toch vanuit een log-bestand. Als je een dagje niet op kantoor/thuis bent, dan bekijk je het toch de volgende dag? Het kan ook in de database, maar als dat de bottleneck is, dan wordt het lastig loggen. Daarom liever in een textbestand.
Er zijn complete methodologieën om problemen op te lossen.
Je moet beginnen bij de exacte tijdstippen wanneer de time-outs voorkomen. Sinds wanneer heb je last van time-outs?
En wat heeft daar nog meer mee te maken? Zijn er andere processen op de server actief?
Om dat te weten kan je achteraf in (performance) logbestanden kijken op die exacte tijdstippen, soms inclusief microseconden. Denk aan de logging van de database, php-fpm en de webserver.
Los van de netwerkverbinding (te veel verkeer) is de enige oorzaak van een I/O time-out dat de server niet tijdig reageert. Dat kan weer twee oorzaken hebben: het ding is te druk of hij wacht expres. Daarvan moet je iets kunnen zien in de logbestanden, anders moet je het logniveau opschroeven tot (= NIET inclusief) DEBUG.
Zodra je er achter bent kan je het probleem oplossen, bijvoorbeeld partitionering van databasetabellen of je queries versnellen met slimmere indices, efficiëntere PHP-code schrijven, meer resources toekennen en/of betere hardware kopen, rate limiting verhogen op de webserver, of een hogere QoS op de netwerkrouter instellen.
Ik ben begonnen met een log tabel die aan het begin van het script een entry toevoegt met taak + datetime + gebruiker. Helemaal aan het eind van het script wordt een tweede datetime toegevoegd, zo heb ik een begin en een eindtijd en dus de uitvoertijd. Aan het eind van de dag gooi ik automatisch alles weg waarvan de tweede datetime niet null is en zo heb ik de taken die niet helemaal tot het einde komen, maw een timeout hebben gehad. Lijkt me een begin voor het vinden van de oorzaak, althans dat hoop ik. Loopt nu 2 dagen, tabel is leeg, en dat klopt de PHP error log is namelijk ook leeg.
