PHP script op de achtergrond uitvoeren
Daarom wil ik graag dat de data WEL meteen weggeschreven wordt in de eigen MySQL database (dit gaat vrij snel), maar dat het wegschrijven in de externe database via cURL op de achtergrond gebeurd. Momenteel heb ik dat opgelost m.b.v. een cronjob die iedere x minuten controleerd of er wijzigingen zijn gedaan in de database en zo ja, deze dan afhandeld (en vervolgens in de eigen database ook als verwerkt markeert).
Deze cron methode werkt helemaal prima maar resulteerd er wel in dat er iedere x minuten een PHP script aangeroepen wordt terwijl er misschien maar 1x in de maand iets gewijzigd wordt. Erg zonde en inefficiënt lijkt me. Daarom zou ik willen weten of er een andere manier is om dit update script dat nu als cronjob iedere x minuten opgestart wordt ook op een of andere manier op de achtergrond gestart kan worden? Of waar ik ook aan had zitten denken is of het mogelijk is om vanuit PHP een cronjob aan te maken/te activeren en aan het eind van het cron script dat daardoor uitgevoerd wordt weer verwijderd/gedeactiveerd wordt of iets dergelijks.
Wie-o-wie heeft er een oplossing of denkrichting voor mij?
Het duurt erg lang.. Je code werkt en/of database-indeling is erg inefficient. Nu wil je dat gaan oplappen met een pleistertje...
Vervolgens bedenk je dan om dit via een cron te doen wat op zich helemaal geen slecht idee is. Maar een slecht in elkaar gestoken cronjob is natuurlijk net zo belabberd als elk ander slecht in elkaar gestoken script.
Voorts vind ik het helemaal niet onlogisch om een cronjob te laten draaien die maar af en toe iets nuttigs doet. Maar een belangrijke voorwaarde is dan wel dat deze zo snel mogelijk kan checken of hij zijn taak moet uitvoeren of niet zonder dat daar hele zware processen voor nodig zijn. Je kunt een cron overigens ook gewoon 1x of een paar keer per dag laten draaien.
Kortom hangt alles uiteindelijk toch vooral af van de kwaliteit van je code.
Frank Nietbelangrijk op 28/07/2016 03:55:27:
Je geeft zelf het antwoord al eigenlijk :-)
Het duurt erg lang.. Je code werkt en/of database-indeling is erg inefficient. Nu wil je dat gaan oplappen met een pleistertje...
Vervolgens bedenk je dan om dit via een cron te doen wat op zich helemaal geen slecht idee is. Maar een slecht in elkaar gestoken cronjob is natuurlijk net zo belabberd als elk ander slecht in elkaar gestoken script.
Voorts vind ik het helemaal niet onlogisch om een cronjob te laten draaien die maar af en toe iets nuttigs doet. Maar een belangrijke voorwaarde is dan wel dat deze zo snel mogelijk kan checken of hij zijn taak moet uitvoeren of niet zonder dat daar hele zware processen voor nodig zijn. Je kunt een cron overigens ook gewoon 1x of een paar keer per dag laten draaien.
Kortom hangt alles uiteindelijk toch vooral af van de kwaliteit van je code.
Het duurt erg lang.. Je code werkt en/of database-indeling is erg inefficient. Nu wil je dat gaan oplappen met een pleistertje...
Vervolgens bedenk je dan om dit via een cron te doen wat op zich helemaal geen slecht idee is. Maar een slecht in elkaar gestoken cronjob is natuurlijk net zo belabberd als elk ander slecht in elkaar gestoken script.
Voorts vind ik het helemaal niet onlogisch om een cronjob te laten draaien die maar af en toe iets nuttigs doet. Maar een belangrijke voorwaarde is dan wel dat deze zo snel mogelijk kan checken of hij zijn taak moet uitvoeren of niet zonder dat daar hele zware processen voor nodig zijn. Je kunt een cron overigens ook gewoon 1x of een paar keer per dag laten draaien.
Kortom hangt alles uiteindelijk toch vooral af van de kwaliteit van je code.
De code is op zich wel gewoon goed. De communicatie met de externe server is echter dusdanig vertragend dat het niet wenselijk is om de gebruiker hier op te laten wachten.
Het controle script is inderdaad een kort script die met minimale middelen test of er iets uitegevoerd dient te worden.
Je argument dat de cron job ook slechts 1x of een paar keer per dag gedraaid kan worden snap ik, echter is de data zodanig relevant dat deze z.s.m. na het wijzigen in de eigen database ook in de externe database aangepast dient te worden.
Dus mocht er iemand toch nog een concreet idee hebben over hoe ik dit proces zou kunnen verbeteren dan hoor ik het graag.
Door middel van 1 van de volgende oplossingen hou je dan die lokale DB in sync:
- Commands en events
- Sync script
- API
Het mooiste is als je vanaf die externe locatie een seintje krijgt dat er iets is veranderd. Als dat geen optie is kan je of een cron of een php deamon schrijven die elke x tijd de data synct.
Remco van Bers op 28/07/2016 09:46:13:
Dit probleem los je op door een lokale DB waar je tegenaan checkt.
Door middel van 1 van de volgende oplossingen hou je dan die lokale DB in sync:
- Commands en events
- Sync script
- API
Het mooiste is als je vanaf die externe locatie een seintje krijgt dat er iets is veranderd. Als dat geen optie is kan je of een cron of een php deamon schrijven die elke x tijd de data synct.
Door middel van 1 van de volgende oplossingen hou je dan die lokale DB in sync:
- Commands en events
- Sync script
- API
Het mooiste is als je vanaf die externe locatie een seintje krijgt dat er iets is veranderd. Als dat geen optie is kan je of een cron of een php deamon schrijven die elke x tijd de data synct.
In dit geval ben ik de externe locatie ;-)
Een cron had ik dus al.
Dat commands & events ziet er interessant uit, daar ga ik vanavond eens even wat dieper induiken.