Hoe je de backlog van een PHP-queue beheerst zonder het probleem te verergeren

Met een jobqueue kun je taken uitvoeren buiten het directe pad van een request, zoals notificaties versturen, bestanden verwerken of gegevens synchroniseren. Maar wanneer er meer jobs binnenkomen dan de consumers kunnen afhandelen, ontstaat er een backlog. De vertraging kan merkbaar worden in late bevestigingen, verouderde gegevens of taken die nooit worden afgerond. Dat heeft gevolgen voor zowel gebruikers als de teams die de applicatie beheren.

Om te bepalen wat je moet doen, volstaat het niet om alleen te kijken hoeveel berichten in de wachtrij staan. Ook hun ouderdom, de snelheid waarmee ze binnenkomen en worden afgerond, het soort werk en de status van afhankelijkheden zijn van belang. Extra consumers kunnen helpen als er capaciteit ontbreekt, maar kunnen ook het aantal queries naar een al overbelaste database vermenigvuldigen. Een veilige aanpak begint met meten en het herkennen van het patroon.

Wat de backlog laat zien en welke metrics ontbreken

Het aantal openstaande jobs is een momentopname, geen verklaring. Het kan tijdens een piek groeien en daarna zonder ingrijpen weer afnemen, of stabiel blijven terwijl de oudste job steeds langer wacht. Daarom is het bij het beheersen van de backlog van een PHP-queue verstandig om de volgende zaken gezamenlijk te monitoren:

• Instroomsnelheid: het aantal geaccepteerde jobs per tijdseenheid.
• Uitstroomsnelheid: het aantal afgeronde jobs per tijdseenheid, waarbij afgeronde jobs worden onderscheiden van mislukte pogingen.
• Ouderdom: hoelang de oudste job al wacht, en daarnaast de wachtpercentielen als die beschikbaar zijn.
• Verwerkingsduur: hoelang elk type job duurt en hoe die duur verandert.
• Fouten en retries: het foutpercentage, het aantal pogingen en de aanwezigheid van jobs die naar een error- of quarantine-queue zijn verplaatst.
• Status van consumers en afhankelijkheden: actieve processen, herstarts, CPU- en geheugengebruik, databaseverbindingen en de latency van externe services.

De uitstroomsnelheid moet het aantal succesvol afgeronde jobs weergeven: als elke poging wordt geteld als een afgehandelde taak, kan een cyclus van fouten en retries verborgen blijven. Het is ook belangrijk om per queue of taakklasse te segmenteren. Een algemeen gemiddelde kan verhullen dat één type werk de overige taken blokkeert.

Diagnosticeer het patroon voordat je de capaciteit aanpast

Vergelijk de metrics over een tijdvenster dat past bij de bedrijfsvoering en met het gebruikelijke gedrag van het systeem. Patronen kunnen richting geven aan het onderzoek, maar bewijzen op zichzelf niet wat de oorzaak is.

• De instroom blijft hoger dan de uitstroom: er kan capaciteit ontbreken, het volume kan zijn toegenomen of de verwerking van jobs kan langer duren. Controleer recente wijzigingen, de samenstelling van het verkeer en de verwerkingstijden per taaktype.
• Consumers zijn actief, maar de uitstroom is vrijwel nihil: zoek naar vastgelopen processen, oneindige wachttijden, deadlocks, een uitgeputte connection pool of externe calls zonder timeouts. Controleer logs en traces die met een job-ID aan elkaar zijn gekoppeld.
• De verwerkingsduur en latency van afhankelijkheden nemen toe: consumers wachten mogelijk op de database, een API of opslag. Meer processen kunnen de contention verhogen en de latency verslechteren.
• Dezelfde jobs mislukken herhaaldelijk: er kan sprake zijn van ongeldige gegevens, een niet-herstelbare situatie of een defect. Controleer het retrybeleid: te snel opnieuw proberen kan een load storm veroorzaken.
• Eén queue groeit terwijl andere vooruitgang boeken: controleer de prioriteiten, de verdeling van consumers en of één taakklasse de resources monopoliseert.

Controleer ook recente configuratiewijzigingen en deployments. Zorg ervoor dat de telemetrie onderscheid maakt tussen een consumer die bezig is en een actieve consumer die geen voortgang boekt; een controle op een actief proces garandeert niet dat er jobs worden afgerond.

Schat de verwerkingscapaciteit in op basis van waargenomen gegevens

Als de aanhoudende uitstroomsnelheid hoger is dan de instroomsnelheid, kan de queue kleiner worden zolang dat verschil blijft bestaan. Als operationele benadering hangt de tijd die nodig is om de backlog te verwerken af van het aantal openstaande jobs gedeeld door de nettoverwerkingscapaciteit: de uitstroomcapaciteit minus de instroom over dezelfde periode. Als dat verschil nul of negatief is, lost een langere wachttijd de ophoping niet op.

