Skalerbarhedsmønstre
Få mere at vide om veludformet pålidelighed → Skalerbarhed og kapacitetsplanlægning
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| SOQL-forespørgselseffektivitet | Konsolider forespørgsler ved brug af relationsforespørgsler (kontakter, Cases__r) i stedet for separate forespørgsler pr. relateret objekt. Forespørg på alle nødvendige data en gang pr. transaktion. Mål <50 forespørgsler i synkrone transaktioner, <100 i asynkrone transaktioner (grænser: 100 synkronisering, 200 asynkronisering). Vedligehold 30-50%-buffer under grænserne. |
| Massificering af DML-handling | Indsaml registreringer i lister, kør enkelt DML-erklæring pr. objekttype pr. transaktion. Brug Database.insert/update/slete med allOrNone-parameteren, der kontrollerer delvis succesadfærd. Mål <75 DML-erklæringer pr. transaktion (grænse: 150). Batch reducerer DML-forbrug fra N erklæringer til 1. |
| Administration af heap-størrelse | Forespørg kun påkrævede felter (undgå SELECT *-mønstre). Behandl store resultatsæt i segmenter. Ryd samlinger efter behandling til frit hukommelse. Mål <4MB heap i synkron kontekst (grænse: 6 MB), <8 MB asynkron (grænse: 12 MB). Fejl, der er overskredet, angiver behovet for segmentering eller streaming af mønstre. |
| CPU-tidsoptimering | Minimer beregningskompleksitet i løkker. Brug kort til opslag (O(1)) i stedet for indlejret liste-iteration (O(n2)). Uploade tung beregning til asynkron kontekst. Mål <7.000ms CPU i synkrone transaktioner (grænse: 10.000 ms), <40.000 ms asynkron (grænse: 60.000ms). |
| SOQL-forespørgselsrækker | Designforespørgsler, der returnerer rimelige størrelser på resultatsæt. Brug LIMIT-sætning til at maksimere resultater. Mål <25.000 rækker pr. forespørgsel i synkron kontekst (grænse: 50,000). Forespørgsler, der nærmer sig grænser, skal bruge sideinddeling eller skifte til asynkron behandling med batch Apex eller Kø. |
| Tildeling af API-opkald | Overvåg 24-timers API-grænseforbrug via Systemoversigt. Batch-API-handlinger i stedet for registrerings-for-registrering-kald. Sæt ofte åbnede referencedata i cache ved brug af platformscache. Mål <70 % af den daglige API-grænse for at tage højde for spids. API-grænsen varierer efter version og licensantal. |
| Udkaldsbegrænsninger | Konsolider eksterne udkald: batch flere registreringer i en enkelt API-anmodning, når et eksternt system understøtter den. Implementer anmodningskø for at serialisere udkald. Respekter 120 sekunder samlet udkaldstid pr. transaktion. Grænse: 100 udkald pr. transaktion. Design asynkron behandling for udkaldsdrevne integrationer. |
| Kode (Apex, Aura, LWC) | Implementer massebehandlingsmønstre: behandle samlinger ikke individuelle registreringer, forespørge en gang og cachelagre i Maps, køre enkelt DML pr. objekttype. Brug relationsforespørgsler til at minimere SOQL-forbrug. Anvend effektive algoritmer, der undgår indlejrede løkker på store datasæt. |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| SOQL i løkker | Problem: Kørsel af SOQL-forespørgsler i forbindelse med løkker, der behandler registreringssamlinger. Påvirkning: Forespørgselsgrænse overskredet fejl ved 100+ registreringer (grænse: 100 forespørgsler pr. transaktion). Løsning: Forespørg en gang før løkken, og gem resultaterne i Tilknytt med relationsfelt. Opslag fra kort i løkke (masseinddelingsmønster). |
| DML i løkker | Problem: Kørsel af indsæt/opdater/slette-erklæringer i for løkker. Påvirkning: DML-grænse overskredet fejl ved 150+ registreringer (grænse: 150 DML-erklæringer pr. transaktion). Løsning: Indsaml registreringer i liste i løkke, kør enkelt DML-erklæring, når løkken er fuldført. |
| Ingen styringsbegrænsningsbuffer | Problem: Design af transaktioner, der forbruger 95% + af styringsbegrænsninger under normale forhold. Påvirkning: Produktionsfejl under lette belastningsforøgelser, ingen kapacitet for kanttilfælde. Løsning: Målret mod 70 % af grænserne som det driftsmæssige loft. Reserver 30 % buffer for spids- og kantsager. |
| Indlejrede løkkekartesiske produkter | Problem: Indlejrede løkker, der gentager to store samlinger, der opretter O(n2)-handlinger. Påvirkning: CPU-grænse overskredet fejl, heap-grænse overskredet fra midlertidige objekter. Løsning: Brug kortbaserede opslag, der konverterer O(n2) til O(n). Indsaml udvendige løkknøgler, forespørg på relaterede registreringer en gang, opslag i indvendig løkke. |
| Heap-akkumulering | Problem: Indlæsning af en stor forespørgsel resulterer i hukommelse uden behandling i segmenter. Påvirkning: Fejl om overskredet heapgrænse (6 MB synkronisering, 12 MB asynkronisering). Løsning: Forespørg kun på nødvendige felter. Proces i batches, der rydder samlinger efter hvert batch. Brug QueryLocator med batch Apex til behandling af flere millioner registreringer. |
| Ingen filtrering på feltniveau | Problem: Valg af alle felter (eksplicit eller implicit), når der kun er brug for undersæt. Påvirkning: Overdreven heap-forbrug, langsommere forespørgselsudførelse, SOQL-rækkegrænse nærmet unødvendigt. Løsning: Vælg kun felter, der er påkrævet til behandling. Brug relationsnotation til at hente relaterede data i en enkelt forespørgsel i stedet for separate forespørgsler. |
| Synkron behandling - overforbrug | Problem: Behandler store datamængder synkront i brugertransaktioner. Påvirkning: Bruger, der venter på handlinger på flere sekunder, overskred CPU/heap-grænser blokerer bruger. Løsning: Flyt tung behandling til asynkron kontekst (batch, i kø, platformsbegivenheder). Angiv brugerens øjeblikkelige svar med statuspolling. |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Asynkron behandling | Brug Batch Apex til behandling af store registreringsvolumener (milioner). Brug Apex i kø til kompleks orkestrering med flere trin med kæde. Brug platformsbegivenheder til begivenhedsstyret afkobling. Brug Planlagt Apex til regelmæssig vedligeholdelse. Match asynkront mønster til at bruge sag: Batch for mængde, Kan sættes i kø for kompleksitet, Begivenheder til afkobling. |
| Batchimplementering af Apex | Designstartmetode, der returnerer selektiv QueryLocator for at minimere behandlede registreringer. Konfigurer batchstørrelse baseret på registreringskompleksitet (200-2.000 registreringer pr. kørsel). Implementer kun tilstandsgrænseflade, når det er nødvendigt, da det reducerer gennemsnit. Overvåg AsyncApexJob for succes/fejl. Batch leverer dedikerede styringsbegrænsninger pr. segment. |
| Platformsbegivenhedsarkitektur | Udgiv begivenheder for statsændringer, der kræver downstream-behandling. Abonner ved brug af Apex på platformsbegivenhedsobjekter eller eksterne abonnenter via CometD. Design idempotente abonnenter (genafspilning kan levere begivenheder flere gange). Brug 72-timers bevarelse til gendannelse fra midlertidige abonnentfejl. |
| Datobaseret partitionering | Behandl data i tidsvinduer: aktuel måned, sidste kvartal, dette år. Arkiver historiske data til Big Objects eller eksternt lager. Tidsbaseret partitionering aktiverer parallelle batchjob, der behandler forskellige datoområder samtidigt. De fleste forespørgsler filtrerer naturligt efter dato, hvilket gør dette effektivt. |
| Registreringstypepartitionering | Behandl forskellige registreringstyper uafhængigt. Planlæg separate batchjob pr. registreringstype, der aktiverer parallelisering. Registreringstyper korrelerer ofte med særskilte forretningsprocesser, der retfærdiggør uafhængig behandling. Maksimalt 5 samtidige batchjob pr. organisation kræver strategisk partitionering. |
| Geografibaseret partitionering | Partition efter ejer, division eller område til behandling af distribution. Behandl hvert område, forretningsenhed eller salgsområde i parallelle batchjob. Geografibaseret partitionering anvender delingsmodel: hvert batchjob kører i konteksten af en bestemt brugergruppe, der automatisk filtrerer data. |
| Cachestrategi | Brug platformscache (organisations-/sessionspartitioner) til hyppigt åbnede referencedata. Cache reducerer forespørgsels- og API-forbrug. Tildel organisations- og sessionspartitioner i hele MB-inddelinger. Standardkapacitet varierer efter version med yderligere kapacitet, der kan købes i blokke. Cachemist skal med god smag falde tilbage til forespørgsel. Cache TTL skal matche dataændringsfrekvens: timer for statiske referencedata, minutter for semidynamiske. |
| Forløbsmassebehandling | Design forløb, der behandler registreringssamlinger ved brug af løkke- og samlingsvariabler. Opret samling af registreringer, udfør enkelt Hent registreringer, opdater samling med enkelt Opdater registreringer-element. Undgå individuelle registreringshandlinger i løkker. Forløbsmassebehandlingsmønstre afspejler Apex bedste fremgangsmåder. |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Kun sekventiel behandling | Problem: Enkelt batchjob, der behandler alle 50 millioner registreringer i rækkefølge, der tager 24+ timer. Påvirkning: Blokerer anden behandling, udtømning af vedligeholdelsesvindue, forsinkelser rettet mod brugere. Løsning: Opdel data efter dato, registreringstype eller geografi. Kør parallelle batchjob, der behandler uafhængige partitioner samtidigt. |
| Synkrone integrationsafhængigheder | Problem: Brugertransaktioner blokeret venter på eksterne systemsvar via synkrone udkald. Påvirkning: Brugeroplevelse, der er knyttet til ekstern systemydeevne, timeoutfejl under eksterne nedbrud. Løsning: Brug platformsbegivenheder til asynkron integration. Frakobl brugertransaktion fra ekstern systemtilgængelighed. |
| Ingen cachelag | Problem: Forespørg på de samme referencedata gentaget på tværs af transaktioner. Påvirkning: Overdreven SOQL-forbrug, API-begrænsning af affald, langsommere transaktionsudførelse. Løsning: Implementer platformscache for hyppigt åbnede referencedata. Cache reducerer styringsbegrænsning forbrug og forbedrer ydeevnen. |
| Batchjobstakning | Problem: Planlægning af 20+ batchjob, der starter samtidigt. Påvirkning: Kødybningsopbygning, 5 samtidige jobgrænser forårsager serialisering, uforudsigelige fuldførelsestider. Løsning: Faseplaner distribuerer indlæsning på tværs af timer. Konsolider lignende job i enkelt batch med dynamisk udsendelseslogik. |
| Overforbrug af statligt batch | Problem: Implementering af batch Apex med Database.Stateful, når det ikke er påkrævet. Påvirkning: Unødvendig serialisering af forekomstmedlemsvariabler på tværs af execute()-kald og potentiel heap-akkumulering fra bevaret tilstand. Løsning: Brug kun tilstand, når tilstanden skal være på tværs af udførte kald. Foretræk batches uden stat for at undgå unødvendig statsserialisering overhead. |
| Enkelttrådet forløbsdesign | Problem: Forløbsbehandling af registreringer en-til-en i løkke med individuelle Hent/opdater registrering-elementer pr. iteration. Påvirkning: Styringsbegrænsning af forbrug proportional med registreringsantal, transaktionsfejl på skala. Løsning: Indsaml registreringer i samlingsvariabel, udfør enkelt Hent registreringer, opdater samling med enkelt Opdater registreringer-element uden for løkke. |
| Ingen asynkron prøvestrategi | Problem: Mislykkede asynkrone job, der ikke bliver forsøgt automatisk, kræver manuel intervention. Påvirkning: Datauoverensstemmelser, manuel driftsbelastning, manglende SLA. Løsning: Implementer automatisk forsøg med eksponentiel tilbagerulning. Brug platformsbegivenheder til en holdbar kø, der aktiverer afspilning. Overvåg AsyncApexJob, og advar om vedvarende fejl. |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Valg af batch kontra kø | Brug batch Apex til: behandling af millioner af registreringer i segmenter, planlagte massehandlinger, datamigreringer. Brug Apex, der kan sættes i kø til: Integrationsarbejdsflows med flere trin med kæde, handlinger, der kræver komplekse objektparametre, job, der har brug for bedre overvågning end @future. Async Apex deler en grænse på 250.000 kørsler pr. 24 timer (DailyAsyncApexExecutions) på tværs af batch, kø, fremtid og planlagt Apex i stedet for en køspecifik tildeling. |
| Kæde, der kan sættes i kø | Implementer arbejdsflows med flere trin ved at linke det næste job fra det aktuelle jobs kørselsmetode. Kæde aktiverer sekventiel behandling: udkald → parse svar → opfølgningshandling i kø. Maksimalt 1 kø pr. kørsel i kø forhindrer løbende kæder. Design kæder med fuldførelsesregistrering for at undgå uendelige løkker. |
| @future-metodebrug | Brug @future til simple asynkrone handlinger, der ikke kræver nogen komplekse parametre (kun primitive) og ingen kæde. Grænse: 50 @future-kald pr. Apex. @future leverer det enkleste asynkrone mønster, men mangler synlighed: ingen jobovervågning, ingen kæde, ingen komplekse parametre. Foretræk Købar til ny udvikling. |
| Planlagt Apex | Konsolider planlagte handlinger i enkelte planlagte klasser, der udsendes til specifikke handlere. Maksimalt 100 planlagte job pr. organisation kræver strategisk konsolidering. Planlægning på fridage for at reducere tvister med brugerhandlinger. Brug Planlagt Apex til orkestrering, uddeleger tung behandling til batch Apex. |
| Genafspilning af platformsbegivenhed | Design abonnenter, der håndterer genspilningsscenarier: dubletbegivenheder efter abonnentfejl, mangelbegivenheder efter udvidet afbrydelse. Vedligehold sidst behandlet ReplayId pr. abonnent. Brug EventBus.getReplayId() til at registrere gentagelse i forhold til nye begivenheder. Implementer idempotent-behandling (behandling af den samme begivenhed to gange giver det samme resultat). |
| Fortsættelsesmønster | Brug Fortsæt til længe kørende udkald fra Lightning, der kræver >5 sekunders svartider. Fortsættelse aktiverer flere samtidige 120-sekunders udkald, der forbedrer den opfattede ydeevne for parallelle handlinger. Grænse: 3 fortsættelser pr. anmodning. Implementer timeouthåndtering og brugerfeedback. |
Hvis du ønsker indbyggede eksempler og detaljerede vejledninger, kan du se søjlen Pålidelighed eller gennemse udforskningen af mønstre og anti-mønstre.