Bästa praxis för konfiguration

Commerce har många inställningar och verktyg som du kan använda för att förbättra svarstiden på sidorna och ge högre genomströmning.

Kronjobb

Alla asynkrona åtgärder i Commerce utförs med Linux cron-kommandot. Se Konfigurera och kör cron för att konfigurera det korrekt.

Indexerare

En indexerare kan köras i antingen Update on Save- eller Update on Schedule-läge. Läget Update on Save indexeras omedelbart när katalogen eller andra data ändras. I det här läget används låg intensitet för uppdaterings- och bläddringsåtgärder i din butik. Det kan leda till betydande förseningar och otillgänglighet av data vid höga belastningar. Vi rekommenderar att du använder Uppdatera i schemat i prestandasyfte, eftersom det lagrar information om datauppdateringar och utför indexering av delar i bakgrunden via ett specifikt cron-jobb. Du kan ändra läget för varje Commerce-indexerare separat på konfigurationssidan System > Tools > Index Management . Indexvärdet Customer Grid måste alltid anges till läget Update on Save.

Cacher

När du startar din butik i produktion aktiverar du alla cacheminnen från sidan System > Tools > Cache Management. Vi rekommenderar att du använder Varnish eftersom det är en effektiv cachelösning för produktionssidor.

Asynkrona e-postmeddelanden

Om du aktiverar inställningen"Asynkrona e-postmeddelanden" flyttas processer som hanterar utcheckning och beställer e-postmeddelanden till bakgrunden. Om du vill aktivera den här funktionen går du till Stores> Settings > Configuration > Sales > Sales Emails > General Settings >Asynchronous Sending. Mer information finns i E-postmeddelanden i användarhandboken för administratören.

Asynkron bearbetning av orderdata

Det kan finnas tillfällen då intensiv försäljning i en butik sker samtidigt som Commerce utför intensiv orderbearbetning. Du kan konfigurera Commerce så att dessa två trafikmönster särskiljs på databasnivå för att undvika konflikter mellan läs- och skrivåtgärder i motsvarande tabeller. Du kan lagra och indexera orderdata asynkront. Beställningar läggs i tillfällig lagring och flyttas i bulk till Order Management rutnät utan några kollisioner. Du kan aktivera det här alternativet från Stores> Settings > Configuration > Advanced > Developer > Grid Settings >Asynchronous indexing. Mer information finns i Schemalagda stödrasteruppdateringar i användarhandboken för administratören.

Spara asynkron konfiguration

För projekt med ett stort antal butikskonfigurationer kan det ta oordinerad tid att spara en butikskonfiguration eller resultera i en timeout. Modulen Async Config aktiverar asynkrona konfigurationssparningar genom att köra ett cron-jobb där en konsument bearbetar sparandet i en meddelandekö. AsyncConfig är inaktiverad som standard.

Du kan aktivera AsyncConfig med kommandoradsgränssnittet:

bin/magento setup:config:set --config-async 1

Kommandot set skriver följande till filen app/etc/env.php:

...
   'config' => [
       'async' => 1
   ]

Starta följande konsument för att börja bearbeta meddelandena i kön först-i-först-ut-baserat:

bin/magento queue:consumers:start saveConfigProcessor --max-messages=1

Uppskjuten lageruppdatering

I tider med intensiv försäljning kan Commerce skjuta upp lageruppdateringar relaterade till order. Detta minimerar antalet åtgärder och snabbar upp orderplaceringsprocessen. Det här alternativet är dock riskabelt och kan bara användas när restorder aktiveras i butiken, eftersom det här alternativet kan leda till negativa lagerkvantiteter. Det här alternativet kan ge avsevärda prestandaförbättringar i utcheckningsflöden för butiker som enkelt kan fylla i sitt lager på begäran. Om du vill aktivera fördröjda Stock-uppdateringar på din webbplats går du till Stores> Settings > Configuration > Catalog > Inventory > Product Stock Options >Use Deferred Stock Update. Mer information finns i Hantera lager i Adobe Commerce användarhandbok.

Optimeringsinställningar på klientsidan

Om du vill förbättra butiksvarstiden för din Commerce-instans går du till Admin i läget Standard eller Utvecklare och ändrar följande inställningar:

Stores-> Configuration -> Advanced -> Developer:

