Schaalbaarheidspatronen
Lees meer over EPS Kisten van 75 x 60cm (5 kg) →
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Efficiëntie van SOQL-query | Consolideer query’s met behulp van relatiequery’s (Contactpersonen, Cases__r) in plaats van afzonderlijke query’s per gerelateerd object. Voer eenmaal per transactie een query uit op alle benodigde gegevens. Doel <50 query’s in synchrone transacties, <100 asynchroon (limieten: 100 synchronisatie, 200 asynchroon). Handhaaf 30-50% buffer onder limieten. |
| bulkverwerking van DML-bewerkingen | Verzamel records in lijsten en voer één DML-instructie per objecttype per transactie uit. Gebruik Database.insert/update/delete met de parameter allOrNone die de werking van gedeeltelijk succes bepaalt. Doel <75 DML-instructies per transactie (limiet: 150). Batch reduceert DML-verbruik van N-instructies naar 1. |
| Heapgroottebeheer | Voer alleen een query uit op verplichte velden (vermijd SELECT *-patronen). Verwerk grote resultaatsets in blokken. Verzamelingen na verwerking wissen naar vrij geheugen. Doel <4MB heap in synchrone context (limiet: 6MB), <8MB asynchroon (limiet: 12MB). Heap overschreden fouten geven de noodzaak aan van blok- of streamingpatronen. |
| CPU-tijdoptimalisering | Minimaliseer de complexiteit van berekeningen in lussen. Gebruik Kaarten voor opzoekopdrachten (O(1)) in plaats van geneste lijstherhaling (O(n2)). Zware berekeningen verplaatsen naar asynchrone context. Doel <7.000ms CPU in synchrone transacties (limiet: 10,000ms), <40,000ms asynchroon (limiet: 60.000ms). |
| SOQL-queryrijen | Ontwerpquery’s die een redelijke grootte van de resultatenset retourneren. Gebruik de LIMIT-clausule om resultaten te beperken. Doel <25.000 rijen per query in synchrone context (limiet: 50,000). Query’s die limieten benaderen, moeten paginering gebruiken of overschakelen naar asynchrone verwerking met Batch Apex of Queueable. |
| API-aanroeptoewijzing | Bewaak 24-uurs API-limietverbruik via Systeemoverzicht. Batch-API-bewerkingen in plaats van record-voor-record aanroepen. Vaak geopende verwijzingsgegevens in het cachegeheugen opslaan met behulp van platformcachegeheugen. Doel <70% van de dagelijkse API-limiet om pieken op te vangen. API-limiet varieert per edition en licentietelling. |
| Aanroeplimieten | Externe aanroepen consolideren: batch meerdere records in één API-verzoek wanneer het externe systeem dit ondersteunt. Implementeer verzoekwachtrijen om aanroepen te serialiseren. Respecteer de totale aanroeptijd van 120 seconden per transactie. Limiet: 100 aanroepen per transactie. Ontwerp asynchrone verwerking voor integraties met veel aanroepen. |
| Code (Apex, Aura, LWC) | Bulkverwerkingspatronen implementeren: verwerk verzamelingen niet afzonderlijke records, voer één query uit en cache in Maps, voer één DML per objecttype uit. Gebruik relatiequery’s om SOQL-verbruik te minimaliseren. Pas efficiënte algoritmen toe om geneste lussen voor grote gegevenssets te vermijden. |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| SOQL in lussen | Probleem: SOQL-query’s binnen uitvoeren voor lussen die recordverzamelingen verwerken. Impact: Querylimiet overschreden fout bij meer dan 100 records (limiet: 100 query’s per transactie). Resolutie: Voer één query uit vóór lus, sla resultaten op in het veld Toewijzen op basis van relatie. Opzoeken vanuit Kaart binnen lus (bulkvormingspatroon). |
| DML in lussen | Probleem: Instructies voor invoegen/bijwerken/verwijderen binnen uitvoeren voor lussen. Impact: DML-limiet overschreden fout bij 150+ records (limiet: 150 DML-instructies per transactie). Resolutie: Verzamel records in Lijst binnen lus en voer één DML-instructie uit nadat de lus is voltooid. |
| Geen buffer voor beheerlimiet | Probleem: Transacties ontwerpen die 95%+ van de beheerlimieten verbruiken onder normale omstandigheden. Impact: Productiefouten tijdens lichte belastingsverhogingen, geen capaciteit voor randkoffers. Resolutie: Beoog 70% van de limieten als operationeel plafond. Reserveer 30% buffer voor spikes en edge cases. |
| Geneste lus cartesische producten | Probleem: Geneste lussen die twee grote verzamelingen herhalen en O(n2)-bewerkingen maken. Impact: CPU-limiet overschreden fouten, heaplimiet overschreden van tijdelijke objecten. Resolutie: Gebruik op kaarten gebaseerde opzoekopdrachten die O(n2) converteren naar O(n). Verzamel buitenste lussleutels, voer één query op gerelateerde records uit en zoek op in binnenste lus. |
| Heapaccumulatie | Probleem: Grote queryresultaten in het geheugen laden zonder verwerking in blokken. Impact: Heaplimiet overschreden fout (6MB synchronisatie, 12MB asynchroon). Resolutie: Query alleen benodigde velden. Verwerk in batches het wissen van verzamelingen na elke batch. Gebruik QueryLocator met Batch Apex voor de verwerking van miljoenen records. |
| Geen filtering op veldniveau | Probleem: Alle velden (expliciet of impliciet) selecteren wanneer alleen subset nodig is. Impact: Overmatig heapverbruik, tragere uitvoering van query’s, SOQL-rijlimiet onnodig benaderd. Resolutie: SELECTeer alleen velden die verplicht zijn voor verwerking. Gebruik relatienotatie om gerelateerde gegevens op te halen in één query in plaats van afzonderlijke query’s. |
| Overmatig gebruik van synchrone verwerking | Probleem: Grote gegevensvolumes synchroon verwerken binnen gebruikerstransacties. Impact: Gebruiker wacht op bewerkingen van meerdere seconden, CPU-/heaplimieten overschreden blokkerende gebruiker. Resolutie: Zware verwerking verplaatsen naar asynchrone context (batch, wachtrij, platformevents). Bied gebruikers onmiddellijke respons met statuspeilingen. |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Asynchrone verwerking | Gebruik Batch Apex voor de verwerking van grote recordvolumes (miljoenen). Gebruik Apex voor wachtrijen voor complexe doeltreffende combinatie van meerdere stappen met koppelen. Gebruik Platform-events voor eventgestuurde ontkoppeling. Gebruik Gepland Apex voor periodiek onderhoud. Asynchroon patroon afstemmen op gebruikscase: Batch voor volume, In wachtrij te plaatsen voor complexiteit, Events voor ontkoppeling. |
| Batch Apex implementatie | Ontwerpmethode die selectieve QueryLocator retourneert om verwerkte records te minimaliseren. Configureer batchgrootte op basis van recordcomplexiteit (200-2.000 records per uitvoering). Implementeer stateful interface alleen wanneer nodig, omdat dit de doorvoer vermindert. Bewaak AsyncApexJob op succes/mislukt. Batch biedt speciale beheerlimieten per blok. |
| Platform-eventsarchitectuur | Publiceer events voor statuswijzigingen die verwerking verderop in de stroom vereisen. Abonneer u met behulp van Apex triggers op platform event objecten of externe abonnees via CometD. Ontwerp idempotente abonnees (herhaling kan events meerdere keren opleveren). Gebruik 72 uur retentie voor herstel van tijdelijke abonneefouten. |
| Op datum gebaseerde partitionering | Verwerk gegevens in tijdsbestekken: huidige maand, afgelopen kwartaal, dit jaar. Archiveer historische gegevens naar Big Objects of externe opslag. Met op tijd gebaseerde partitionering kunnen parallelle batchtaken verschillende datumbereiken tegelijkertijd verwerken. De meeste query’s filteren natuurlijk op datum, wat dit efficiënt maakt. |
| Recordtype partitionering | Verwerk verschillende recordtypen onafhankelijk. Plan afzonderlijke batchtaken per recordtype en schakel parallellisatie in. Recordtypen correleren vaak met afzonderlijke bedrijfsprocessen die onafhankelijke verwerking rechtvaardigen. Maximaal 5 gelijktijdige batchtaken per organisatie vereist strategische partitionering. |
| Op geografie gebaseerde partitionering | Partitionering op eigenaar, divisie of territorium voor het verwerken van distributie. Verwerk elke regio, bedrijfseenheid of verkoopterritorium in parallelle batchtaken. Op geografie gebaseerde partitionering maakt gebruik van het sharemodel: elke batchtaak wordt uitgevoerd in de context van een specifieke gebruikersgroep die op natuurlijke wijze gegevens filtert. |
| Cachingstrategie | Gebruik Platformcachegeheugen (organisatie/sessiepartities) voor vaak geopende naslaggegevens. Cachegeheugen vermindert query- en API-verbruik. Wijs organisatie- en sessiepartities toe in stappen van hele MB; standaardcapaciteit varieert per edition, waarbij extra capaciteit kan worden aangeschaft in blokken. Cachefout moet elegant terugvallen op query. Cache-TTL moet overeenkomen met gegevenswijzigingsfrequentie: uren voor statische verwijzingsgegevens, minuten voor semidynamisch. |
| Stroombulkverwerking | Ontwerpstromen die recordverzamelingen verwerken met behulp van variabelen Lus en Verzameling. Maak een verzameling records, voer één record ophalen uit, werk de verzameling bij met één element Records bijwerken. Vermijd afzonderlijke recordbewerkingen binnen lussen. Stroombulkpatronen weerspiegelen best practices van Apex. |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Alleen sequentiële verwerking | Probleem: Enkelvoudige batchtaak die alle 50 miljoen records sequentieel verwerkt en 24+ uur in beslag neemt. Impact: Blokkeert andere verwerking, uitputting van onderhoudsvensters, vertragingen voor de gebruiker. Resolutie: Partitioneringsgegevens op datum, recordtype of geografie. Voer parallelle batchtaken uit waarbij onafhankelijke partities tegelijkertijd worden verwerkt. |
| Synchrone integratieafhankelijkheden | Probleem: Gebruikerstransacties geblokkeerd die wachten op externe systeemreacties via synchrone aanroepen. Impact: Gebruikerservaring gekoppeld aan externe systeemprestaties, time-outfouten tijdens externe uitval. Resolutie: Gebruik Platform-events voor asynchrone integratie. Koppel gebruikerstransactie los van beschikbaarheid van extern systeem. |
| Geen cachinglaag | Probleem: Herhaaldelijk query’s uitvoeren op dezelfde verwijzingsgegevens binnen transacties. Impact: Overmatig SOQL-verbruik, API-limietverspilling, tragere transactie-uitvoering. Resolutie: Implementeer Platformcachegeheugen voor vaak geopende referentiegegevens. Cache vermindert verbruik van beheerlimieten en verbetert prestaties. |
| Stapelen van batchtaken | Probleem: 20+ batchtaken plannen die gelijktijdig beginnen. Impact: Opbouw van wachtrijdiepte, 5 gelijktijdige taaklimieten veroorzaakt serialisering, onvoorspelbare voltooiingstijden. Resolutie: Gefaseerde planningen die de belasting over uren verdelen. Consolideer soortgelijke taken in één batch met dynamische verzendingslogica. |
| Staat/provincie overmatig gebruik | Probleem: Batch Apex implementeren met Database.Stateful wanneer niet vereist. Impact: Onnodige serialisering van instantielidvariabelen over execute()-aanroepen en potentiële heapaccumulatie vanuit behouden status. Resolutie: Gebruik stateful alleen wanneer state moet blijven bestaan voor het uitvoeren van aanroepen. Geef de voorkeur aan batches zonder staat/provincie om onnodige overhead voor serialisering van staat/provincie te voorkomen. |
| Stroomontwerp met enkele schroefdraad | Probleem: Stroomverwerkingsrecords één voor één binnen Lus met afzonderlijke elementen Record ophalen/bijwerken per herhaling. Impact: Beheerderslimietverbruik proportioneel aan recordtelling, transactiefouten op schaal. Resolutie: Records verzamelen in verzamelingsvariabele, enkelvoudige Records ophalen uitvoeren, verzameling bijwerken met enkelvoudige element Records bijwerken buiten lus. |
| Strategie voor opnieuw asynchroon proberen | Probleem: Mislukte asynchrone taken worden niet automatisch opnieuw geprobeerd en vereisen handmatige interventie. Impact: Gegevensinconsistenties, handmatige operationele lasten, SLA-missers. Resolutie: Implementeer automatisch opnieuw proberen met exponentiële backoff. Gebruik Platform-events voor duurzaam opnieuw afspelen van wachtrijen. Bewaak AsyncApexJob en waarschuw voor aanhoudende storingen. |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Batch- versus wachtrijselectie | Gebruik Batch Apex voor: het verwerken van miljoenen records in blokken, geplande bulkbewerkingen, gegevensmigraties. Gebruik Apex voor wachtrijen voor: integratiewerkstromen in meerdere stappen met koppelen, bewerkingen die complexe objectparameters vereisen, taken die betere bewaking vereisen dan @future. Async Apex deelt een limiet van 250.000 uitvoeringen per 24 uur (DailyAsyncApexExecutions) voor batch-, wachtrij-, toekomstige en geplande Apex, in plaats van een wachtrijspecifieke toewijzing. |
| Wachtrijgebonden koppelen | Implementeer werkstromen met meerdere stappen door de volgende taak in een wachtrij te plaatsen vanuit de uitvoeringsmethode van de huidige taak. Chain schakelt sequentiële verwerking in: aanroep → parseerrespons → wachtrijvervolgactie. Maximaal 1 wachtrij per wachtrijuitvoering voorkomt op hol geslagen ketens. Ontwerp ketens met voltooiingsdetectie om oneindige lussen te voorkomen. |
| Gebruik van @future-methode | Gebruik @future voor eenvoudige asynchrone bewerkingen die geen complexe parameters (alleen primitieven) en geen ketens vereisen. Limiet: 50 @future-aanroepen per Apex transactie. @future biedt het eenvoudigste asynchrone patroon, maar mist zichtbaarheid: geen taakbewaking, geen ketens, geen complexe parameters. Voorkeur Wachtrij voor nieuwe ontwikkeling. |
| Geplande Apex optimalisering | Consolideer geplande bewerkingen in één planbare klassenverzending naar specifieke handlers. Maximaal 100 geplande taken per organisatie vereist strategische consolidatie. Plan buiten kantooruren om betwisting met gebruikersbewerkingen te verminderen. Gebruik Geplande Apex voor doeltreffende combinatie, delegeer zware verwerking aan Batch Apex. |
| Platform-event opnieuw afspelen | Ontwerp abonnees die replay-scenario’s afhandelen: duplicaatevents na uitval van abonnee, hiaatevents na langdurige uitval. Onderhoud laatst verwerkte ReplayId per abonnee. Gebruik EventBus.getReplayId() om opnieuw afspelen t.o.v. nieuwe events te detecteren. Idempotente verwerking implementeren (dezelfde event tweemaal verwerken leidt tot hetzelfde resultaat). |
| Vervolgpatroon | Gebruik Doorgaan voor langlopende aanroepen vanuit Lightning componenten die >5 seconden reactietijd vereisen. Voortzetting maakt meerdere gelijktijdige aanroepen van 120 seconden mogelijk, waardoor de waargenomen prestaties voor parallelle bewerkingen worden verbeterd. Limiet: 3 voortzettingen per verzoek. Implementeer time-outafhandeling en feedback van gebruikers. |
Zie de pijler Betrouwbaarheid voor inline voorbeelden en gedetailleerde richtlijnen of blader door de verkenner van patronen en antipatronen.