AEM 6.x | Tips för prestandajustering

Implementera och kör inläsningstester som simulerar realistiska scenarier i både författare- och publiceringsinstanser. Att utforska och definiera den förväntade belastningen är ett viktigt steg i den här processen. I det här steget får du hjälp att visa om AEM program, arkitektur och AEM fungerar bra när de finns i en produktionsmiljö.
Resultatet av den här övningen hjälper till att avgöra om det finns ett fel i konfiguration, programproblem, storleksändring, maskinvaruproblem eller andra problem som påverkar systemets prestanda. Se även riktlinjerna för prestanda och övervakning.

Förutom belastningstestning hjälper stresstestning till att definiera den maximala belastning som systemet kan hantera. Det här testet kan hjälpa dig att förbereda dig för trafiktoppar. Mer information om prestandatestning finns här.

Installera rekommenderade AEM, kumulativa korrigeringspaket och snabbkorrigeringar: Adobe Experience Manager-versionsuppdateringar.

Om du använder Windows-servern ska du granska den här artikeln.

Om du planerar att läsa in stora mängder resurser (bilder, videoklipp och så vidare) till AEM bör du kontrollera att du använder Assets bästa praxis.

Tillräckligt med RAM och undvik IO-mättnad
Om du tänker köra produktionen i någon skala bör Linux-miljön förses med så mycket RAM som segmenttjärfilerna kommer att växa till mellan offlinekomprimering (eller online-komprimeringstopp). Dessutom undviker följande IO-mättnad.

• Separata operativsystem, data och loggningsdiskar
• Montera datadiskar med Noatime.
• Ställ in read-ahead-buffertar på 32 på datadisk.
• Bäst är att använda XFS över ext4 på datadrivna diskar.
• Om RedHat körs på en virtuell dator ska du kontrollera att entropy-poolen alltid är > 1 K bitar (använd ngtools om det behövs)

Inaktivera genomskinliga stora sidor i Linux
AEM utför finkorniga läs-/skrivåtgärder, medan Linux-genomskinliga stora sidor är optimerade för stora åtgärder, så vi rekommenderar att du inaktiverar genomskinliga stora sidor när du använder Mongo- eller Tjära-lagring.

Möjliggöra tillfälliga arbetsflöden
Övergående arbetsflöden kan användas för alla arbetsflöden som:

• körs ofta.
• behöver inte arbetsflödeshistoriken.

De ger en prestandaökning i dessa situationer.
Det här användningsexemplet är vanligtvis uppfyllt när det finns stora mängder resurser som används.
Följ proceduren som beskrivs i Prestandajustering av Assets.

Justera köer för delningsjobb
Massöverföring av stora resurser är vanligtvis en mycket resurskrävande process. Som standard är antalet samtidiga trådar per jobbkö lika med antalet processorkärnor. Därför kan den här värdeinställningen ge en generell prestandapåverkan och hög Java-heap-förbrukning.
Adobe rekommenderar att du inte överskrider 50 % av processorkärnorna. Om du vill justera det här värdet går du till https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration:
Ange queue.maxparallel till ett värde som representerar 50 % av processorkärnorna på servern som är värd för AEM. För 8 processorkärnor anger du till exempel värdet 4.

Anpassa din Oak-databas
Kontrollera först att du har den senaste Oak-versionen installerad för AEM 6. Kontrollera den rekommenderade snabbkorrigeringssidan som nämns ovan.

Oak Query Engine/Index-optimeringar

• Skapa anpassade ekindexvärden för alla sökfrågor som används ofta.

  • Mer information om hur du analyserar långsamma frågor finns i den här artikeln.
  • Skapa anpassade index under noden ek:index för alla sökegenskaper som du vill söka med genom att följa den här artikeln.
  • För varje anpassat Lucene-baserat index kan du försöka ange inställningen includedPaths (String) så att indexet bara tillämpas på vissa innehållssökvägar. Begränsa sedan sökningarna till de sökvägar som ingår i indexet.

