Job handling

    Roald Lenaerts
    by Roald Lenaerts
Job handling hotline27

In aflevering 16 van onze podcast, Hotline27, gingen we dieper in op jobs en queues en wanneer je hier gebruik van maakt. In deze blog overlopen we wat je zeker moet weten uit deze interessante aflevering.

 

 

Wat is job handling?

Job handling wordt ook wel batches, tasks of steps genoemd en is een concept dat we bij bijna elke website tegenkomen. 

Een job passen we toe indien een bepaalde actie, een proces of een opgestart script te lang duurt. Dit proces laten we in de achtergrond draaien zodat gebruikers er tijdens hun websitebezoek geen hinder van ondervinden.

Scheduled jobs

De meest gebruikte vorm van jobs zijn scheduled jobs. Daarbij voer je op een bepaald moment van de dag iets uit met een bepaald interval, bijvoorbeeld elke dag, elke week of elk kwartier. Denk maar aan een database backup. In de Linux-wereld gebruiken we daar crons voor.

Jobs on demand

Je kan jobs ook onmiddellijk uitvoeren, op het moment dat je ze nodig hebt. Dit doen we bijvoorbeeld als we nieuwe content of images hebben geüpload waarop we in de achtergrond image resizes toepassen.

In de achtergrond betekent dat we ze niet uitvoeren in het proces waarin de request al verwerkt wordt. Alle gebruikers zouden immers de benen nemen als zo’n request langer dan 15 seconden duurt. Omdat de gebruiker te allen tijde controle moet houden over de situatie, geven we aan wanneer de job gestart is en wat de status ervan is.

Job workers, oftewel PHP-processen

Bij jobs on demand begint een website na het accepteren van een bestelling of actie dus meteen de job uit te voeren in de achtergrond. Het voordeel is dat je daarbij zoveel PHP-processen, ook job workers genoemd, kan starten als je wil.

Vroeger moesten we deze job workers op een creatieve manier laten weten wat ze moesten uitvoeren. In 2006 deed Peter (CEO Level27) dat nog met een primitieve databasetabel. Hierin werden jobs bijgehouden met een statusveldje. De job workers deden dan elke seconde een database-query om te kijken of er jobs klaarstonden.

Intussen lossen we dit op met een distributed queuing systeem. 
 

Wat is een distributed queuing systeem?

Een distributed queuing systeem is vergelijkbaar met een kassasysteem. Je hebt je kar ingeladen in het grootwarenhuis en rijdt ermee naar de kassa. Daar neem je natuurlijk de kassa waar het minste volk staat aan te schuiven.

Jij bent dan eigenlijk een job, en je gaat in de rij staan om je beurt af te wachten tot de kassierster alles heeft ingescand. Daarna zet het werk zich verder, want je moet nog alles in de auto laden en thuis in de kasten zetten.

In de winkel heb je ook verschillende kassa’s, en dat is eigenlijk net zo bij een distributed queuing systeem: je hebt verschillende workers met verschillende queues.
 

Wat is een queue dan eigenlijk?

Een bepaald proces gaat jobs plaatsen op de queue. Dan is er ook een consumer, en dat is eigenlijk een worker die effectief de jobs gaat uitvoeren. Als je hierover Googelt, zal je zien dat er vaak van messages gesproken wordt. Dat komt omdat je op de queue in feite notificaties zet die aan de worker vertellen dat hij een job moet uitvoeren.

Als je 20 of 100 jobs op die queue plaatst, gaan die jobs allemaal één voor één tot een goed einde gebracht worden. De consumer moet ook tegen de queue vertellen dat hij de job heeft uitgevoerd. Dit is naar consistentie toe heel belangrijk, want anders weet je niet of het proces volledig uitgevoerd werd.

Het gebruik van queues bij level27

Queues gebruiken heeft eigenlijk alleen maar voordelen. Je kan er meerdere consumers of workers op plaatsen, en de verwerking van processen gebeurt onmiddellijk én in realtime. 

Er zijn trouwens systemen voor queues op de markt die vrij kant-en-klaar zijn. Bij Level27 werken we met RabbitMQ en kunnen we alleen maar aanbevelen om te werken met zo’n kant-en-klaar systeem. 

In het controlepaneel van Level27 zitten er dan ook heel veel queues. Alle processen of acties die langer kunnen duren dan 100 milliseconden gebeuren met jobs: domeinregistraties, een cloud API aanspreken, AWS aanspreken, … Dit gebeurt ook allemaal via de queue.

Bij welk project moet je dan zéker met queues werken?

Eigenlijk gebruik je queues altijd als er iets extern gedaan moet worden dat potentieel langer kan duren. Bij een verwerking, een pdf, een externe call naar een API, … Als je wilt dat je jobs consistent uitgevoerd worden, is een queue wat je nodig hebt.

 

 

Contactgegevens

+32 (0)89 449130 Via Media 4
3500 Hasselt, België

BTW: BE0890 439 412
IBAN: BE73 6451 0290 9860
BIC: JVBABE22

Heb je na het lezen van dit artikel vragen over job handling of hosting in het algemeen? Stel ze hier en een van onze experts neemt spoedig contact met je op. 

Stel hier je vragen

Vragen of opmerkingen?

Laat het ons zeker weten via onze chatbox!
We helpen je graag verder.

Deel deze blog via