Resourcebeheer

Queuety verdeelt resourcebeheer in vier kernlagen, met optionele poolgrootte-instellingen daarbovenop.

De eerste laag beschrijft hoe kostbaar één werkeenheid is. De tweede beperkt hoeveel gedeelde belasting één wachtrij of providergroep tegelijk mag dragen. De derde bepaalt hoeveel één workflowuitvoering mag verbruiken. De vierde bepaalt of een worker de volgende opgehaalde taak meteen moet starten of deze moet uitstellen totdat het huidige proces en de huidige container nog voldoende ruimte hebben.

Deze lagen werken samen. Een handler kan aangeven dat deze bij een gedeelde pool hoort die veel resources verbruikt, een wachtrij kan voor één provider slechts een beperkte hoeveelheid gewogen werk reserveren, een workflow kan begrenzen hoeveel van dat werk deze mag aanmaken, en de worker kan alsnog weigeren meer van dat werk te starten wanneer het huidige proces of de huidige container de limieten al bijna bereikt.

De kosten van één werkeenheid beschrijven

Taken, workflowstappen en acties bij statusovergangen kunnen allemaal dezelfde drie resourceaanwijzingen meegeven:

• concurrency_group
• concurrency_limit
• cost_units

concurrency_group en concurrency_limit beschrijven de gedeelde belasting van één downstreamsysteem. Als verschillende handlers dezelfde provider, hetzelfde API-account of dezelfde tenant gebruiken, kunnen ze dezelfde groep gebruiken zodat workers niet te veel tegelijk starten.

cost_units beschrijft het relatieve gewicht. Een cacheverversing en een grote aanroep van een provider zijn allebei misschien “één taak”, maar moeten niet even zwaar meetellen wanneer een workflowbudget of toelatingsregel voor workers bepaalt of meer werk nog verantwoord is.

final class CallProviderStep implements \Queuety\Step
{
    public function handle( array $state ): array
    {
        // ...
    }

    public function config(): array
    {
        return [
            'concurrency_group' => 'providers',
            'concurrency_limit' => 3,
            'cost_units' => 5,
        ];
    }
}

Hetzelfde geldt voor verstuurbare taken via klasse-eigenschappen en voor afzonderlijke taakverzendingen via PendingJob::concurrency_group() en PendingJob::cost_units().

Budgetten voor gedeelde wachtrijen en providergroepen

Gedeelde belasting gaat niet altijd over een eenvoudig aantal gelijktijdige taken. Soms wordt de belasting vooral bepaald door het totale gewicht van het werk dat al wordt uitgevoerd.

Queuety ondersteunt dit met gewogen budgetten voor wachtrijen en groepen. Wachtrijbudgetten zijn gekoppeld aan de wachtrijnaam. Groepsbudgetten zijn gekoppeld aan concurrency_group, zodat niet-verwante handlers dezelfde gedeelde limiet kunnen gebruiken.

define( 'QUEUETY_RESOURCE_QUEUE_COST_BUDGETS', [
    'providers' => 20,
    'exports' => 8,
] );

define( 'QUEUETY_RESOURCE_GROUP_COST_BUDGETS', [
    'openai' => 12,
    'tenant:acme' => 6,
] );

Wanneer een worker een taak ophaalt, controleert deze de actieve rijen van processing die al bij die wachtrij of groep horen. Als de huidige uitvoeringskosten plus het cost_units van de opgehaalde taak het ingestelde budget zouden overschrijden, geeft de worker de taak vrij en probeert deze het later opnieuw.

Zo krijgt u een andere vorm van controle dan met concurrency_limit. Een provider kan drie gelijktijdige verzoeken toestaan, maar toch minder totale kosteneenheden reserveren voor grotere verzoeken dan voor kleinere.

Houd één workflow binnen de grenzen

Workflowbudgetten zijn bedoeld voor situaties waarin het probleem niet één zware taak is, maar een uitvoering die steeds meer werk ontdekt dan de bedoeling was.

Dit komt vaak voor in agentsystemen. Een planner kan dezelfde kostbare tak opnieuw doorlopen, te veel subtaken voor elk onderdeel maken of onderliggende workflows blijven starten, terwijl deze technisch gezien binnen een normaal model voor nieuwe pogingen blijft.

Queuety biedt hiervoor limieten op workflowniveau:

Queuety::workflow( 'research_run' )
    ->max_transitions( 20 )
    ->max_for_each_items( 12 )
    ->max_state_bytes( 32768 )
    ->max_cost_units( 40 )
    ->max_started_workflows( 8 )
    ->then( PlanResearchStep::class )
    ->for_each( 'tasks', ExecuteResearchTask::class, 'results' )
    ->dispatch();