• JVM-parametrar
  Lägg till dessa JVM-parametrar i AEM startskript för att förhindra att expanderande frågor överbelastar systemen. Observera att det här är standardvärden AEM 6.3.

  • Doak.queryLimitInMemory=500000 (se även Oak-dokumentation)
  • Doak.queryLimitReads=100000 (se även Oak-dokumentation)
  • Dupdate.limit=250000 (endast för DocumentNodeStore, t.ex. MongoMK, RDBMK)

  Följande alternativ kan förbättra prestandan, men ändrar innebörden av anropet till resultatstorlek. I synnerhet beaktas endast frågebegränsningar som är en del av det index som används vid beräkning av storleken.
  Dessutom tillämpas inte åtkomstkontrollistor på resultaten, så noder som inte är synliga för den aktuella sessionen inkluderas fortfarande i det antal som returneras. Därför kan antalet som returneras vara högre än det faktiska antalet resultat och det korrekta antalet kan endast bestämmas genom iterering genom resultaten:

  • Doak.fastQuerySize=true (se även Resultatstorlek i Oak-dokumentation)

  Varning! Om du aktiverar fastQuerySize resulterar det i snabbare frågesvar. AEM returnerar emellertid felaktiga resultatantal för vissa frågor. Använd inte fastQuerySize om du förlitar dig på exakta resultatantal i programmet.

• Lucene-indexkonfiguration
  Öppna /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService och

  • aktivera CopyOnRead (aktiverat som standard sedan AEM 6.2)
  • aktivera CopyOnWrite (aktiverat som standard sedan AEM 6.2)
  • aktivera Förhämta indexfiler (aktiverat som standard sedan AEM 6.2)

  Mer information om tillgängliga parametrar finns på https://jackrabbit.apache.org/oak/docs/query/lucene.html
  Eftersom vissa sökvägar inte behöver indexeras kan du göra följande:
  I CRXDE Lite går du till /oak:index/lucene, anger en strängegenskap med flera värden (String)som heter excludePaths med dessa värden /var, /etc/workflow/instances, /etc/replication.

• Datalager
  Om du använder AEM Assets eller har ett AEM som använder binära filer i stor utsträckning rekommenderar Adobe att du använder ett externt datalager. Om du använder ett externt datalager får du maximala prestanda. Mer information finns i dokumentationen.
  När du använder en FileDataStore kan du justera cacheSizeInMB till en procentandel av den tillgängliga stacken. Ett konservativt värde är 2 % av den maximala stacken. Exempel: för en heap på 8 GB:

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  Observera att maxCachedBinarySize har värdet 1 MB (1048576). Därför cachelagras endast filer som är högst 1 MB. Det kan också vara bra att justera den här inställningen till ett lägre värde.
  När du arbetar med ett stort antal binära filer vill du maximera prestanda. Därför rekommenderar Adobe att ett externt datalager används i stället för standardnodarkiven. Adobe rekommenderar dessutom att du justerar följande parametrar:

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  Obs! Inställningen cacheSizeInMB kan göra att Java-processen får slut på minne om den är för hög. Om du till exempel har den maximala stackstorleken inställd på 8 GB (-Xmx8g) och du förväntar dig att AEM och att programmet ska använda en kombinerad heap på 4 GB, är det bra att ställa in cacheSizeInMB på 82 i stället för 164. Inom intervallet 2-10 % av den maximala stacken är en säker konfiguration. Adobe rekommenderar dock att du validerar inställningsändringar med inläsningstestning samtidigt som minnesanvändningen övervakas.

Mongo-lagringsjustering

• Cachestorlek för MongoBlobStore: BLOBstore används för att lagra och läsa stora binära objekt. Internt implementeras arkivet med cache som delar binärfilerna i relativt små block (data- eller hash-kod eller indirekt hash-kod) så att varje block får plats i minnet. I en standardinställning använder MongoBlobStore en fast cachestorlek på 16 MB. För distributioner där det finns mer RAM-minne och där blobblagring ofta används (t.ex. när Lucene-indexet är stort) ökar du cachestorleken. Den här cachestorleken gäller bara när du använder MongoBlobStore (standard), inte när du använder ett externt blobstore.

  • Du kan konfigurera cachestorleken (i MB) med inställningen blobCacheSize på DocumentNodeStoreService.
    Exempel: blobCacheSize=1024
  • Granska även AEM-MongoDB checklista.

