Skaalattavuuskuviot
Lue lisää Hyvin rakennettu luotettavuus → Skaalattavuus ja kapasiteetin suunnittelu
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| SOQL-kyselyiden tehokkuus | Yhdistä kyselyitä käyttämällä suhdekyselyitä (Yhteyshenkilöt, Tapaukset__r) erillisten kyselyiden sijaan per liittyvä objekti. Kysele kaikkia tarvittavia tietoja kerran per transaktio. Kohde <50 kyselyä synkronoiduissa transaktioissa, <100 ei-synkronoiduissa (rajoitukset: 100 synkronointia, 200 asynkronointia). Pidä 30–50 %:n puskurin rajoituksen alapuolella. |
| DML-toiminnon bulkkaaminen | Kerää tietueita luetteloihin ja suorita yksi DML-lauseke per objektityyppi per transaktio. Käytä Database.insert/update/delete-parametriä allOrNone-parametrillä, joka hallitsee osittaista onnistumista. Tavoite <75 DML-lauseketta per transaktio (rajoitus: 150). Erä vähentää DML:n kulutusta N-lausekkeesta 1:een. |
| Heap-kokojen hallinta | Kysele vain pakollisia kenttiä (vältä SELECT * -kuvioita). Käsittele suuria tulosjoukkoja osioihin. Tyhjennä kokoelmat, kun niitä käsitellään vapaaseen muistiin. Tavoite <4 Mt peukalo synkronoidussa asiayhteydessä (rajoitus: 6 Mt), <8 Mt ei-synkronoitu (rajoitus: 12 MT). Peukaloiden ylimääräiset virheet osoittavat, että kuviot täytyy pilkkoa tai suoratoistaa. |
| CPU-aikojen optimointi | Minimoi laskentojen monimutkaisuus silmukoissa. Käytä Maps-hakua (O(1)), äläkä sisäkkäistä luettelo-iteraatiota (O(n2)). Poista raskas laskenta ei-synkronoidusta asiayhteydestä. Tavoite < 7 000ms CPU synkronoiduissa transaktioissa (rajoitus: 10 000ms), < 40 000ms asynkroninen (rajoitus: 60 000ms). |
| SOQL-kyselysivut | Suunnittelukyselyt, jotka palauttavat kohtuullisia tulosjoukkojen kokoja. Käytä LIMIT-lauseketta sulkeaksesi tulokset. Kohdista alle 25 000 riviä per kysely synkronoidussa asiayhteydessä (rajoitus: 50,000). Rajoituksiin lähestyvät kyselyt tulisi käyttää sivutusta tai siirtyä ei-synkronoituun käsittelyyn Apex tai Jonostava. |
| API-kutsujen rajoitus | Valvo 24 tunnin API-rajoituksen kulutusta järjestelmän yleiskatsauksesta. Erä-API-operaatiot tietueen mukaan -kutsujen sijaan. Tallenna usein käytetty viitetiedot välimuistiin käyttämällä sovellusalustan välimuistia. Tavoite <70 % päivittäisestä API-rajoituksesta huippujen huomioimiseksi. API-rajoitus vaihtelee Edition-version ja lisenssien määrän mukaan. |
| Callout-kutsujen rajoitukset | Ulkoisten callout-kutsujen yhdistäminen: erätä useita tietueita yhdeksi API-pyynnöksi, kun ulkoinen järjestelmä tukee sitä. Ota pyyntöjen jono käyttöön sarjanumeroidaksesi callout-kutsuja. Noudata 120 sekunnin kokonaiskutsuaikaa per transaktio. Rajoitus: 100 callout-kutsua per transaktio. Suunnittele asynkronoitavien integraatioiden asynkronointi. |
| Koodi (Apex, Aura, LWC) | Bulkkauskuvioiden toteuttaminen: käsittele kokoelmia, jotka eivät ole yksittäisiä tietueita, kysele kerran ja tallenna karttoihin, suorita yksi DML per objektityyppi. Käytä suhdekyselyitä minimoidaksesi SOQL-kulutusta. Käytä tehokkaita algoritmeja välttyäksesi sisäkkäisiltä silmukoilta suurille datajoukoille. |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| SOQL silmukoissa | Ongelma: SOQL-kyselyiden suorittaminen sisäisesti silmukoille, jotka käsittelevät tietueiden kokoelmia. Vaikutus: Ylennetyn virheen kyselyn rajoitus yli 100 tietueessa (rajoitus: 100 kyselyä per transaktio). Tarkkuus: Kysele kerran ennen silmukkaa ja tallenna tulokset Kartta-kenttään suhdekentän perusteella. Haku Kartta silmukan sisällä (bulkkauskuvio). |
| DML silmukoissa | Ongelma: Lisää/päivitä/poista-lausekkeiden suorittaminen silmukoiden sisällä. Vaikutus: DML-rajoitus ylittynyt virhe yli 150 tietueessa (rajoitus: 150 DML-lausuntoa per transaktio). Tarkkuus: Kerää tietueita luetteloon silmukan sisällä, suorita yksi DML-lauseke silmukan suorittamisen jälkeen. |
| Ei hallintorajoituksen puskuria | Ongelma: Suunnittele transaktioita, jotka kuluttavat yli 95 % hallintarajoituksista normaaleissa olosuhteissa. Vaikutus: Tuotantovirheet, kun kuorma kasvaa hieman, ei kapasiteettia reunojen tapauksille. Tarkkuus: Kohdista 70 prosenttia rajoituksista toiminta-asteikoksi. Varata 30 % puskuripuskuria pikkulapset ja reunatapaukset. |
| Sisäkkäiset silmukan kartesiaanituotteet | Ongelma: Sisäkkäiset silmukat iteroivat kaksi isoa kokoelmaa luomalla O(n2)-operaatioita. Vaikutus: CPU-rajoitus ylitettyjä virheitä, joukkorajoitus ylitettyjä väliaikaisista objekteista. Tarkkuus: Käytä karttoihin perustuvia hakuja muuntaaksesi O(n2) muotoon O(n). Kerää ulkoiset silmukan avaimet, kysele asiaan liittyviä tietueita kerran ja hae sisäisessä silmukassa. |
| Pinojen kumulointi | Ongelma: Suuren kyselyn lataaminen palauttaa muistiin ilman, että sitä käsitellään lohkoina. Vaikutus: Heap limit exceeded error (6 Mt synkronointi, 12 Mt asynkronointi). Tarkkuus: Kysele vain tarvittavia kenttiä. Prosessit erissä, jotka tyhjentävät kokoelmat jokaisen erän jälkeen. Käytä QueryLocatoria Apex erän kanssa käsitelläksesi miljoonia tietueita. |
| Ei kenttätason suodatusta | Ongelma: Kaikkien kenttien (selkeiden tai epäsuorien) valitseminen tarvittaessa. Vaikutus: Liiallinen joukkojen kulutus, kyselyiden suorittaminen hitaammin, SOQL-rivien rajoitus lähestyy tarpeettomasti. Tarkkuus: Valitse vain kentät, jotka vaaditaan käsittelyyn. Käytä suhdetaatiota noutaaksesi asiaan liittyvää dataa yksittäisessä kyselyssä erillisten kyselyiden sijaan. |
| Synkronoidun käsittelyn ylikäyttö | Ongelma: Suuren datamäärän käsittely synkronoidusti käyttäjätapahtumissa. Vaikutus: Käyttäjät odottavat useiden sekuntien toimintoja, CPU/heap-rajoitukset ylitetty estää käyttäjän. Tarkkuus: Siirrä raskaan käsittelyn asynkroniseen kontekstiin (Batch, Queueable, Platform Events). Tarjoa käyttäjille välitön vastaus tilakyselyllä. |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Ei-synkronoitu käsittely | Käytä Apex käsitelläksesi suuria tietueiden määriä (miljoonia). Käytä Queueable Apexia monivaiheiseen monivaiheiseen orkestrointiin ketjutuksella. Käytä sovellusalustan tapahtumia tapahtumiin perustuvaan irrottamiseen. Käytä ajoitettua Apexia säännölliseen huoltoon. Täsmää asynkronointikuvio käyttämään tapausta: Erä määrälle, Jonotettava monimutkaisuudelle, Tapahtumat irrottamiseen. |
| Apex | Suunnittele aloitusmenetelmä, joka palauttaa valikoivan QueryLocator-arvon vähentääkseen käsiteltyjä tietueita. Määritä erän koko tietueiden monimutkaisuuden perusteella (200–2 000 tietuetta per suorituskerta). Toteuta tilainen käyttöliittymä vain tarvittaessa, koska se vähentää läpimenoa. Valvo AsyncApexJob-objektia onnistuneen/epäonnistuneen varalta. Erä tarjoaa erilliset hallintarajoitukset per osa. |
| Sovellusalustan tapahtumat -arkkitehtuuri | Julkaise tapahtumia tilojen muutoksille, jotka vaativat myöhemmän käsittelyn. Tilaa sovellusalustan tapahtumaobjektien tai ulkoisten tilaajien Apex CometD:n kautta. Suunnittele idempotent-tilaajat (toisto voi toimittaa tapahtumia useita kertoja). Käytä 72 tunnin säilytystä toipuaksesi tilaajan väliaikaisista virheistä. |
| Päivämääräperusteinen osiointi | Tietojen käsittely ajanjaksoissa: tämänhetkinen kuukausi, viime vuosineljännes, tämä vuosi. Arkistoi historiallisia tietoja Big-objekteihin tai ulkoiseen tallennustilaan. Aikaperusteinen osiointi sallii samanaikaisten erätöiden käsitellä eri ajanjaksoja samanaikaisesti. Useimmat kyselyt suodatetaan luonnollisesti päivämäärän perusteella, mikä tekee tästä tehokasta. |
| Tietuetyypin osiointi | Käsittele eri tietuetyyppejä itsenäisesti. Ajoita erillisiä erätöitä per tietuetyyppi ottaen käyttöön rinnakkaisvalvonta. Tietuetyypit korreloivat usein erillisten liiketoimintaprosessien kanssa, mikä oikeuttaa itsenäisen käsittelyn. Enintään 5 samanaikaista erätyötä per organisaatio vaatii strategisen osioinnin. |
| Maantieteeseen perustuva osiointi | Osio omistajan, divisioonan tai alueen mukaan jakelun käsittelemiseksi. Käsittele jokainen alue, liiketoimintayksikkö tai myyntialue rinnakkaisissa erätöissä. Maantieteeseen perustuva osiointi hyödyntää jakomallia: jokainen erätyö suoritetaan tietyn käyttäjäryhmän asiayhteydessä, joka suodattaa dataa luonnollisesti. |
| Välimuistiin tallennusstrategia | Käytä sovellusalustan välimuistia (organisaation/istunnon osiot) usein käytettyyn viitetietoihin. Välimuisti vähentää kyselyiden ja API:n kulutusta. Kohdista organisaatio- ja istunto-osioita koko Mt:n määrissä. Oletusarvoinen kapasiteetti vaihtelee Edition-version mukaan, ja ylimääräistä kapasiteettia voi ostaa lohkoina. Välimuistin puute palauttaa kyselyn helposti. Välimuistin TTL:n tulisi vastata datan muutosten yleisyyttä: staattisen viitetietojen tunnit, puolidynamiikan minuutit. |
| Kulkujen bulkkaaminen | Suunnittele kulkuja, jotka käsittelevät tietueiden kokoelmia käyttämällä Silmukka- ja Kokoelma-muuttujia. Luo tietueiden kokoelma, suorita yksi Nouda tietueita ja päivitä kokoelma yhdellä Päivitä tietueita -elementillä. Vältä yksittäisiä tietuetoimintoja silmukoiden sisällä. Kulkujen bulkkauskuviot vastaavat Apexin suositeltuja käytäntöjä. |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Vain peräkkäinen käsittely | Ongelma: Yksittäinen erätyö, joka käsittelee kaikki 50 miljoonaa tietuetta peräkkäin yli 24 tuntia. Vaikutus: Estää muun käsittelyn, huoltojaksojen tyhjentymisen ja käyttäjille aiheutuvia viiveitä. Tarkkuus: Jaa tiedot päivämäärän, tietuetyypin tai maantieteellisen sijainnin mukaan. Suorita rinnakkaisia erätöitä, jotka käsittelevät itsenäisiä osioita samanaikaisesti. |
| Synkronoitujen integraatioiden sidonnaisuudet | Ongelma: Käyttäjätapahtumat estetään odottamaan ulkoisten järjestelmän vastauksia synkronoitujen callout-kutsujen kautta. Vaikutus: Käyttäjäkokemus liittyy ulkoiseen järjestelmän suorituskykyyn, aikakatkaisuvirheisiin ulkoisten käyttökatkosten aikana. Tarkkuus: Käytä sovellusalustan tapahtumia ei-synkronoidulle integraatiolle. Irrota käyttäjätapahtuma ulkoisen järjestelmän saatavuudesta. |
| Ei välimuistikerrosta | Ongelma: Saman viitetiedot kyseleminen toistuvasti transaktioissa. Vaikutus: Liiallinen SOQL-kulutus, API-rajoituskulut, hitaampi transaktioiden suoritus. Tarkkuus: Toteuta sovellusalustan välimuisti usein käytetyille viitetiedoille. Välimuisti vähentää hallintorajoituksen kulutusta ja parantaa suorituskykyä. |
| Erätöiden pinottaminen | Ongelma: Ajoita yli 20 erätyötä, jotka alkavat samanaikaisesti. Vaikutus: Jonojen syvyyden muodostaminen, 5 samanaikaisen työn rajoitus aiheuttaa sarjanumeroinnin ja odottamattomat suoritusajat. Tarkkuus: Stagger-ajoitukset, jotka jakavat kuorman tunneille. Yhdistä samankaltaisia töitä yhteen erään dynaamisen lähetyslogiikan avulla. |
| Tilallinen erän ylikäyttö | Ongelma: Apex Database.Stateful-muuttujalla, kun sitä ei tarvita. Vaikutus: Instanssin jäsenten muuttujien tarpeeton sarjanpito execute()-kutsuissa ja mahdollinen pinojen kertyminen säilytetystä tilasta. Tarkkuus: Käytä stateful-arvoa vain, kun tila täytyy säilyttää kaikkien suorituskutsujen aikana. Valitse tilatonta erää välttyäksesi tarpeettomilta osavaltioiden sarjoituksilta. |
| Yksittäisen ketjun kulkujen rakenne | Ongelma: Kulku käsittelee tietueita yksi kerrallaan Silmukan sisällä yksittäisillä Nouda/päivitä tietue -elementeillä per iterointi. Vaikutus: Hallitse kulutusrajoituksia suhteessa tietueiden määrään, transaktioiden virheisiin skaalassa. Tarkkuus: Kerää tietueita kokoelmamuuttujiin, suorita yksi Nouda tietueita ja päivitä kokoelma yhdellä Päivitä tietueita -elementillä silmukan ulkopuolella. |
| Ei asynkronoitavaa uudelleenyritysstrategiaa | Ongelma: Epäonnistuneet asynkronointityöt, joita ei yritetä uudelleen automaattisesti, vaativat manuaalisen toimenpiteen. Vaikutus: Datan epäjohdonmukaisuudet, manuaalinen työkuorma, palvelutasosopimus puuttuu. Tarkkuus: Ota käyttöön automaattinen uudelleenyritys eksponenttisella rästityksellä. Käytä sovellusalustan tapahtumia kestävän jonon sallimiseen toistamiseen. Valvo AsyncApexJob ja ilmoita jatkuvista virheistä. |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Erä vs. jonoon asetettava valinta | Käytä Apex miljoonien tietueiden käsittely lohkoina, ajoitetut joukkotoiminnot ja datan siirrot. Käytä Queueable Apexia seuraaviin kohteisiin: monivaiheiset integrointityönkulut ketjutuksella, monimutkaisten objektien parametrejä vaativat toiminnot ja työt, jotka tarvitsevat parempaa valvontaa kuin @future. Async Apex jakaa 250 000 suorituskerran 24 tunnin välein (DailyAsyncApexExecutions) erä-, jono-, tuleva- ja ajoitettu-Apexille, eikä jono-kohtaista rajoitusta. |
| Jonossa oleva ketjutus | Toteuta monivaiheisia työnkulkuja lisäämällä seuraava työ tämänhetkisen työn suoritusmenetelmään. Ketju sallii järjestyksellisen käsittelyn: callout → jonota vastaus → jonota jatko-toiminto. Enintään 1 jono per jonoitettava suoritus estää ketjut. Suunnittele ketjuja ja suorituksen tunnistusta välttyäksesi loputtomilta silmukoilta. |
| @future-metodin käyttö | Käytä @futurea yksinkertaisille asynkronointitoiminnoille, jotka eivät vaadi monimutkaisia parametrejä (vain primitiivisiä) tai ketjutusta. Rajoitus: 50 @future-kutsua per Apex. @future tarjoaa yksinkertaisimman asynkronointikuvion, mutta ei näkyvyyttä: ei töiden valvontaa, ketjutusta tai monimutkaisia parametrejä. Valitse uudelle kehitykselle Jonotettava. |
| Ajoitettu Apex | Yhdistä ajoitetut toiminnot yhteen ajoitettavaan luokkaan, joka lähetetään tietyille käsittelijöille. Enintään 100 ajoitettua työtä per organisaatio vaatii strategisen yhdistämisen. Ajoita aukioloaikoina vähentääksesi ristiriitoja käyttäjien toiminnoissa. Käytä ajoitettua Apexia orkestrointiin, delegoi raskas käsittely erä Apexiin. |
| Sovellusalustan tapahtuman toisto | Suunnittele tilaajat käsittelemään toistokuvioita: identtiset tapahtumat tilaajan epäonnistumisen jälkeen, aukkotapahtumat pitkän käyttökatkoksen jälkeen. Ylläpidä viimeksi käsiteltyä ReplayId-arvoa per tilaaja. Käytä EventBus.getReplayId()-funktiota havaitaksesi toistamisen vs. uusia tapahtumia. Ota käyttöön idempotent-käsittely (saman tapahtuman käsittely kahdesti tuottaa saman tuloksen). |
| Jatkosuunnitelma | Käytä Jatka-vaihtoehtoa pitkäaikaisille callout-kutsuille Lightning, jotka vaativat yli 5 sekuntia vastausaikoja. Jatkaminen sallii useiden samanaikaisten 120 sekunnin callout-kutsujen, mikä parantaa samanaikaisten toimintojen havaittua suorituskykyä. Rajoitus: 3 jatkoa per pyyntö. Ota käyttöön aikakatkaisujen käsittely ja käyttäjien palaute. |
Katso inline-esimerkkejä ja yksityiskohtaisia ohjeita kohdasta Reliability Pillar tai selaa Patterns and Anti-Patterns -tutkintaohjelmaa.