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):

AEM

Produkt

Topologi
Operativsystem
Programserver
JRE
Dokumentskydd
Micro Kernel
Datastore
Indexering
Webbserver
Webbläsare
Experience Cloud
Sites
Ej-HA
Windows
CQSE
Oracle
LDAP
tar
Segment
Egenskap
Apache
Edge
Mål
Assets
Publish-HA
Solaris™
WebLogic
IBM®
SAML
MongoDB
Fil
Lucene
IIS
IE
Analyser
Communities
Author-CS
Red Hat®
WebSphere®
HP
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
FireFox
Campaign
Forms
Författaravlastning
HP-UX
Tomcat
RDB/DB2
MongoDB
Chrome
Social
Mobil
Författarkluster
IBM® AIX®
JBoss®
RDB/MySQL
RDBMS
Safari
Målgrupp
Flera platser
ASRP
SUSE®
RDB/SQLServer
Assets
Commerce
MSRP
APPLE OS
Aktivering
Dynamic Media
JSRP
Mobil
Brand Portal
J2E
AoD
LiveFyre
Screens
Dokumentsäkerhet
Processhantering
datorprogram
NOTE
Riktlinjerna gäller i huvudsak AEM Sites.

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:

chlimage_1

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.

chlimage_1-1

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.

chlimage_1-2

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.

NOTE
Adobe rekommenderar att TARMK är standardbeständighetstekniken som används av kunder både för AEM författare och Publish.
CAUTION
Mikrokärnan i relationsdatabasen har begränsat stöd. Kontakta Adobe kundtjänst innan du använder den här typen av mikrokärna.

chlimage_1-3

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.

NOTE
Adobe rekommenderar att du väljer alternativet att distribuera AEM på Azure eller Amazon Web Services (AWS) med Adobe Managed Services. Kunderna drar nytta av ett team som har erfarenhet och kompetens av att driftsätta och AEM i dessa molnmiljöer. Se ytterligare dokumentation om Adobe Managed Services.
Adobe rekommenderar att du arbetar direkt med molnleverantören för att få rekommendationer om hur du ska distribuera AEM på Azure eller AWS utanför Adobe Managed Services. Eller samarbeta med en av Adobe som stöder driftsättningen av AEM i molnmiljön. Den valda molnleverantören eller partnern ansvarar för storleksspecifikationerna, designen och implementeringen av den arkitektur de stöder för att uppfylla just dina krav på prestanda, belastning, skalbarhet och säkerhet.
​>Se även sidan Tekniska krav.

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.

NOTE
För de flesta installationer rekommenderar Adobe att du använder Lucene-index. Använd Solr endast för skalbarhet vid specialiserad och komplex driftsättning.

chlimage_1-4

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

NOTE
Alla test som visas på den här sidan har utförts i laboratoriemiljö.

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

NOTE
De riktlinjer för minimiarkitektur som presenteras nedan gäller produktionsmiljöer och stora trafikplatser. Riktlinjerna är inte de lägsta specifikationerna som ska köras AEM.

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.

NOTE
Binärfri replikering ska vara ON om fildatalagret delas.

Riktlinjer för Tjärarkitektur för AEM Sites

chlimage_1-5

Riktlinjer för Tjärarkitektur för AEM Assets

chlimage_1-6

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 på den här sidan.

Inställning
Parameter
Värde
Beskrivning
Sling-jobbköer
queue.maxparallel
Ange värdet till hälften av antalet processorkärnor.
Som standard är antalet samtidiga trådar per jobbkö lika med antalet processorkärnor.
Bevilja tillfällig arbetsflödeskö
Max Parallel
Ange värdet till hälften av antalet processorkärnor
JVM-parametrar

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

True

Om du vill förhindra att expanderande frågor överbelastar systemen lägger du till dessa JVM-parametrar i AEM startskript.
Lucene-indexkonfiguration

CopyOnRead

CopyOnWrite

Prefetch Index Files

Aktiverad

Aktiverad

Aktiverad

Mer information om tillgängliga parametrar finns på den här sidan.
Datalager = S3 Datastore

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) eller mindre

2-10 % av maximal stackstorlek

Se även Datalagerkonfigurationer.
Arbetsflöde för DAM-uppdatering
Transient Workflow
checked
Det här arbetsflödet hanterar uppdateringen av resurser.
DAM MetaData Writeback
Transient Workflow
checked
Det här arbetsflödet hanterar XMP återskrivning till det ursprungliga binärdokumentet och anger det senaste ändringsdatumet i JCR.

Resultatjämförelse för tarMK tarmk-performance-benchmark

Tekniska specifikationer technical-specifications

Testerna utfördes på följande specifikationer:

Författarnod
Server
Maskinvara av barrmetall (HP)
Operativsystem
Red Hat® Linux®
Processor/kärnor
Processorn Intel® Xeon® E5-2407 @2,40 GHz, 8 kärnor
RAM
32 GB
Skiva
Magnetiskt
Java™
Oracle JRE version 8
JVM-heap
16 GB
Produkt
AEM 6.2
Nodestore
tarMK
Datastore
Fil-DS
Scenario
En produkt: Assets/30 samtidiga trådar

Resultat av prestandatest performance-benchmark-results

NOTE
Siffrorna nedan har normaliserats till 1 som baslinje och är inte de faktiska flödenumren.