• Dokumentcache-storlek: För att optimera prestanda för läsning av noder från MongoDB måste du justera cachestorlekarna för DocumentNodeStore. Standardstorleken för cachen är 256 MB, som fördelas mellan olika cacheminnen som används i DocumentNodeStore. Se http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

  • Du kan konfigurera cachestorleken (MB) med cacheinställningen för DocumentNodeStoreService. Exempel: cache=2048.

  • Ställ in alla följande cachekonfigurationer i crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configoch läs sedan in test med olika värden för att se vilken som är bäst för din miljö. Observera att återstående cache-procent ges till dokumentcachen:

    • cache=2048
    • nodeCachePercentage=35
    • childrenCachePercentage=20
    • diffCachePercentage=30
    • docChildrenCachePercentage=10

  • Med ovanstående konfiguration utgör procentsatserna totalt 95 %. Återstående 5 % av cacheminnet ges till documentCache. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • Kontrollera att den återstående cachen för documentCache inte är särskilt stor när du distribuerar procentsatserna för cacheminnet. Det vill säga, håll den högst 500 MB. En stor documentCache kan leda till en ökad tid för att utföra cacheogiltigförklaring.

• Cacheinställningar i AEM 6.2 med Oak 1.4.x:

  • I AEM 6.2 ändrades hur de här cacheinställningarna fungerar. I AEM 6.2 med Oak 1.4 finns det ett nytt cacheminne: prevDocCache. Du kan konfigurera det här cacheminnet med inställningen prevDocCachePercentage. Standardvärdet är 4.
  • DocumentCache använder den återstående cacheminnet-MB (cacheinställning minus storleken på alla andra cacheminnen): documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• Implementera kontrollistan för MongoDB-produktionen:
  https://docs.mongodb.org/manual/administration/production-checklist/ - Enligt Mongo DB-stöd har många av objekten stor inverkan på prestandan. Kontakta MongoDB-supporten direkt om du har frågor.

• Läsprestanda: Lägg till den här frågesträngsparametern i Mongo DB-URL:en på varje AEM nod: ?readPreference=secondaryPreferred
  Den här parametern anger för systemet att göra läsningar från den sekundära, vilket ger extra läsprestanda.

• Öka trådpoolen för ekaövervakning: open /system/console/configMgr/org.apache.sling.Commons.threads.impl.DefaultThreadPool.factory Ställ in namnet på ekv-observation och ställ in min- och maxpoolstorleken på 20.

• Öka längden på observationskön: Skapa en fil med namnet .adobe.granite.database.impl.SlingRepositoryManager.cfg som innehåller parametern oak.observation.queue-length=50000. Placera den under mappen /crx - snabbstart/install.

• Undvik frågor som körs länge: Ange systemegenskapen i JVM-parametrarna: -Doak.mongo.maxQueryTimeMS=60000 för att undvika frågor som körs längre än en minut.

Stjärllagringsinställning
Microkernels anropar inte minnesmappade filer direkt. JDK använder dock internt minnesmappade filer för effektiv läsning. I vissa Windows 64-bitars operativsystem kan det misslyckas med att rensa minnesmappade filer och utnyttja allt systemminne. Kontrollera att du har installerat prestandarelaterade korrigeringsfiler/snabbkorrigeringar från Microsoft (se KB 2731284) och Oracle.

Ett annat alternativ är att inaktivera minnesmappningsläget genom att lägga till target.mode=32 i SegmentNodeStoreService.config tills operativsystemsproblemet är löst. Nackdelen med inaktivering gör I/O-intensiva. Se till att höja I/O-sidlåsgränsen.

StjärtMK-revisionen ren (kompaktion)
Från och med AEM 6.3 är onlinekomprimeringen (även kallad rensning av onlineändringar) aktiverad som standard. Mer information finns på den här sidan.

Användare av Cloud Manager för Adobe Managed Services (AMS)
Med Cloud Manager (endast AMS-användare) kan du säkerställa AEM driftsättning med guidad prestandatestning och autoskalning.