SOQL (Salesforce Object Query Language) -forespørgsler kan undertiden løbe hurtigere i et sandkassemiljø sammenlignet med et produktionsmiljø på grund af flere tekniske og operationelle faktorer, der er iboende for, hvordan Salesforce -sandkasser er oprettet og styret. At forstå disse faktorer kræver at dykke ned i forskelle i datamængder, indeksering, cache, ressourcekonkurrence og systemoptimeringer, der er specifikke for sandkasse kontra produktionsmiljøer.
Datavolumen og kompleksitet
En af de primære årsager til, at SOQL -forespørgsler løber hurtigere i sandkassemiljøer er forskellen i datavolumen. Sandkasser har typisk mindre datasæt end produktionsmiljøer, især hvis de er delvis eller udvikler sandkasser, der kun kopierer en undergruppe af produktionsdataene. Dette reducerede datavolumen betyder, at færre poster skal scannes, indekseres og returneres af forespørgsler, og naturligt fremskynder forespørgselsudførelsestider. Selv i fulde sandkasser, der spejler produktionsdata, kan hyppige opdateringer eller snapshots betyde, at dataene ikke er så omfangsrige eller så ofte tilgængelige som i live -produktionsorganet, hvilket resulterer i bedre ydelse på grund af lavere overordnet systembelastning.
Indeksering og selektivitet
Salesforce's Query Optimizer er meget afhængig af indekser for at fremskynde udførelsen af forespørgslen. Forespørgsler, der filtrerer på indekserede felter, er ofte meget hurtigere, fordi Salesforce hurtigt kan indsnævre resultatsættet i stedet for at scanne hele tabellen. I sandkassemiljøer kan forespørgselsoptimeringen opføre sig mere effektivt, fordi datafordelingen kan være anderledes, hvilket gør det muligt for indekser at være mere selektive. For eksempel, hvis en sandkasse har færre duplikat- eller nulværdier i visse indekserede felter end produktion, kan forespørgselsoptimeringen bruge indekser mere effektivt til at udføre forespørgsler hurtigere. Desuden giver sandkassemiljøer ofte mulighed for mere fleksibilitet i at eksperimentere med brugerdefinerede indekser eller forespørgselsstuning uden at påvirke produktionen, hvilket kan optimere SOQL -ydeevne under udvikling og test.
Reduceret påstand og ressourceisolering
Produktionsmiljøer er multi-tenant og bruges stærkt af slutbrugere, der udfører forskellige operationer samtidigt, hvilket skaber ressourcekonkurrence. Denne påstand kan bremse udførelsen af forespørgslen som CPU, hukommelse, og I/O deles mellem adskillige samtidige processer. I modsætning hertil har sandkasser, især udvikler og udvikler pro sandkasser, en tendens til at have færre samtidige brugere og lavere overordnet systembelastning. Denne reduktion i efterspørgslen af samtidig behandling betyder, at forespørgsler kan få adgang til ressourcer lettere, reducere ventetider og fremskynde udførelsen.
Cache og forespørgselsplan Stabilitet
Salesforce anvender sofistikerede forespørgselscache -mekanismer til at forbedre ydeevnen. I sandkassemiljøer kan visse forespørgselsresultater og eksekveringsplaner cache, især hvis gentagne test eller udviklingsterationer udfører de samme forespørgsler. Denne cache -effekt kan fremskynde forespørgselsresultatet på efterfølgende kørsler. Fordi Sandbox -data ændres sjældnere end produktionen, forbliver de cache -forespørgselsplaner og resultater gyldige længere, hvilket forbedrer forespørgselseffektiviteten. Produktionsmiljøer med deres dynamiske og kontinuerlige dataændringer og tunge transaktionsaktiviteter kan ikke udnytte cache så effektivt, hvilket fører til hyppigere genkompilering af forespørgselsplaner og dermed langsommere forespørgselsydelse.
Guvernørgrænser og eksekveringskontekst
Salesforce pålægger guvernørgrænser inklusive det maksimale antal SOQL -forespørgsler pr. Transaktion for at opretholde platformstabilitet. I udviklingssandkasser konfigurerer og kontrollerer udviklere ofte og kontrollerer eksekveringskontekster mere omhyggeligt for at undgå at ramme disse grænser, for eksempel ved at bulke forespørgsler og behandling af data i batches. Denne opmærksomme udvikling og test hjælper med at holde forespørgsler optimeret inden implementering til produktion. I produktionen kan komplekse forretningsprocesser og integrationer utilsigtet forårsage overdreven eller ineffektiv forespørgsel, hvilket fører til langsommere ydelse på grund af gentagne databasehits og rammer guvernørgrænser. Sandkasser giver en sikrere plads til at fejlsøge og optimere disse forespørgsler, hvilket giver bedre relativ ydelse.
Forskelle i delingsregler og sikkerhedsindstillinger
Sandkassemiljøer kan have forenklet eller forskellige delingsregler og sikkerhedskonfigurationer sammenlignet med produktionen. Salesforce håndhæver delings- og synlighedsregler på databaseniveau under udførelse af forespørgsel. Komplekse delingsberegninger i produktionen kan tilføje overhead til forespørgsler, især dem, der er relateret til objekt- og rekordniveau-sikkerhed. Sandkasser, der bruges til udvikling eller testning, løfter eller forenkler disse regler undertiden disse regler, reducerer eksekveringskompleksiteten og således fremskynder SOQL -forespørgselsydelse.
Test og optimeringsfokus
I sandkassemiljøer er der generelt et fokus på test og optimering. Udviklere og administratorer profilerer aktivt, analyserer og forbedrer SOQL -forespørgsler ved hjælp af Salesforce -værktøjer som forespørgselsplan -værktøjet, Developer Consoles Performance Logs og Debug Logs. Derfor er den bedste praksis, der læres under udvikling af sandkasse, såsom at vælge kun nødvendige felter, anvende selektive filtre, undgå sløjfer med forespørgsler inde i dem, ved hjælp af forhold og aggregater tankevækkende og asynkron behandling (som batch spids) Â implementeret, hvilket resulterer i hurtigere forespørgsler. Produktionsmiljøer kan stadig indeholde arv eller uoptimerede forespørgsler, der forringer ydeevnen.
Andre medvirkende faktorer
- Data -skævhed: Produktionsdata har ofte skæve distributioner, hvor en lille undergruppe af poster dominerer datasættet. Dette skævhed kan forringe forespørgselspræstation ved at besejre indekseringsstrategier. Sandkasser kan have mindre skævhed, hvilket muliggør mere effektive forespørgsler.
- Vakuum- og genanvendelsesbakke Stat: Slettede poster i papirkurven kan påvirke ydelsen. Produktionsorganer har ofte en fyldigere papirkurven end sandkasser, som kan bremse SOQL -forespørgsler, der får adgang til relaterede objekter eller historier.
- Replikationsforsinkelse og forespørgselsstatistik: Salesforce's forespørgselsoptimering er afhængig af forudgående statistikker, der er opdateret med jævne mellemrum. Sandkasser, især nyligt forfriskede, kan have friske statistikker, der giver optimizer mulighed for at vælge bedre forespørgselsplaner.
- Forbedringer af platform: Nogle gange implementerer Salesforce nye ydelsesforbedringer og funktioner først i sandkasser til tidlig test. Dette kan midlertidigt forbedre sandkassens ydeevne i forhold til ældre produktionsmiljøer.
Sammenfattende løber SOQL -forespørgsler hurtigere i sandkassemiljøer primært på grund af mindre og mindre komplekse datasæt, bedre indeksselektivitet, reduceret systemforpligtelse, effektiv cache, fokuseret forespørgselsoptimering under udvikling og enklere sikkerhed og delingskonfigurationer. Disse kombinerede faktorer skaber forhold, hvor Salesforce's forespørgselsoptimering kan udføre forespørgsler mere effektivt, og hvor ressourcerne er lettere tilgængelige til behandling af forespørgsler. Dette miljø fremmer bedre ydeevne uopnåelig i den meget belastede og komplekse karakter af produktionsorganer. Sandkasser tjener således både som en udvikling/testlegeplads og et sted til præstationstuning, før de implementerer forespørgsler og applikationer til produktion, hvor ydelseskrav og datakompleksiteter er meget højere. Alle disse indsigter er hentet fra Salesforce Performance Best Practices, udvikleroplevelser og Salesforce's arkitekturegenskaber.