max_cost_units() voorkomt dat de uitvoering meer gewogen werk verbruikt dan de bedoeling is. max_started_workflows() voorkomt dat een bovenliggende workflow uitgroeit tot een onbegrensde boom van uitvoeringen op hoofdniveau. De andere beveiligingen blijven ook nodig, omdat niet elke workflow die op hol slaat op dezelfde manier veel resources verbruikt.

De workflowstatus geeft de ingestelde limieten en het huidige verbruik weer via de openbare payload budget, zodat u de uitvoering kunt blijven inspecteren zolang die limieten actief zijn.

Laat workers werk uitstellen wanneer het proces al te vol zit

Zelfs wanneer metadata en workflowbudgetten goed zijn ingesteld, ligt de uiteindelijke beslissing bij het workerproces dat de taak gaat uitvoeren.

Daar komt resourcebewuste toelating van pas. Voordat een opgehaalde taak wordt gestart, kan Queuety het volgende controleren:

• de gedeelde gelijktijdigheidsgroep van de taak
• gewogen budgetten voor wachtrijen en providergroepen
• recente uitvoeringsduur en piekgeheugengeschiedenis van de handler
• de resterende geheugenruimte van de huidige worker
• de resterende geheugenruimte van de huidige container of host
• de resterende tijd binnen het tijdsvenster voor uitvoeringen in één keer

Als de worker de ingestelde limiet al bijna bereikt, geeft Queuety de taak vrij in plaats van werk te starten dat waarschijnlijk niet netjes wordt afgerond.

Dit is bewust voorzichtig ingesteld. Het is geen volledige clusterscheduler. Het is een beveiligingslaag die een drukke worker helpt voorkomen dat deze het proces waarin die draait overbelast en, wanneer er geheugentelemetrie beschikbaar is, ook de container of host eromheen.

Het onderdeel voor containers of hosts is optioneel. Wanneer QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS is ingeschakeld, probeert Queuety eerst cgroup-geheugengegevens te lezen en valt deze op /proc/meminfo terug op Linux-hosts. Als er geen betrouwbare momentopname op systeemniveau beschikbaar is, blijft de worker de controles voor het lokale proces gebruiken.

Werkerpools schalen zonder capaciteit te negeren

Vaste workerpools zijn eenvoudig te begrijpen, maar dwingen u ook één aantal te kiezen voor zowel rustige perioden als pieken.

Met adaptieve pools kunt u in plaats daarvan een minimum en maximum instellen:

wp queuety work --queue=providers --min-workers=2 --max-workers=6

Het bovenliggende proces houdt minstens het minimumaantal onderliggende processen actief, schaalt op richting het maximum wanneer de achterstand aan ophaalbare taken toeneemt en schaalt weer af nadat de wachtrij gedurende het ingestelde respijtvenster voor inactiviteit rustig is gebleven.

Opschalen houdt nog steeds rekening met de beschikbare capaciteit. Als bewustzijn van het systeemgeheugen is ingeschakeld en het bovenliggende proces niet genoeg resterend geheugen ziet voor een volledige extra worker, houdt het de pool op de huidige grootte in plaats van meer onderliggende processen te starten.

Een realistische combinatie van de lagen

Stel u een onderzoeksworkflow voor die aanroepen van providers plant, specialistische workflows start en daarna het resultaat samenvoegt.

De stap die met de provider communiceert, kan cost_units en een gedeelde concurrency_group aanbieden, zodat meerdere workers niet tegelijk dezelfde modelprovider overspoelen. De wachtrij kan een gewogen budget voor dat providerverkeer reserveren. De bovenliggende workflow kan max_cost_units() en max_started_workflows() begrenzen, zodat een planner de uitvoering niet eindeloos kan uitbreiden. De worker kan een nieuw opgehaalde aanroep naar de provider vervolgens nog steeds uitstellen als recente gegevens over piekgeheugen aangeven dat het proces of de container de limiet al bijna bereikt.

Zo krijgt u vier afzonderlijke controles:

1. beschrijf het gewicht van het werk
2. reserveer gedeelde capaciteit voor de wachtrij of provider
3. beperk hoeveel één uitvoering mag aanmaken
4. voorkom dat een zwaarbelaste worker meer start dan verantwoord is

Waar u de gedetailleerde API's vindt

Deze pagina biedt een conceptueel overzicht.

Voor de concrete instellingen:

• Workers behandelt toelatingsgedrag en runtimeconstanten
• CLI behandelt opdrachten voor vaste en adaptieve workerpools
• Workflowbeveiligingen behandelt workflowbudgetten
• Taken behandelt metadata voor taken en handlers
• Statusmachines behandelt resourcemetadata voor statusacties
• API bevat de exacte methoden en resultaatvormen