chlimage_1-7 chlimage_1-8

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
NOTE
I produktionsmiljöer används MongoDB alltid som en replikuppsättning med en primär och två sekundära. Läsningar och skrivningar går till huvudlistan och läsningar kan gå till de sekundära. Om lagring inte är tillgängligt kan en av de sekundära ersättas med en skiljedomare, men MongoDB-replikuppsättningar måste alltid bestå av ett ojämnt antal instanser.
NOTE
Binärfri replikering ska vara ON om fildatalagret delas.

chlimage_1-9

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 på den här sidan.

Inställning
Parameter
Värde (standard)
Beskrivning
Sling-jobbköer
queue.maxparallel
Ange värdet till hälften av antalet processorkärnor.
Som standard är antalet samtidiga trådar per jobbkö lika med antalet processorkärnor.
Bevilja tillfällig arbetsflödeskö
Max Parallel
Ange värdet till hälften av antalet processorkärnor.
JVM-parametrar

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

True

60000

Om du vill förhindra att expanderande frågor överbelastar systemen lägger du till dessa JVM-parametrar i AEM startskript.
Lucene-indexkonfiguration

CopyOnRead

CopyOnWrite

Prefetch Index Files

Aktiverad

Aktiverad

Aktiverad

Mer information om tillgängliga parametrar finns på den här sidan.
Datalager = S3 Datastore

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) eller mindre

2-10 % av maximal stackstorlek

Se även Datalagerkonfigurationer.
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

35 (25)

20 (10)

30 (5)

10 (3)

4 (4)

./cache,size=2048,binary=0,-compact,-compress

Standardstorleken för cachen är 256 MB.

Påverkar hur lång tid det tar att göra cachen ogiltig.

ek-observation

thread pool

length

min & max = 20

50000

Prestandatest för MongoMK mongomk-performance-benchmark

Tekniska specifikationer technical-specifications-1

Testerna utfördes på följande specifikationer:

Författarnod
MongoDB-nod
Server
Maskinvara av barrmetall (HP)
Maskinvara av barrmetall (HP)
Operativsystem
Red Hat® Linux®
Red Hat® Linux®
Processor/kärnor
Processorn Intel® Xeon® E5-2407 @2,40 GHz, 8 kärnor
Processorn Intel® Xeon® E5-2407 @2,40 GHz, 8 kärnor
RAM
32 GB
32 GB
Skiva
Magnetiskt - >1 k IOPS
Magnetiskt - >1 k IOPS
Java™
Oracle JRE version 8
Ej tillämpligt
JVM-heap
16 GB
Ej tillämpligt
Produkt
AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore
MongoMK
Ej tillämpligt
Datastore
Fil-DS
Ej tillämpligt
Scenario
En produkt: Assets/30 samtidiga trådar
En produkt: Assets/30 samtidiga trådar

Resultat av prestandatest performance-benchmark-results-1

NOTE
Siffrorna nedan har normaliserats till 1 som baslinje och är inte de faktiska flödenumren.

chlimage_1-10 chlimage_1-11

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

NOTE
Siffrorna nedan har normaliserats till 1 som baslinje och är inte faktiska flödesnummer.

Tekniska specifikationer för scenario 1 scenario-technical-specifications

Skapa OAK Node
MongoDB-nod
Server
Maskinvara av barrmetall (HP)
Maskinvara av barrmetall (HP)
Operativsystem
Red Hat® Linux®
Red Hat® Linux®
Processor/kärnor
Processorn Intel(R) Xeon(R) E5-2407 @2,40 GHz, 8 kärnor
Processorn Intel(R) Xeon(R) E5-2407 @2,40 GHz, 8 kärnor
RAM
32 GB
32 GB
Skiva
Magnetiskt - >1 k IOPS
Magnetiskt - >1 k IOPS
Java™
Oracle JRE version 8
Ej tillämpligt
JVM Heap16 GB
16 GB
Ej tillämpligt
Produkt
AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore
tarMK eller MongoMK
Ej tillämpligt
Datastore
Fil-DS
Ej tillämpligt
Scenario
En produkt: Assets/30 samtidiga trådar per körning

Resultat av prestandatest för scenario 1 scenario-performance-benchmark-results

chlimage_1-12

Tekniska specifikationer för scenario 2 scenario-technical-specifications-1

NOTE
Om du vill aktivera samma antal författare med MongoDB som med ett tarMK-system behöver du ett kluster med två AEM noder. Ett mongoDB-kluster med fyra noder kan hantera 1,8 gånger så många författare som en tarMK-instans. Ett åtta-nods MongoDB-kluster kan hantera 2,3 gånger så många författare som en tarMK-instans.
Författare tarMK-nod
Författare MongoMK-nod
MongoDB-nod
Server
AWS c3.8xlarge
AWS c3.8xlarge
AWS c3.8xlarge
Operativsystem
Red Hat® Linux®
Red Hat® Linux®
Red Hat® Linux®
Processor/kärnor
32
32
32
RAM
60 GB
60 GB
60 GB
Skiva
SSD - 10 000 IOPS
SSD - 10 000 IOPS
SSD - 10 000 IOPS
Java™
Oracle JRE version 8
Oracle JRE version 8
Ej tillämpligt
JVM Heap16 GB
30 GB
30 GB
Ej tillämpligt
Produkt
AEM 6.2
AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore
tarMK
MongoMK
Ej tillämpligt
Datastore
Fil-DS
Fil-DS
Ej tillämpligt
Scenario
Vertikalt användningsfall: Media/2000 samtidiga trådar

Resultat av prestandatest för scenario 2 scenario-performance-benchmark-results-1

chlimage_1-13

Riktlinjer för arkitekturskalbarhet för AEM Sites och Assets architecture-scalability-guidelines-for-aem-sites-and-assets

chlimage_1-14

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.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2