Hoeveel kan het aan? Runs die tegelijk lopen

Hoeveel runs kan uw workflowtool tegelijk aan? Vraag het aan drie mensen in uw team. Misschien krijgt u drie antwoorden, of geen enkel.

Eén team stelde precies die vraag op een openbaar forum, voordat het servers kocht voor workflows met spraakagents. Bij het gehoste abonnement hing de limiet af van het abonnement. Voor de versie die het team zelf zou draaien, wilde het eerst meten hoeveel belasting die aankon, voordat het koos hoe groot de servers moesten zijn, en het vroeg mensen die de tool in productie draaien om hun cijfers.

Het is de juiste vraag. De meeste teams stellen hem te laat: nadat een lange taak in een time-out is gelopen, of nadat het werk van de ene klant dat van een andere klant heeft opgehouden.

Eén team meldde drie geplande workflows die elke ochtend met een minuut ertussen starten. Op ongeveer zes van de tien ochtenden crashten ze alle drie tegelijk, binnen een paar seconden. Dezelfde workflows slaagden drie uur later altijd. De run meldde alleen "Unknown error". De melder stelde twee eenvoudige vragen: is er een geheugenlimiet, en zo ja, hoe hoog is die en wat kan het team eraan doen? Toen wij de melding lazen, had nog geen maintainer van het project erop gereageerd.

Een gebruiker die één installatie voor meerdere klanten draaide, meldde dat het een week duurde voordat duidelijk werd waarom één klant bleef klagen dat webhooks wegvielen. De oorzaak zat in het werk van een andere klant: een polling-lus van ongeveer twee minuten die al het andere werk ophield.

Een derde gebruiker ontdekte dat zodra de limiet van de eigen tool voor runs die tegelijk lopen was bereikt, binnenkomende webhook-aanroepen helemaal geen antwoord meer kregen. De health checks slaagden nog steeds, dus de monitoring zag niets mis.

In elk geval was de limiet echt. Niemand kon hem zien tot er iets tegenaan liep.

Wat er gebeurt als één workflow de hele server platlegt, leest u in De workflow die al het andere meenam in zijn val.

Een tool vangt belasting op zoals een winkel klanten opvangt. Er zijn een aantal kassa's open. Een lange bestelling houdt één kassa bezet. Als elke kassa bezet is, wacht de volgende klant, en sommige klanten lopen weg.

Drie dingen bepalen dus hoeveel belasting uw opzet aankan. Hoeveel runs tegelijk kunnen lopen. Wat die runs delen terwijl ze lopen. En wat u kunt uitzetten of stoppen als er een misgaat.

Het deel dat de kassa's verdeelt, is de harness, de laag rond het model die uw agents en uw flows laat draaien. Wie controleert of die laag doet wat hij belooft, leest u in wie controleert de agent-harness.

Stel deze vragen over de versie die u zou installeren, op hardware zoals de uwe. Ons eigen antwoord staat bij elke vraag. Een agentstap is een stap waarin een model werkt met instructies en tools (zie wat een AI-agent is). EpicStaff noemt een run een sessie. De beheerder is de persoon die de installatie draait.

Hoeveel runs kunnen tegelijk lopen, en wie beslist dat? EpicStaff: de beheerder stelt in hoeveel runs tegelijk lopen, met één getal voor de hele installatie.

Houdt één lange stap andere runs op? EpicStaff: deels. Een lange stap houdt andere runs niet tegen om te starten, tot het aantal runs dat tegelijk mag lopen; daarboven wachten nieuwe runs op een vrije plek. Agentstappen uit alle runs delen dezelfde plekken voor agentwerk, dus veel lange agentstappen laten de agentstappen van andere runs wachten.

Kan ik één workflow uitzetten zonder alles te stoppen? EpicStaff: deels. EpicStaff heeft geen aan/uit-schakelaar voor een hele flow. Een schematrigger kan op zichzelf worden uitgezet, en de koppeling van een flow met de chatwidget kan worden uitgeschakeld. Webhook- en Telegram-triggers hebben geen schakelaar: ze starten de flow zodra er een geldige aanroep binnenkomt.

Kan ik één run stoppen zonder de rest aan te raken? EpicStaff: ja. Elke lopende sessie kan worden gestopt zonder de installatie aan te raken: vanuit de sessielijst, de pagina met alle sessies of het scherm van de lopende flow, of via de API. Andere runs lopen gewoon door.

Hoe voeg ik capaciteit toe? EpicStaff: op één host. EpicStaff verdeelt runs niet voor u over meer servers: de geleverde opzet draait één exemplaar van elke dienst op één host. De beheerder kan op die host meer gelijktijdigheid instellen: meer werkprocessen voor de hoofd-API, de spraakdienst en de kennisdienst, en runlimieten voor flows en voor agentwerk. De twee runlimieten bepalen hoeveel flow-runs tegelijk lopen (standaard 25) en hoeveel agentstappen tegelijk lopen (standaard 10).

Vraag bij elke tool, als u naar het stoppen vraagt, ook hoe snel het werkt. Een stop die binnen seconden ingrijpt, is iets anders dan een stop die wacht tot de stap klaar is.

Een leverancier kan u vertellen welke instellingen er zijn. Alleen een test vertelt u wat uw server met uw flows doet. Doe het op een rustige dag, op een kopie, nooit op de server die uw klanten gebruiken.

1. Kopieer één echte flow. Houd er een echte agentstap en een echte tool-aanroep in. Een test met lege stappen meet niets waar u later mee te maken krijgt.
2. Start runs tegelijk, in rondes. Een paar, dan meer, dan nog meer. Noteer per ronde hoe lang de runs nodig hebben om te starten en om klaar te zijn.
3. Voeg aan één run één lange stap toe. Kijk naar de andere. Starten ze? Wachten hun agentstappen?
4. Schrijf de instellingen bij elk resultaat. Een getal zonder de instellingen van de beheerder ernaast zegt niets meer na de volgende wijziging.
5. Herhaal dezelfde test na elke upgrade. Een snelheid die vorige maand standhield, houdt misschien geen stand na een upgrade, en niets zal het u vertellen.

Hoeveel runs kan uw tool dus tegelijk aan? Na deze test kunt u een echt antwoord geven: een getal, gemeten op uw eigen server met uw eigen flows, met de instellingen die het opleverden ernaast. Leg dat antwoord vast waar de volgende die het vraagt het vindt.