Riktlinjer för prestanda performance-guidelines
Den här sidan innehåller allmänna riktlinjer för hur du optimerar prestandan för AEM. Om du inte har AEM tidigare bör du granska följande sidor innan du börjar läsa riktlinjerna för prestanda:
Illustrator below are the deployment options available for AEM (scroll to view all the options):
När prestandarådarna ska användas when-to-use-the-performance-guidelines
Använd riktlinjerna för prestanda i följande situationer:
- Första gången du distribuerar: När du planerar att distribuera AEM Sites eller Assets för första gången är det viktigt att du förstår vilka alternativ som är tillgängliga. Särskilt när du konfigurerar Micro Kernel, Node Store och Data Store (jämfört med standardinställningarna). Om du till exempel ändrar standardinställningarna för datalagret för tarMK till fildatalagret.
- Uppgraderar till en ny version: När du uppgraderar till en ny version är det viktigt att du förstår prestandaskillnaderna jämfört med körningsmiljön. Du kan till exempel uppgradera från AEM 6.1 till 6.2 eller från AEM 6.0 CRX2 till 6.2 OAK.
- Svarstiden är långsam: När den valda Nodestore-arkitekturen inte uppfyller dina krav är det viktigt att förstå prestandaskillnaderna jämfört med andra topologialternativ. Du kan till exempel distribuera tarMK i stället för MongoMK, eller använda en File Data Store i stället för ett Amazon S3- eller Microsoft® Azure-datalager.
- Lägger till fler författare: Om den rekommenderade TjärMK-topologin inte uppfyller prestandakraven och om redigeringsnoden har uppnått den maximala tillgängliga kapaciteten, måste du förstå prestandaskillnaderna. Jämför med att använda MongoMK med tre eller fler Author-noder. Du kan till exempel distribuera MongoMK i stället för tarMK.
- Lägga till mer innehåll: När den rekommenderade datalagerarkitekturen inte uppfyller dina krav är det viktigt att förstå prestandaskillnaderna jämfört med andra datalageralternativ. Exempel: använda Amazon S3 eller Microsoft® Azure Data Store i stället för ett File Data Store.
Introduktion introduction
I det här kapitlet ges en allmän översikt över den AEM arkitekturen och dess viktigaste komponenter. Den innehåller också riktlinjer för utveckling och beskriver de testscenarier som används i prestandatesterna TjärMK och MongoMK.
AEM Platform the-aem-platform
Den AEM plattformen består av följande komponenter:
Mer information om den AEM plattformen finns i Vad är AEM.
AEM arkitektur the-aem-architecture
Det finns tre viktiga byggstenar för en AEM. Författarinstansen som används av innehållsförfattare, redigerare och godkännare för att skapa och granska innehåll. När innehållet godkänns publiceras det till en andra instanstyp med namnet Publish Instance som slutanvändarna kommer åt det från. Det tredje byggblocket är Dispatcher som är en modul som hanterar cachelagring och URL-filtrering och som är installerad på webbservern. Mer information om den AEM arkitekturen finns i Vanliga distributionsscenarier.
Micro Kernels micro-kernels
Micro Kernels fungerar som beständiga chefer i AEM. Det finns tre typer av mikrokärnor som används med AEM: tarMK, MongoDB och Relational Database (med begränsat stöd). Vilken som passar bäst beror på instansens syfte och vilken distributionstyp du överväger. Mer information om Micro Kernels finns på sidan Rekommenderade distributioner.
Nodestore nodestore
I AEM kan binära data lagras oberoende av innehållsnoder. Platsen där binära data lagras kallas datalagret, medan platsen för innehållsnoderna och -egenskaperna kallas nodarkivet.
Datalager data-store
När du hanterar ett stort antal binära filer bör du använda ett externt datalager i stället för standardnodarkiven för att maximera prestandan. Om ditt projekt till exempel kräver många medieresurser och du lagrar dem under Arkiv eller Azure/S3 Data Store blir det snabbare att komma åt dem än att lagra dem direkt i en MongoDB.
Mer information om tillgängliga konfigurationsalternativ finns i Konfigurera nod- och datalager.
Sök search-features
I det här avsnittet finns de anpassade indexproviders som används med AEM. Mer information om indexering finns i Oak-frågor och indexering.
Utvecklingsriktlinjer development-guidelines
Utveckla för AEM som vill ha prestanda och skalbarhet. Här följer några tips som du kan följa:
GÖR
- Separera presentation, logik och innehåll
- Använd befintliga AEM-API:er (t.ex. Sling) och verktyg (t.ex. replikering)
- Utveckla i rätt sammanhang
- Utveckla för optimal tillgänglighet
- Minimera antalet besparingar (t.ex. genom att använda tillfälliga arbetsflöden)
- Kontrollera att alla HTTP-slutpunkter är RESTful
- Begränsa omfattningen av JCR-observation
- Tänk på asynkron tråd
GÖR INTE
-
Använd inte JCR-API:er direkt om du kan
-
Ändra inte /libs, utan använd i stället övertäckningar
-
Använd inte frågor där det är möjligt
-
Använd inte Sling Bindings för att få OSGi-tjänster i Java™-kod, utan använd istället:
- @Referens i en DS-komponent
- @Injicera i en körningsmodell
- sling.getService() i en lättanvänd klass
- sling.getService() i en JSP
- en ServiceTracker
- direktåtkomst till OSGi-tjänstregistret
Mer information om hur du utvecklar AEM finns i Utveckla - Grunderna. Mer information finns i Bästa metoder för utveckling.
Benchmark-scenarier benchmark-scenarios
De testscenarier som beskrivs nedan används för prestandatestavsnitten i kapitlen TjärMK, MongoMk och TjärMK jämfört med MongoMk. Läs avsnittet Scenario i tabellen Tekniska specifikationer om du vill se vilket scenario som användes för ett visst test.
Scenario för en produkt
AEM Assets:
- Användarinteraktioner: Bläddra i Assets/Sök i Assets/Hämta resurs/Läs resursmetadata/Uppdatera resursmetadata/Överför resurs/Kör arbetsflöde för överföring av resurs
- Körningsläge: samtidiga användare, en interaktion per användare
Scenario för blandade produkter
AEM Sites + Assets:
- Webbplatsanvändarinteraktioner: Läs artikelsida / Läs sida / Skapa stycke / Redigera stycke / Skapa innehållssida / Aktivera innehållssida / Författarsökning
- Assets användarinteraktioner: Bläddra i Assets/Sök i Assets/Hämta resurs/Läs resursmetadata/Uppdatera resursmetadata/Överför resurs/Kör arbetsflöde för överföring av resurs
- Körningsläge: samtidiga användare, blandade interaktioner per användare
Vertikalt scenario för användning
Media:
Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)- Körningsläge: samtidiga användare, blandade interaktioner per användare
tarMK tarmk
I det här kapitlet finns allmänna riktlinjer för prestanda för TjäraMK som specificerar minimikraven för arkitektur och inställningskonfigurationen. Riktmärkestester tillhandahålls också för ytterligare förtydliganden.
Adobe rekommenderar att TARMK är standardbeständighetstekniken som används av kunder i alla distributionsscenarier, både för AEM Author och Publish.
Mer information om TjärMK finns i Distributionsscenarier och Tjärlagring.
TaMK - riktlinjer för minimiarkitektur tarmk-minimum-architecture-guidelines
För att få goda prestanda när du använder tarMK bör du utgå från följande arkitektur:
- En författarinstans
- Två Publish-instanser
- Två utskickare
Nedan visas riktlinjerna för arkitektur för webbplatser AEM AEM Assets.
Riktlinjer för Tjärarkitektur för AEM Sites
Riktlinjer för Tjärarkitektur för AEM Assets
Riktlinje för inställningar för TARMK tarmk-settings-guideline
För bästa prestanda bör du följa riktlinjerna nedan. Instruktioner om hur du ändrar inställningarna finns i Prestandaoptimering.
Resultatjämförelse för tarMK tarmk-performance-benchmark
Tekniska specifikationer technical-specifications
Testerna utfördes på följande specifikationer:
Resultat av prestandatest performance-benchmark-results
MongoMK mongomk
Den främsta anledningen till att du väljer MongoMK-beständighetsbackend framför tarMK är att skalförändra instanserna vågrätt. Detta innebär att två eller flera aktiva författarinstanser alltid körs och att MongoDB används som beständigt lagringssystem. Behovet av att köra mer än en författarinstans beror i allmänhet på att processorn och minneskapaciteten på en enda server, som stöder alla samtidiga redigeringsaktiviteter, inte längre är hållbara.
Mer information om TjärMK finns i Distributionsscenarier och Mongo-lagring.
Riktlinjer för minimiarkitektur i MongoMK mongomk-minimum-architecture-guidelines
För att få bra prestanda när du använder MongoMK bör du utgå från följande arkitektur:
- Tre författarinstanser
- Två Publish-instanser
- Tre MongoDB-instanser
- Två utskickare
Riktlinjer för MongoMK-inställningar mongomk-settings-guidelines
För bästa prestanda bör du följa riktlinjerna nedan. Instruktioner om hur du ändrar inställningarna finns i Prestandaoptimering.
Prestandatest för MongoMK mongomk-performance-benchmark
Tekniska specifikationer technical-specifications-1
Testerna utfördes på följande specifikationer:
Resultat av prestandatest performance-benchmark-results-1
tarMK jämfört med MongoMK tarmk-vs-mongomk
Den grundläggande regeln som ska beaktas när du väljer mellan de två är att tarMK är utformat för prestanda, medan MongoMK används för skalbarhet. Adobe rekommenderar att TARMK är standardbeständighetstekniken som används av kunder i alla distributionsscenarier, både för AEM Author och Publish.
Den främsta anledningen till att du väljer MongoMK-beständighetsbackend framför tarMK är att skalförändra instanserna vågrätt. Den här funktionen innebär att två eller flera aktiva författarinstanser alltid körs och att MongoDB används som beständigt lagringssystem. Behovet av att köra mer än en författarinstans beror i allmänhet på att processorn och minneskapaciteten på en enda server, som stöder alla samtidiga redigeringsaktiviteter, inte längre är hållbara.
Mer information om TjäraMK och MongoMK finns i Rekommenderade distributioner.
Riktlinjer för tarMK jämfört med MongoMk tarmk-vs-mongomk-guidelines
Fördelar med tarMK
- Ändamålsenlig för content management-program
- Filerna är alltid konsekventa och kan säkerhetskopieras med valfritt filbaserat säkerhetskopieringsverktyg
- Tillhandahåller en redundansmekanism - mer information finns i Cold Standby
- Ger höga prestanda och tillförlitlig datalagring med minimal driftkostnad
- Lägre ägandekostnader (total ägandekostnad)
Villkor för val av MongoMK
- Antal namngivna användare som är anslutna under en dag: i tusental eller mer
- Antal samtidiga användare: i hundratals eller fler
- Volym för tillgångsförslag per dag: i hundratusentals eller fler
- Antal sidredigeringar per dag: hundratusentals eller fler
- Antal sökningar per dag: tiotusentals eller fler
Benchmarks för tarMK jämfört med MongoMK tarmk-vs-mongomk-benchmarks
Tekniska specifikationer för scenario 1 scenario-technical-specifications
Resultat av prestandatest för scenario 1 scenario-performance-benchmark-results
Tekniska specifikationer för scenario 2 scenario-technical-specifications-1
Resultat av prestandatest för scenario 2 scenario-performance-benchmark-results-1
Riktlinjer för arkitekturskalbarhet för AEM Sites och Assets architecture-scalability-guidelines-for-aem-sites-and-assets
Sammanfattning av riktlinjer för prestanda summary-of-performance-guidelines
Riktlinjerna på denna sida kan sammanfattas enligt följande:
-
tarMK med fildatastore - Den rekommenderade arkitekturen för de flesta kunder:
- Minimitopologi: en författarinstans, två Publish-instanser, två utskickare
- Binärfri replikering aktiveras om fildatalagret delas
-
MongoMK med File DataStore - Den rekommenderade arkitekturen för vågrät skalbarhet för Author-nivån:
- Minimitopologi: tre författarinstanser, tre MongoDB-instanser, två Publish-instanser, två Dispatchers
- Binärfri replikering aktiveras om fildatalagret delas
-
Nodestore - lagras på den lokala disken, inte ett nätverksanslutet lagringsutrymme (NAS)
-
När du använder Amazon S3:
- Amazon S3-datalagret delas mellan författaren och Publish-skiktet
- Binär replikering måste vara aktiverad
- Datastore Garbage Collection kräver en första körning på alla författarnoder och Publish-noder och sedan en andra körning på författaren
-
Anpassat index ska skapas utöver indexvärdet i rutan - baserat på de vanligaste sökningarna
- Lucene-index bör användas för anpassade index
-
Om du anpassar arbetsflödet kan prestandan förbättras avsevärt - Ta bort videomsteget i arbetsflödet Uppdatera resurs, inaktivera avlyssnare som inte används och så vidare.
Mer information finns också på sidan Rekommenderade distributioner.