När du aktiverar alternativet Enable JavaScript Bundling tillåter du att Commerce sammanfogar alla JS-resurser till ett eller flera paket som är inlästa på butikssidor. Paketeringen av JS resulterar i färre begäranden till servern, vilket förbättrar sidans prestanda. Det hjälper även webbläsaren att cachelagra JS-resurser vid det första anropet och återanvända dem för all vidare surfning. Det här alternativet ger även en lat utvärdering eftersom all JS läses in som text. Den initierar bara analys och utvärdering av kod efter att specifika åtgärder har utlösts på sidan. Den här inställningen rekommenderas dock inte för butiker där den första sidans laddningstid är extremt viktig eftersom allt JS-innehåll läses in vid det första anropet.

Pakettips

Validering av kundsegment

Handlare som har ett stort antal kundsegment kan uppleva betydande prestandaförsämringar med kundåtgärder, till exempel kundinloggning och tillägg av produkter i kundvagnen.

Kundåtgärder utlöser en valideringsprocess för kundsegment, vilket kan leda till sämre prestanda. Som standard validerar Adobe Commerce varje segment i realtid för att definiera vilka kundsegment som matchas och vilka som inte gör det.

För att undvika prestandaförsämringar kan du ställa in systemkonfigurationsalternativet Real-time Check if Customer is Matched by Segment på Nej för att validera kundsegment med en enda SQL-villkorsfråga.

Om du vill aktivera den här optimeringen går du till Stores> Settings > Configuration > Customers > Customer Configuration > Customer Segments >Real-time Check if Customer is Matched by Segment.

Den här inställningen förbättrar prestandan vid validering av kundsegment om det finns många kundsegment i systemet. Det fungerar dock inte med delade databasimplementeringar eller när det inte finns några registrerade kunder.

Databasunderhållsschema database

Vi rekommenderar att du gör regelbundna databassäkerhetskopieringar för instanserna Staging och Production. På grund av I/O-intensiva säkerhetskopieringsåtgärder kan det uppstå långsammare säkerhetskopiering och potentiella problem. Att köra databasprocesser för flera miljöer samtidigt kan eventuellt gå långsammare på grund av att det finns invändningar mot tillgängliga resurser.

För bättre prestanda bör du schemalägga säkerhetskopieringar så att de körs i följd, en åt gången, vid låg belastning. Med den här metoden undviker du I/O-problem och förkortar tiden för slutförande, särskilt för mindre instanser, större databaser och så vidare.

Vi rekommenderar till exempel att du schemalägger en säkerhetskopia av din produktionsdatabas som följs av mellanlagringsdatabasen när dina butiker stöter på lägre besök.

Begränsa antalet produkter i rutnätet

För att förbättra prestanda för produktstödraster för stora kataloger rekommenderar vi att du begränsar antalet produkter i stödrastret med Stores> Settings > Configuration > Advanced > Admin > Admin Grids >Limit Number of Products in Grid systemkonfigurationsinställningen.

Den här systemkonfigurationsinställningen är inaktiverad som standard. Genom att aktivera det kan du begränsa antalet produkter i rutnätet till ett visst värde. Records Limit är en anpassningsbar inställning som har standardvärdet 20000.
När inställningen Limit Number of Products in Grid är aktiverad och antalet produkter i rutnätet är större än postgränsen, returneras den begränsade mängden poster. När gränsen nås döljs de totala antalet poster som hittats, antalet valda poster och sidnumreringselementen från rutnätets rubrik.

När det totala antalet produkter i rutnätet är begränsat påverkas inte massåtgärder i produktrutnätet. Det påverkar bara presentationsskiktet för produktrutnät. Det finns till exempel ett begränsat antal 20000 produkter i rutnätet, användaren klickar på Select All, väljer massåtgärden Update attributes och uppdaterar vissa attribut. Därför uppdateras alla produkter, inte den begränsade samlingen av 20000 poster.

Begränsningen för produktstödraster påverkar bara produktsamlingar som används av gränssnittskomponenter. Därför påverkas inte alla produktrutnät av den här begränsningen. Endast de som använder Magento\Catalog\Ui\DataProvider\Product\ProductCollection.
Du kan endast begränsa produktstödrastersamlingar på följande sidor:

Om du inte vill att produktrutnätet ska begränsas bör du använda filter mer exakt så att resultatsamlingen har färre objekt än Records Limit.