Alternatief voor cron job
Voor mijn implementatie heb ik een cron job gebruikt die om de minuut een script uitvoert. Nu vertelde mijn leraar dat er meerdere alternatieven zijn om dit te doen met PHP. Iemand suggesties?
Je kan wel een dergelijke mogelijkheid in PHP bouwen, maar dan ben je wel afhankelijk van je bezoekers, en dan is er ook een kans dat je scripts niet op de juiste tijden worden gedraaid. Tevens draaien de scripts dan als proces binnen PHP wat niet altijd verstandig is, plus dat je niet zomaar alle taken kan uitvoeren omdat je webserver (hopelijk!) niet als root zal draaien. Dit betekent ook dat als je zware taken zou draaien, dat deze via het proces van de bezoeker worden gedraaid. Als dit zware scripts zijn, dan zal je bezoeker dus een lange laadtijd kunnen ervaren.
Maar als je het vanuit PHP wilt dan, dan kan je heel simpel kijken naar de tijd dat iets ingepland is, en of deze verstreken is. strtotime is een handige functie hiervoor. Hoe je de taken bijhoudt, dat is aan jouw vrijheid verder. Dit kan met een simpel tekstbestandje, maar ook in een database.
Vergeet niet als een taak afgelopen is om dit netjes af te vinken, anders blijft deze worden gedraaid.
Verder is het altijd verstandig om na te denken of een cronjob echt elke minuut moet worden gedraaid. Vaak is hier een logische oplossing voor om dit overbodig te maken.
Gewijzigd op 25/03/2018 11:11:10 door - Ariën -
Berucht is het bijwerken van saldo.
Als je elke mknuut een euro verdient, kun je elke minuut van alle gebruikers het saldo bij werkwn.
Je kunt ook bij het willen kopen van iets constateren dat hij 100 minuten geleden in het bezit was van 1000 euro en dat dat nu dus 1100 oet zijn.
Hij koopt nu iets van 500 dus sla je op dat zijjn saldo om 11u11 vandaag 600 is.
Volgende keer baseeer je je oo die 600 en het tijdstip
- Ariën - op 25/03/2018 11:08:14:
Je kan wel een dergelijke mogelijkheid in PHP bouwen, maar dan ben je wel afhankelijk van je bezoekers, en dan is er ook een kans dat je scripts niet op de juiste tijden worden gedraaid. Tevens draaien de scripts dan als proces binnen PHP wat niet altijd verstandig is, plus dat je niet zomaar alle taken kan uitvoeren omdat je webserver (hopelijk!) niet als root zal draaien. Dit betekent ook dat als je zware taken zou draaien, dat deze via het proces van de bezoeker worden gedraaid. Als dit zware scripts zijn, dan zal je bezoeker dus een lange laadtijd kunnen ervaren.
Dit klinkt erg interessant om mijn verhaal te verdedigen :) zou je hier wellicht wat dieper in detail kunnen treden aub? Dat zou ik enorm waarderen.
- Ariën - op 25/03/2018 11:08:14:
maar dan ben je wel afhankelijk van je bezoekers, en dan is er ook een kans dat je scripts niet op de juiste tijden worden gedraaid. waarom precies?
Tevens draaien de scripts dan als proces binnen PHP wat niet altijd verstandig is dus een cron job is de enige manier, waarmee er niet altijd een proces draaiende?
Tevens draaien de scripts dan als proces binnen PHP wat niet altijd verstandig is dus een cron job is de enige manier, waarmee er niet altijd een proces draaiende?
En cronjob is de enige manier om er zeker van te zijn dat je script exact uitgevoerd wordt op het moment dat het gepland is, en dat doet de cronjob-deamon helemaal zelf.
Gewijzigd op 25/03/2018 13:31:28 door - Ariën -
Een voorbeeld is het versturen van een nieuwsbrief. Die wil je bijvoorbeeld iedere woensdagnacht om 3.00 uur versturen. Daar gebruik je dan een cronjob voor.
Voor zaken die wél afhankelijk zijn van het feit of er iemand aanwezig is op de site, kun je andere methodes gebruiken om de pagina te verversen. Denk bijvoorbeeld aan een chatfunctionaliteit.
- hoe belangrijk is het dat de cron altijd op een gezette tijd wordt uitgevoerd
Is het bijvoorbeeld toegestaan dat een cron een keer wordt gemist?
Zonee, dan is het zaak dat er een monitorsysteem is die dit detecteert. Of het is in ieder geval handig/verstandig om een log bij te houden die registreert wat er dan wel gebeurt zodat je kan terugzoeken dat deze een keer niet is doorgeggaan.
Zoja,
- is dit dan van invloed op een volgende cron? Moeten bepaalde taken dan meerdere keren worden uitgevoerd, zoals het (vaker) ophogen van tellers zoals @Ivo aangeeft
- dient de data waarop de cron van invloed is vergrendeld te worden tijdens de uitvoering? je wilt namelijk mogelijk geen inmenging van buitenaf die de toestand van de data beinvloedt terwijl een cron daarmee bezig is; daartoe zou je een semafoor kunnen gebruiken, en database-transacties
- wat dient er te gebeuren als een cron om wat voor reden nog bezig is als de volgende cron wordt gestart? mogelijk moet je dan het interval tweaken (als dat mogelijk is) of code efficiënter maken, of iets anders, eerdergenoemde semafoor kan dan ook uitkomst bieden zodat te allen tijde eenzelfde cron maximaal 1x parallel actief is
Maar dit alles hangt wederom af van het gedrag van het script / de data die door de cron wordt aangezwengeld, ook hier is geen universeel recept voor. Dit is gedrag van de applicatie en daarmee applicatie-specifiek.
Danny Spinhuis op 25/03/2018 11:01:37:
Ik ben heel benieuwd welke meerdere alternatieven er volgens jouw leraar zijn. Ik hoop dat hij uitlegt na je opdracht en dat jij dat hier vertelt.Nu vertelde mijn leraar dat er meerdere alternatieven zijn om dit te doen met PHP. Iemand suggesties?
Sommige alternatieven hierboven beschreven vallen toch wel in de categorie "gekunsteld" omdat er een afhankelijkheid van gebruikers die een pagina opvragen is. Daarbij moet je dan extra programmeren dat de opdracht "gedaan" is voor deze minuut maar nog niet voor de volgende minuut. Kan ook extra vertraging op gaan leveren voor gebruikers. De ene keer is de pagina snel en de andere keer niet omdat de verwerking loopt. Enorm foutgevoelig gedoe. Ben benieuwd naar je leraar....
Zelfs voor de standaard cron is per minuut vaak al heel kritisch en moet je ook zekerheden inbouwen, zie wat Thomas schrijft.
Gewijzigd op 26/03/2018 11:04:23 door Aad B
En dan is het dus nog de vraag of het werk dat je met deze cron wil verzetten zich uberhaupt leent voor het mogelijk grillige verloop van het bezoek.
Uit oogpunt van complexiteit is het gewoon veel makkelijker om op gezette tijden een update-script aan te zwengelen via een cron in plaats van elke page-request te kijken of er iets moet gebeuren.
On a side note: iets wat héél belangrijk is is het volgende: de scripts die gebruikt worden voor dit soort crontaken dienen bij voorkeur niet in de publieke webdirectory staan en zouden eigenlijk nooit via een URL uitgevoerd mogen worden (of in ieder geval niet rechtstreeks). Dit hangt wederom van de taken af die zij uitvoeren en hoe dit is ingericht maar zelden tot nooit is het de bedoeling dat deze meer dan één keer binnen een bepaald tijdsbestek (of parallel, for that matter) worden uitgevoerd. Meestal heeft het te vaak uitvoeren van dit soort taken dan ongewenste bijeffecten of haalt het helemaal niets uit.