oorzaak timeout vinden
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.
Misschien helpt Monolog erbij.
https://github.com/Seldaek/monolog/blob/HEAD/doc/01-usage.md
Gewijzigd op 12/09/2024 15:22:17 door - Ariën -
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.
Succes ermee.
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..
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 ..
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.
Gewijzigd op 18/09/2024 08:44:40 door Gabriel Rood
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?