Deze schatting is indicatief en geen belofte van een specifiek hersteltijdstip. Ze gaat ervan uit dat het tempo gelijk blijft en dat de jobs een vergelijkbare samenstelling en verwerkingskosten hebben. Een klein aantal lange jobs, retries of limieten van een afhankelijkheid kan de uitkomst veranderen. Gebruik snelheden die onder echte belasting zijn gemeten en maak na elke ingreep een nieuwe schatting. Bereken voor taken met uiteenlopende verwerkingskosten de waarden per taakklasse, of meet de servicetijd in plaats van alleen het aantal berichten.

Grijp stapsgewijs en met duidelijke limieten in

Geef voorrang aan omkeerbare en begrensde maatregelen. Spreek voordat je het aantal consumers wijzigt af welke impact elke afhankelijkheid kan verdragen en hoe je de wijziging terugdraait.

1. Beperk indien mogelijk nieuwe instroom: pauzeer niet-essentiële producers, stel limieten in of stel taken met lage prioriteit uit. Gooi geen jobs weg zonder een bedrijfsregel, registratie en herstelmechanisme.
2. Isoleer problematische jobs: beperk het aantal pogingen, pas waar nodig een oplopende wachttijd toe en stuur aanhoudende fouten door naar een error-queue die kan worden gecontroleerd. Negeer deze jobs niet: ze kunnen een correctie en herverwerking vereisen.
3. Bescherm prioriteiten: scheid urgente taken van onderhoudstaken of bulkverwerking, en controleer of lagere prioriteiten niet onbepaalde tijd in de queue blijven wachten.
4. Pas de concurrency geleidelijk aan: wijzig het aantal consumers in kleine stappen en monitor de prestaties en verzadiging. Houd limieten aan die passen bij het aantal beschikbare verbindingen, CPU, geheugen en quota van externe services.
5. Verhelp de oorzaak: los trage queries, blokkades of calls zonder timeout op voordat je meer processen parallel laat werken.

Idempotentie is vooral belangrijk wanneer een job meer dan één keer kan worden uitgevoerd. Ontwerp externe effecten en schrijfbewerkingen zo dat ze retries kunnen verdragen, of gebruik geschikte deduplicatiemechanismen. Controleer ook wat er gebeurt als de consumer stopt nadat het effect is uitgevoerd, maar voordat het bericht is bevestigd.

Stel drempelwaarden en een herstelprocedure vast

Stel drempelwaarden vast op basis van de servicevereisten, niet op basis van een universeel getal. Een alert kan de maximale ouderdom of het wachtpercentiel combineren met de trend van de backlog, het verschil tussen instroom en uitstroom en het foutenpercentage. De ouderdom houdt doorgaans sterker verband met de impact voor gebruikers dan een losse telling; het volume helpt de omvang in te schatten.

Leg vast wie ingrijpt, welke queues diegene mag pauzeren, welke afhankelijkheden moeten worden geraadpleegd en voor welke wijzigingen goedkeuring nodig is. Noteer tijdens het incident het tijdstip, de hypothese, de actie en het waargenomen effect. Controleer na elke aanpassing of de uitstroomsnelheid toeneemt zonder dat de databaselatency, externe fouten, het resourcegebruik of het aantal applicatiefouten onaanvaardbaar stijgt.

Beschouw het herstel als bevestigd wanneer de ouderdom en het volume aanhoudend afnemen, jobs succesvol worden afgerond en afhankelijkheden weer stabiel zijn. Verklaar het probleem niet opgelost alleen omdat de teller daalt: berichten kunnen zijn weggegooid of zich in een andere queue hebben opgehoopt.

Checklist om een volgende ophoping te voorkomen

• Worden instroom, nuttige uitstroom, ouderdom, verwerkingsduur en retries per queue gemeten?
• Hebben jobs timeouts en een eindig, passend retrybeleid?
• Zijn er alerts voor gebrek aan voortgang, en niet alleen voor het volume?
• Respecteert de maximale concurrency de limieten van gedeelde afhankelijkheden?
• Kan een problematische taakklasse worden geïsoleerd zonder de volledige verwerking stil te leggen?
• Is er een gedocumenteerde procedure om veilig te pauzeren, te hervatten en opnieuw te verwerken?
• Worden metrics en neveneffecten gecontroleerd na wijzigingen in code, belasting of configuratie?

Een gezonde queue is niet noodzakelijk een lege queue: normale schommelingen zijn mogelijk. Het praktische criterium is dat jobs binnen het beoogde serviceniveau worden afgerond, fouten zichtbaar zijn en het systeem voldoende marge heeft om pieken op te vangen. Door dit gedrag te meten, kun je ingrijpen voordat een ophoping voor gebruikers tot een onderbreking leidt.