Cloud-VM’s en cloudbrowsers worden per tijdseenheid afgerekend, waardoor batchtaken snel tegen quota kunnen aanlopen. Schat het verbruik, bepaal een praktisch maximum voor gelijktijdigheid en herstel in een vaste volgorde wanneer het quota is opgebruikt.
Bij resources die op tijd worden afgerekend, is de facturering eenvoudig: looptijd maal het aantal instances. Het quota is een harde bovengrens. Zodra je die raakt, worden taken niet alleen trager maar mislukken ze direct: nieuwe instances kunnen niet worden aangemaakt, actieve instances kunnen worden teruggenomen en API's beginnen rate-limitfouten terug te geven. Weten hoeveel ruimte je nog hebt tot de grens is nuttiger dan achteraf alleen het budget verhogen.
Bepaal eerst welk verbruik echt nodig is
Hetzelfde quota kan per taak een heel andere opbrengst hebben. Maak daarom eerst een inventaris en verdeel taken op basis van de vraag of ze echt in realtime moeten worden uitgevoerd.
Permanente taken behoren tot de grootste quotaverbruikers. Ze draaien de hele dag terwijl ze misschien maar een paar minuten werkelijk werk doen. Door continue monitoring om te zetten naar geplande triggers kun je vaak een groot deel van het verbruik schrappen zonder merkbare impact op de bedrijfsvoering. Piektaken die in bepaalde tijdvakken samenkomen kunnen worden verschoven, en eenmalige taken kunnen alleen op verzoek starten.
Stel jezelf daarna één vraag: heeft het gevolgen voor de bedrijfsvoering als deze taak zes uur later wordt uitgevoerd? Zo ja, houd haar op het kritieke pad en voer haar realtime uit. Zo nee, maak er een batch met lage prioriteit van en plan die in een periode met meer quotaruimte. Concurrentieprijzen in plaats van elk uur nog maar twee keer per dag controleren, vermindert in de meeste situaties de informatiewaarde niet wezenlijk.
Verbruik schatten en gelijktijdigheid bepalen
Als je betaalt voor de looptijd van instances, is het totale verbruik van een batch ongeveer de gemiddelde duur van één taak maal het aantal taken. Dat verandert niet door meer gelijktijdigheid; gelijktijdigheid bepaalt alleen hoe snel de batch klaar is. Wat wel met gelijktijdigheid samenhangt, is de druk op een bepaald moment: hoe meer instances tegelijk starten, hoe sneller je de concurrencylimiet van de resourcepool of de rate limiting van het platform raakt.
Begin daarom met de laagste gelijktijdigheid. Voer eerst één taak uit en controleer de gemiddelde duur en het slagingspercentage. Verhoog daarna stap voor stap naar enkele en vervolgens een tiental taken en noteer foutpercentages en aantallen retries. Als het foutpercentage vanaf een bepaald punt duidelijk stijgt, heb je de praktisch bruikbare bovengrens gevonden. Nog verder verhogen geeft de gewonnen tijd alleen via extra retries weer terug.
Vergeet bij je schatting geen verborgen tijd: wachten op aanmelden, pagina's laden, verificatiestappen en mislukte retries duren vaak langer dan de hoofdworkflow zelf. Een marge per taak reserveren is nuttiger dan alles op de minuut proberen uit te rekenen.
Hoe een uitgeput quota eruitziet
Een uitgeput quota is soms lastig te herkennen, omdat de symptomen vaak op andere problemen lijken.
Een mogelijkheid is dat een taak tijdens het starten blijft hangen omdat het verzoek om een omgeving of instance te maken wordt geweigerd en er alleen een vage foutmelding in de logs staat. Een andere mogelijkheid is dat een instance halverwege wordt teruggenomen, waardoor eerder werk verloren gaat. Je kunt ook rate-limitfouten zien, een mix van geslaagde en mislukte taken of een wachtrij die steeds langer wordt zonder dat iemand hem verwerkt.
Het makkelijkst verkeerd te interpreteren is een schijnbare vastloper: de instance bestaat nog en de taak lijkt te draaien, maar wacht in werkelijkheid voortdurend terwijl het quota met de tijd blijft afnemen. Controleer dan eerst het paneel met quotagebruik en probeer daarna één kleine taak apart. Kan ook die niet starten, zoek dan bij quota of rechten. Werkt die wel normaal, dan ligt het waarschijnlijker aan gelijktijdigheid of hergebruik van omgevingen.
Volgorde van herstelmaatregelen
Begin met acties die niets kosten.
Stop ten eerste permanente consumptie met weinig waarde en maak monitoringstaken gepland. Verplaats ten tweede taken die vertraging verdragen naar perioden met meer beschikbare quota, zodat de verbruikscurve vlakker wordt. Verlaag ten derde de gelijktijdigheidslimiet en voeg een wachtrij toe, zodat taken volgens de beschikbare capaciteit worden verwerkt in plaats van allemaal tegelijk te starten. Verminder ten vierde verspilling: cache dezelfde resources in plaats van ze steeds opnieuw op te halen, haal waar zinvol meer gegevens per verzoek op, stop verzoeken die zeker zullen mislukken snel en blijf ze niet eindeloos opnieuw proberen.
Bekijk pas na deze vier stappen of je meer budget of een hoger serviceniveau nodig hebt. Vaak blijkt dat het werkelijk benodigde quota lager is dan je aanvankelijk dacht. Verhoog je eerst het budget, dan koop je inefficiënte gewoonten meteen mee.
Druk de omgevingslaag niet samen met de computelaag
Een veelgemaakte fout bij het besparen op quota is meerdere taken dezelfde browseromgeving laten delen, met als redenering dat één keer starten genoeg zou moeten zijn.
De nadelen verschijnen meteen: sessies overschrijven elkaar, aanmeldstatussen worden verdrongen, caches lopen door elkaar en één mislukte taak kan de rest meesleuren. De kleine besparing op instancetijd betaal je vervolgens dubbel en dwars terug in probleemoplossing en herhaalde runs.
Bekijk deze twee lagen afzonderlijk. De computelaag voert taaklogica uit, plant werk op aanvraag en optimaliseert voor kostenefficiëntie. De omgevingslaag beheert identiteit en isolatie, met één onafhankelijke omgeving per taak, en optimaliseert voor stabiliteit. De omgevingslaag comprimeren omdat rekenkracht schaars is, haalt twee verschillende kosten door elkaar. Het in bulk aanmaken en terugnemen van omgevingen hoort centraal door tooling van de omgevingslaag te worden beheerd. Wanneer PurpleMark sessies en caches per omgeving isoleert, kunnen taken en executors in de bovenliggende laag vrijer worden ingepland.
Tot slot: bespaar niet door regels te overtreden. Gebruik geen onofficiële diensten alleen om quota te sparen en probeer geen extra doorvoer af te dwingen door vaker verzoeken te sturen. Zodra rate limiting wordt geactiveerd, kosten retries meestal meer quota dan werken op een beheerst tempo.
