Job queue

Wie maakt hier gebruik van job queues en welk programma gebruik je daarvoor? Heb altijd een zelf fabrikaatsel gebruikt met Redis maar ben nu opzoek naar een deftige oplossing.

Ik ken heel wat queue programmas maar ik ben benieuwd wat jullie ervaring is met programma x en wat het voordeel is t.o.v. programma y.

Ik gebruik heel slordig een cronjob welke elke minuut of */2 draait.
En dan kijk ik daar of er opdrachten open staan en gepland voor dat tijdstip, of ik zet eenmalig een cronjob in t systeem.

Nooit gekeken naar goede oplossingen hiervoor eigenlijk, dus ben ook wel benieuwd welke programmas er hier voor zijn en hoe het werkt.

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Ik dacht dat er misschien wel een programma als cronjob zou zijn die het makkelijk maakt om cronjob te managen.

newcron -c "echo Gefeliciteerd > /home/jesse/welcome" -t "03-07-2014T00:00:000"

Zoiets ofzo
En return is dan een id, en deletecron {id} verwijderd die cron dan.

Ik weet niet hoe je het nu kan doen met individuele regels uit een cron halen?
Maar je hebt geen ID, dus dan zou je het met een regex moeten doen oid?

Xjessex schreef:

Ik dacht dat er misschien wel een programma als cronjob zou zijn die het makkelijk maakt om cronjob te managen.

newcron -c "echo Gefeliciteerd > /home/jesse/welcome" -t "03-07-2014T00:00:000"

Zoiets ofzo
En return is dan een id, en deletecron {id} verwijderd die cron dan.

Ik weet niet hoe je het nu kan doen met individuele regels uit een cron halen?
Maar je hebt geen ID, dus dan zou je het met een regex moeten doen oid?

Sorry, dat lijkt mij juist omslagtig... Overigens werken veel programmas met een soort gelijke tast queue die Lennie beschreef.

Ja zo doe ik het nu dus..
Alleen lijkt het mij makkelijker om voor een enkele cronjob welke eenmalig uitgevoerd dient te worden een regel in de cronjob te zetten. En bij het uitvoeren deze rule verwijderen.

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

En waarom niet, PHP is bloed snel als je het juist configureert.

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

En waarom niet, PHP is bloed snel als je het juist configureert.

Omdat je net zit te klagen dat het "500ms" duurt. Dan zijn er vast talen en opstellingen voor die het beter kunnen handelen.

Althans, dat wil zeggen dat ik naar een andere oplossing/taal was gaan zoeken.

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

En waarom niet, PHP is bloed snel als je het juist configureert.

Omdat je net zit te klagen dat het "500ms" duurt. Dan zijn er vast talen en opstellingen voor die het beter kunnen handelen.

Een API request die 500ms duurt, ik kan moeilijk van bedrijf x eisen dat ze een server moeten plaatsen in datacenter y in Amsterdam.

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

En waarom niet, PHP is bloed snel als je het juist configureert.

Omdat je net zit te klagen dat het "500ms" duurt. Dan zijn er vast talen en opstellingen voor die het beter kunnen handelen.

nodejs.
Dat is non blocking, php wordt regel voor regel uitgevoerd.
nodejs meerdere regels tegelijk
Waardoor je al die requests dus tegelijk kan uitvoeren
Ze hoeven niet op elkaar te wachten zoals bij php

toevoeging op 2 juli 2014, 19:09:43:

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

En waarom niet, PHP is bloed snel als je het juist configureert.

Omdat je net zit te klagen dat het "500ms" duurt. Dan zijn er vast talen en opstellingen voor die het beter kunnen handelen.

Een API request die 500ms duurt, ik kan moeilijk van bedrijf x eisen dat ze een server moeten plaatsen in datacenter y in Amsterdam.

Probleem heb ik ook wel eens gehad.
Ik was met de devs van *bliep bezig met een API etc. En beetje uitdenken en paar meetings
Maar de API waarmee *bliep werkt (het heeft geen eigen masten) is van een bedrijf dat wel toegang heeft tot T-Mobile masten.
Een Belgisch bedrijf geloof ik, en hun API is echt bar traag waardoor alles van *bliep ook best traag wordt (tegoed opvragen etc)

Xjessex schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Lennard schreef:

Je zou simpelweg een tabel in je database kunnen maken die je jobqueue bijhoudt. Je geeft daarin aan welke view/taak/bestand er uitgevoerd moet worden en welke parameters er moeten zijn, en je laat een cronjob elk bepaald interval checken of er commandos uit te voeren zijn; en zo ja dan voer je die uit.

Denk dat dat het handigste werkt?

Zo deed ik het.
Maar leek mij best omslachtig.

toevoeging op 2 juli 2014, 17:28:14:
doe*

Zo omslachtig is dit niet volgens mij. Hoe wil je het anders doen?

Je hebt programmas zoals RabitMQ. Die kun je een taak geven (nog geen 1ms) die vervolgens de taak gelijk doorgeeft naar in dit geval PHP die + / - 500 ms nodig heeft voor een API request.

Een cronjob zou niet werken omdat PHP niet asynchroon is (1000 API requests á 500 ms = 500 seconde) en elke minuut te traag is om bijvoorbeeld transactional mails te sturen.

Nu doe ik het met Redis. PHP zet een key in Redis en geeft het ID van die key door in een pub / sub channel waar een Node.js script actief naar luistert en vervolgens een CLI PHP request aanroept. Erg onhandig en fout gevoelig.

Je moet ook geen PHP gebruiken , is iedere seconde van belang? Gebruik dan sowieso geen PHP.

En waarom niet, PHP is bloed snel als je het juist configureert.

Omdat je net zit te klagen dat het "500ms" duurt. Dan zijn er vast talen en opstellingen voor die het beter kunnen handelen.

nodejs.
Dat is non blocking, php wordt regel voor regel uitgevoerd.
nodejs meerdere regels tegelijk
Waardoor je al die requests dus tegelijk kan uitvoeren
Ze hoeven niet op elkaar te wachten zoals bij php

In het geval van API requests wel ja maar voor applicaties is het niet altijd even handig een asynchrone omgeving.

Zullen we weer ontopic gaan? Ik zoek geen alternatief op maar gewoon een job queue programma zoals RabbitMQ en ik zou graag wat ervaringen horen met dit soort programmas.