Skalerbarhetsmønstre
Lær mer om velbygd pålitelighet → Skalerbarhet og kapasitetsplanlegging
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| SOQL-spørringseffektivitet | Konsolider spørringer ved bruk av relasjonsspørringer (Kontakter, Saker__r) i stedet for separate spørringer per relatert objekt. Spørre mot alle nødvendige data én gang per transaksjon. Mål <50 spørringer i synkrone transaksjoner, <100 i asynkrone (grenser: 100 synkronisering, 200 asynkron). Hold bufferen på 30–50 % under grensene. |
| Masseutføring av DML-operasjon | Samle poster i lister, utfør én enkelt DML-setning per objekttype per transaksjon. Bruk Database.insert/update/delete med allOrNone-parameteren som kontrollerer virkemåten for delvis vellykket utførelse. Mål <75 DML-setninger per transaksjon (grense: 150). Gruppe reduserer DML-forbruket fra N setninger til 1. |
| Hapt-størrelsesbehandling | Spør bare på nødvendige felt (undgå SELECT *-mønstre). Behandle store resultatsett i biter. Tøm samlinger etter behandling til ledig minne. Mål <4 MB heap i synkron kontekst (grense: 6 MB), <8 MB asynkron (grense: 12 MB). Heap overskredet-feil angir at det er nødvendig å dele eller strømme mønstre. |
| Optimalisering av CPU-tid | Minimer beregningskompleksitet i sløyfer. Bruk Kart for oppslag (O(1)) i stedet for nestet liste-gjentagelse (O(n2)). Last ut tung beregning til asynkron kontekst. Mål <7 000 ms CPU i synkrone transaksjoner (grense: 10 000 ms), < 40 000 ms asynkron (grense: 60 000 ms). |
| SOQL-spørringsrader | Utformingsspørringer som returnerer rimelige resultatsettstørrelser. Bruk LIMIT-setningen til å vise resultater. Mål <25 000 rader per spørring i synkron kontekst (grense: 50,000). Spørringer som nærmer seg grenser, bør bruke paginering eller gå over til asynkron behandling med batch Apex eller Købar. |
| Tildeling av API-kall | Overvåk 24-timers API-grenseforbruk via Systemoversikt. Gruppe-API-operasjoner i stedet for post-for-post-kall. Bufre ofte brukte referansedata ved bruk av plattformbuffer. Mål <70 % av den daglige API-grensen for å ta hensyn til høydepunkter. API-grensen varierer etter versjon og antall lisenser. |
| Oppkallsgrenser | Konsolidere eksterne oppkall: batch flere poster i én enkelt API-forespørsel når et eksternt system støtter den. Implementer kø for forespørsler for å serialisere oppkall. Ta hensyn til totalt 120 sekunder oppkallstid per transaksjon. Grense: 100 oppkall per transaksjon. Utform asynkron behandling for oppkallvektige integrasjoner. |
| Kode (Apex, Aura, LWC) | Implementer mønstre for masseutførelse: behandle samlinger, ikke individuelle poster, spørre én gang og bufre i Maps, utføre enkelt DML per objekttype Bruk relasjonsspørringer til å redusere SOQL-forbruket. Bruk effektive algoritmer som unngår nestede sløyfer på store datasett. |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| SOQL i sløyfer | Problem: Utføre SOQL-spørringer i sløyfer som behandler postsamlinger. Innvirkning: Spørringsgrense overskredet feil på 100+ poster (grense: 100 spørringer per transaksjon). Løsning: Spørring én gang før sløyfe, lagrer du resultatet i Tilordning-nøkkelen etter relasjonsfelt. Oppslag fra Map inside loop (bulkifikasjonsmønster). |
| DML i sløyfer | Problem: Utføre sett inn/oppdater/slett-setninger i sløyfer. Innvirkning: DML-grense overskredet feil ved 150+ poster (grense: 150 DML-setninger per transaksjon). Løsning: Samle poster i Liste i sløyfe, utfør én enkelt DML-setning etter at sløyfen er fullført. |
| Buffer uten styringsgrense | Problem: Utforme transaksjoner som bruker mer enn 95 % av styringsgrensene under normale forhold. Innvirkning: Produksjonsfeil under mindre belastning øker, ingen kapasitet for kanttilfeller. Løsning: Mål 70 % av grensene som operasjonelt tak. Reserver 30 % buffer for spikes og edge-tilfeller. |
| Nestede sløyfe-kartesiske produkter | Problem: Nestede sløyfer gjentar to store samlinger og oppretter O(n2)-operasjoner. Innvirkning: CPU-grense overskredet feil, heap-grense overskredet fra midlertidige objekter. Løsning: Bruk kartbaserte oppslag til å konvertere O(n2) til O(n). Innhent nøkler i ytre sløyfe, spør relaterte poster én gang, oppslag i indre sløyfe. |
| Heap-akkumulering | Problem: Innlasting av en stor spørring fører til minne uten behandling i biter. Innvirkning: Heap-grense overskredet-feil (6 MB synkronisering, 12 MB asynkron). Løsning: Spørring er bare nødvendige felt. Prosess i batcher, rydde samlinger etter hver batch. Bruk QueryLocator sammen med Apex til behandling av flere millioner poster. |
| Ingen filtrering på feltnivå | Problem: Velge alle felt (eksplisitt eller implisitt) når bare delsett er nødvendig. Innvirkning: Overdreven heap-forbruk, tregere utførelse av spørringer, unødvendig nærming av SOQL-radgrense. Løsning: VELG bare felt som er nødvendige for behandling. Bruk relasjonsnotasjon til å hente relaterte data i enkeltspørringer i stedet for separate spørringer. |
| Overbruk av synkron behandling | Problem: Behandle store datavolumer synkront i brukertransaksjoner. Innvirkning: Brukere som venter på operasjoner som varer flere sekunder, har overskredet grensene for CPU/heap som blokkerer brukeren. Løsning: Flytt tung behandling til asynkron kontekst (Batch, Købar, Plattformhendelser). Gi brukere umiddelbar respons med statusspørring. |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Asynkron behandling | Bruk Apex til behandling av store postvolumer (millioner). Bruk Apex i kø for kompleks orkestrering med flere trinn med kjetting. Bruk Plattformhendelser til hendelsesdrevet frakobling. Bruk Planlagt Apex til periodisk vedlikehold. Samsvar asynkront mønster med brukstilfelle: Gruppe for volum, Købar for kompleksitet, Hendelser for frakobling. |
| Apex for batcher | Utform startmetoden som returnerer selektiv QueryLocator for å minimere antall behandlede poster. Konfigurer batchstørrelse basert på postkompleksitet (200–2000 poster per utførelse). Implementer statusfullt grensesnitt bare når det er nødvendig fordi det reduserer gjennomløp. Overvåk AsyncApexJob for suksess/feil. Gruppe har dedikerte styringsgrenser per bit. |
| Plattformhendelsesarkitektur | Publiser hendelser for delstatsendringer som krever nedstrøms behandling. Abonnere ved bruk av Apex på plattformhendelsesobjekter eller eksterne abonnenter via CometD. Utform idempotente abonnenter (gjenopprettelse kan levere hendelser flere ganger). Bruk 72-timers oppbevaring til gjenoppretting fra midlertidige abonnentfeil. |
| Datobasert partisjonering | Behandle data i tidsvinduer: gjeldende måned, forrige kvartal, dette året. Arkivere historiske data til store objekter eller eksternt lagringsplass. Tidsbasert partisjonering aktiverer parallelle gruppejobber som behandler forskjellige datoområder samtidig. De fleste spørringer filtrerer naturlig etter dato som gjør dette effektivt. |
| Posttypepartisjonering | Behandle forskjellige posttyper uavhengig. Planlegg separate gruppejobber per posttype som aktiverer parallelisering. Posttyper korrelerer ofte med distinkte forretningsprosesser som berettiger uavhengig behandling. Maksimalt fem samtidige gruppejobber per organisasjon krever strategisk partisjonering. |
| Geografibasert partisjonering | Partisjon etter eier, divisjon eller område for behandling av distribusjon. Behandle hvert område, forretningsenhet eller salgsområde i parallelle gruppejobber. Geografibasert partisjonering bruker delingsmodellen: hver gruppejobb kjører i sammenheng med en bestemt brukergruppe som filtrerer data naturlig. |
| Bufringsstrategi | Bruk plattformbuffer (organisasjons-/øktpartisjoner) til referansedata som ofte åpnes. Bufre reduserer forbruk av spørringer og API. Tildel organisasjons- og øktpartisjoner i trinn med hele MB. Standardkapasitet varierer etter versjon, med ekstra kapasitet som kan kjøpes i blokker. Bufferfeil bør gå tilbake til spørring. Bufre-TTL må samsvare med frekvensen for dataendring: timer for statiske referansedata, minutter for semi-dynamiske. |
| Masseutførelse av flyt | Utforme flyter som behandler postsamlinger med Sløyfe- og Samling-variabler. Opprett samling av poster, utfør enkelt Hent poster, oppdater samling med enkelt Oppdater poster-element. Unngå individuelle postoperasjoner i sløyfer. Mønstre for masseutførelse av flyter gjenspeiler Apex beste praksis. |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Bare sekvensiell behandling | Problem: Enkel gruppejobb som behandler alle 50 millioner poster sekvensielt og tar mer enn 24 timer. Innvirkning: Blokkerer annen behandling, uttømming av vedlikeholdsvindu og brukerrettede forsinkelser. Løsning: Partisjonere data etter dato, posttype eller geografi. Kjør parallelle gruppejobber som behandler uavhengige partisjoner samtidig. |
| Synkrone integrasjonsavhengigheter | Problem: Brukertransaksjoner blokkert venter på eksterne systemsvar via synkrone oppkall. Innvirkning: Brukeropplevelse knyttet til ekstern systemytelse, tidsavbrudd ved eksterne avbrudd. Løsning: Bruk plattformhendelser til asynkron integrering. Koble brukertransaksjon fra tilgjengelighet av eksternt system. |
| Ikke noe bufringslag | Problem: Spørring mot samme referansedata gjentatte ganger på tvers av transaksjoner. Innvirkning: Overdreven SOQL-forbruk, API-begrensningsavfall, tregere utførelse av transaksjoner. Løsning: Implementer Plattformbuffer for ofte brukte referansedata. Bufre reduserer forbruket av styringsgrenser og forbedrer ytelsen. |
| Stabling av gruppejobb | Problem: Planlegge 20+ gruppejobber som starter samtidig. Innvirkning: Kødybdeoppsamling, grensen for fem samtidige jobber fører til serialisering, uforutsigbare fullføringstider. Løsning: Stagger planlegger fordelingen av belastningen på tvers av timer. Konsolider lignende jobber i én batch med dynamisk senderogikk. |
| Overbruk av status for batcher | Problem: Implementere Apex med Database.Stateful når det ikke er nødvendig. Innvirkning: Unødvendig serialisering av forekomstmedlemsvariabler på tvers av execute()-kall og potensiell heap-akkumulering fra beholdt tilstand. Løsning: Bruk status bare når stat må beholdes på tvers av utføringsoppkall. Foretrukk grupper uten status for å unngå unødvendig overhead for status-seriering. |
| Utforming av enkelttrådet flyt | Problem: Flytbehandlingsposter én-ved-én i Sløyfe med individuelle Hent/oppdater post-elementer per gjentagelse. Innvirkning: Styringsgrenser forbruk proporsjonal med antall poster, transaksjonsfeil i stor skala. Løsning: Samle poster i samlingsvariabel, utfør enkelt Hent poster, oppdater samlingen med enkelt Oppdater poster-element utenfor sløyfe. |
| Ingen strategi for asynkrone forsøk på nytt | Problem: Mislykkede asynkrone jobber som ikke prøves på nytt automatisk, krever manuell intervensjon. Innvirkning: Datainkonsistens, manuell driftsbelastning, manglende tjenestenivåavtale. Løsning: Implementer automatisk forsøk på nytt med eksponentiell tilbakemelding. Bruk Plattformhendelser til å aktivere gjentakelse av langvarig kø. Overvåk AsyncApexJob og varsle om vedvarende feil. |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Batch kontra købasert-valg | Bruk Apex til følgende: behandle millioner av poster i biter, planlagte masseoperasjoner og dataoverføringer. Bruk Apex i kø for: arbeidsflyter for flertrinns integrering med kjetting, operasjoner som krever komplekse objektparametere, jobber som trenger bedre overvåking enn @future. Async Apex deler en grense på 250 000 utførelser per 24 timer (DailyAsyncApexExecutions) på tvers av batch, købar, fremtidig og planlagt Apex, i stedet for en køspesifikk tildeling. |
| Kjeding i kø | Implementer flertrinns arbeidsflyter ved å legge til neste jobb fra gjeldende jobbs utførelsesmetode. Kjede aktiverer sekvensiell behandling: oppfølgingshandlingen callout → parse response → enke. Maksimalt 1 kø per købasert utførelse hindrer kjeder som ikke kjører. Utform kjeder med fullføringsdeteksjon for å unngå uendelige sløyfer. |
| bruk av @future-metode | Bruk @future til enkle asynkrone operasjoner som ikke krever komplekse parametere (bare primitive) og ingen kjetting. Grense: 50 @future-kall per Apex. @future gir det enkleste asynkrone mønsteret, men mangler synlighet: ingen jobbovervåking, ingen kjetting, ingen komplekse parametere Foretrukk Købar for ny utvikling. |
| Planlagt Apex | Konsolider planlagte operasjoner til sending av én enkelt planleggbar klasse til bestemte behandlere. Maksimalt 100 planlagte jobber per organisasjon krever strategisk konsolidering. Planlegg i åpningstider for å redusere konflikt med brukeroperasjoner. Bruk Planlagt Apex til orkestrering, deleger tung behandling til Apex. |
| Avspilling av plattformhendelse | Utforme abonnenter som håndterer gjentakelsesscenarier: duplikathendelser etter abonnentfeil, gaphendelser etter utvidet avbrudd. Vedlikehold siste behandlede ReplayId per abonnent. Bruk EventBus.getReplayId() til å oppdage avspilling mot nye hendelser. Implementer idempotent-behandling (behandling av samme hendelse to ganger gir samme resultat). |
| Fortsettelsesmønster | Bruk Fortsettelse for langvarige oppkall fra Lightning som krever >5 sekunders responstider. Fortsettelse aktiverer flere samtidige 120-sekunders oppkall som forbedrer oppfattet ytelse for parallelle operasjoner. Grense: 3 fortsettelser per forespørsel. Implementer håndtering av tidsavbrudd og tilbakemeldinger fra brukere. |
Hvis du vil se innebygde eksempler og detaljert veiledning, kan du se Pålitelighet-pilen eller bla gjennom utforskeren Mønstre og anti-mønstre.