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 använt AEM tidigare, gå igenom 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
Du bör använda 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 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.
- Uppgradera 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. Exempel: uppgradering 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 ett fildatalager i stället för ett Amazon S3- eller Microsoft Azure-datalager.
- Lägga till fler författare: När den rekommenderade TjäraMK-topologin inte uppfyller prestandakraven och om du uppgraderar redigeringsnoden så att den maximala tillgängliga kapaciteten nås, är det viktigt att förstå prestandaskillnaderna jämfört 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: med 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 the-aem-platform
Den AEM plattformen består av följande komponenter:
Mer information om AEM finns i Vad är AEM?.
Den AEM arkitekturen the-aem-architecture
Det finns tre viktiga byggstenar för en AEM driftsättning. The Författarinstans 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 som heter Publiceringsinstans från vilken slutanvändarna har åtkomst till den. Den tredje byggstenen ä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 Micro Kernels som används med AEM: TARMK, MongoDB och Relational Database (med begränsat stöd). Vilken som passar dina behov beror på syftet med instansen och vilken distributionstyp du överväger. Mer information om Micro Kernels finns i Rekommenderade distributioner sida.
Nodestore nodestore
I AEM kan binära data lagras oberoende av innehållsnoder. Platsen där binära data lagras kallas för Datalager, medan platsen för innehållsnoderna och -egenskaperna kallas för Node Store.
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 ett stort antal medieresurser kan du lagra dem under Arkiv eller Azure/S3 Data Store så att du kommer åt dem snabbare än att lagra dem direkt i en MongoDB.
Mer information om tillgängliga konfigurationsalternativ finns i Konfigurera nod- och datalager.
Sökning search-features
I det här avsnittet finns de anpassade indexproviders som används med AEM. Mer information om indexering finns i Fråga och indexering.
Utvecklingsriktlinjer development-guidelines
Du bör utveckla för AEM som vill prestanda och skalbarhet. Nedan visas ett antal metodtips 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
- Var uppmärksam på asynkron tråd
INTE
-
Använd inte JCR-API:er direkt om du kan
-
Ändra inte /libs, utan använd övertäckningar
-
Använd inte frågor där det är möjligt
-
Använd inte Sling Bindings för att hämta 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 Utveckling - Grunderna. Ytterligare metodtips finns på Bästa praxis 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. Om du vill se vilket scenario som användes för ett visst test av prestandatestet läser du avsnittet Scenario i Tekniska specifikationer tabell.
Scenario för en produkt
AEM Assets:
- Användarinteraktioner: Bläddra bland resurser/Sök resurser/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, enstaka interaktion per användare
Scenario med blandade produkter
AEM Sites + Assets:
- Webbplatsens användarinteraktioner: Läs artikelsidan / Läs sidan / Skapa stycke / Redigera stycke / Skapa innehållssida / Aktivera innehållssida / Författarsökning
- Resursens användarinteraktioner: Bläddra bland resurser/Sök resurser/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:
- Läs artikelsida (27,4 %), Läs sida (10,9 %), Skapa session (2,6 %), Aktivera innehållssida (1,7 %), Skapa innehållssida (0,4 %), Skapa stycke (4,3 %), Redigera stycke (0,9 %), Bildkomponent (0,9 %), Bläddra bland resurser (20 %), Läs resursmetadata (2) 8,5 %), Hämta resurs (4,2 %), Sökresurs (0,2 %), Uppdatera resursmetadata (2,4 %), Överför resurs (1,2 %), Bläddra i projekt (4,9 %), Läs projekt (6,6 %), Lägg till resurs i projekt (1,2 %), Lägg till webbplats i projekt (1,2 %), Skapa projekt (0,1 %), Författare eller Sök (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-instanserna.
Mer information om tarMK 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å publiceringsinstanser
- 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 visa den här sidan.
Resultatjämförelse för tarMK tarmk-performance-benchmark
Tekniska specifikationer technical-specifications
Testerna utfördes på följande specifikationer:
Resultat av prestandatest performance-bechmark-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. Det 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 tarMK 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å publiceringsinstanser
- 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 visa den här sidan.
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
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-instanserna.
Den främsta anledningen till att du väljer MongoMK-beständighetsbackend framför tarMK är att skalförändra instanserna vågrätt. Det 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 jämfört med 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 - se Vänteläge, kallt för mer information
- Ger höga prestanda och tillförlitlig datalagring med minimal driftkostnad
- Lägre ägandekostnader (total ägandekostnad)
Kriterier för att välja MongoMK
- Antal namngivna användare anslutna under en dag: i tusental eller mer
- Antal samtidiga användare: på hundratals eller fler
- Volym för tillgångsinmatningar per dag: på hundratusentals eller fler
- Antal sidredigeringar per dag: på 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 är den rekommenderade arkitekturen för de flesta kunder:
- Minimitopologi: en Author-instans, två Publish-instanser, två Dispatcher
- Binärfri replikering aktiveras om fildatalagret delas
-
MongoMK med File DataStore är den rekommenderade arkitekturen för vågrät skalbarhet för Author-nivån:
- Minimitopologi: tre Author-instanser, tre MongoDB-instanser, två Publish-instanser, två Dispatcher
- Binärfri replikering aktiveras om fildatalagret delas
-
Nodestore ska lagras på den lokala hårddisken, inte på en nätverksansluten lagringsplats (NAS)
-
När du använder Amazon S3:
- Amazon S3-datalagret delas mellan författaren och publiceringsskiktet
- Binär replikering måste vara aktiverad
- Datastore-skräpinsamlingen kräver en första körning på alla författar- och publiceringsnoder, och sedan en andra körning på författare
-
Anpassat index ska skapas utöver indexvärdet utanför 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, t.ex. borttagning av videosteget i arbetsflödet Uppdatera resurs, inaktivering av avlyssnare som inte används osv.
Mer information finns även i Rekommenderade distributioner sida.