AEM 6,x | Tips voor afstemmen van prestaties

Implementeer en voer belastingstests uit die realistische scenario's in zowel auteur als publiceer instanties simuleren. Het zoeken naar en het bepalen van de verwachte belasting is een cruciale stap in dit proces. Deze stap helpt u aantonen of de AEM toepassing, architectuur en AEM installatie goed zal presteren zodra het in een productiemilieu is.
De resultaten van deze oefening helpen bepalen of er een misconfiguratie, toepassingskwestie, grootte, hardwareprobleem, of een andere kwestie die de systeemprestaties beïnvloedt zijn. Zie ook de prestatiesrichtlijnenen controlerichtlijnen.

Naast het testen van de belasting, helpt het testen van de belasting om de maximale belasting te bepalen die het systeem kan verwerken. Deze test kan u helpen zich op verkeerspikes voorbereiden. Meer informatie over prestaties het testen kan hierworden gevonden.

Installeer de geadviseerde AEM de dienstpakken, cumulatieve moeilijke fixpakken en hotfixes: de versieupdates van Adobe Experience Manager.

Als u de server van Vensters gebruikt, herzie dan dit artikel.

Als u van plan bent om grote hoeveelheden activa (beelden, video's, etc.) in AEM te laden, dan zorg ervoor u de beste praktijken van Assetstoepast.

Zorg voor voldoende RAM en vermijd IO-verzadiging
Als u productie op om het even welke schaal wilt in werking stellen dan zou het milieu van Linux van zo veel RAM moeten worden voorzien aangezien de dossiers van de segmentteer aan tussen off-line samenperking (of online samenstellingspieken) zullen groeien. Bovendien wordt IO-verzadiging vermeden door:

• Schijven voor besturingssysteem, gegevens en logboekregistratie
• Gegevensschijven koppelen met Noatime.
• Stel 'read-ahead'-buffers in op 32 op de gegevensschijf.
• In het ideale geval gebruikt u XFS via Text4 op de gegevensschijven.
• Als RedHat in een VM wordt uitgevoerd, moet u ervoor zorgen dat de entropiepool altijd > 1 kB bits is (gebruik indien nodig hulpprogramma's)

Transparante grote pagina's uitschakelen in Linux
AEM voert verfijnde lees/schrijft uit, terwijl de Transparante Pagina's van de Geheime PAGINA's van Linux voor grote verrichtingen worden geoptimaliseerd, zodat wordt het geadviseerd Transparante Pagina's van de Groot onbruikbaar te makenwanneer het gebruiken van Mongo of de opslag van de Tar.

Tijdelijke workflows inschakelen
U kunt tijdelijke workflows gebruiken voor workflows die:

• worden vaak uitgevoerd.
• hebt de workflowgeschiedenis niet nodig.

In dergelijke situaties zullen ze de prestaties verbeteren.
Aan dit gebruiksgeval wordt doorgaans voldaan wanneer er grote hoeveelheden activa worden opgenomen.
Volg de procedure die op Prestaties wordt gedocumenteerd die Assetsstemmen.

Reeksen taken afstemmen
Het uploaden van grote bedrijfsmiddelen in bulk is doorgaans een zeer bronintensief proces. Standaard is het aantal gelijktijdige threads per taakwachtrij gelijk aan het aantal CPU-cores. Als zodanig kan deze instelling een invloed hebben op de algehele prestaties en een hoog Java-heap-verbruik.
Adobe raadt u aan niet meer dan 50% van de CPU-cores te gebruiken. Ga als volgt te werk om deze waarde aan te passen: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Stel queue.maxparallel in op een waarde die 50% vertegenwoordigt van de CPU-cores van de server die als host fungeert voor de AEM instantie. Stel de waarde voor 8 CPU-cores bijvoorbeeld in op 4.

Je Oak-opslagplaats afstemmen
Controleer eerst of u de nieuwste Oak-versie hebt geïnstalleerd voor uw AEM 6-exemplaar. Controleer de bovenstaande pagina met aanbevolen hotfixes.

de optimalisaties van de Motor/van de Index van de Vraag van Oak

• creeer de indexen van het douaneeik voor alle vaak gebruikte onderzoeksvragen.

  • Voor informatie over hoe te om langzame vragen te analyseren zie dit artikel.
  • Creeer de douaneindexen onder het eik:indexknoop voor alle onderzoekseigenschappen die u wilt zoeken met door dit artikelte volgen.
  • Probeer voor elke aangepaste index op basis van Luceen de instelling includePaths (String) in te stellen om de index te beperken tot alleen bepaalde inhoudspaden. Vervolgens beperkt u de toepasselijke zoekopdrachten tot de paden die door de index worden opgenomen.

• parameters JVM
  Voeg deze JVM-parameters toe aan het AEM-beginscript om te voorkomen dat uitgebreide query's de systemen overladen. Dit zijn standaardwaarden vanaf AEM 6.3.

  • Doak.queryLimitInMemory=500000 (zie ook {de documentatie van 0} Oak 🔗)
  • Doak.queryLimitReads=100000 (zie ook {de documentatie van 0} Oak 🔗)
  • Dupdate.limit=250000 (alleen voor DocumentNodeStore, bijvoorbeeld. MongoMK, RDBMK)

  De volgende optie zou ook prestaties kunnen verbeteren, maar verandert de betekenis van de vraag van de resultaatgrootte. Vooral, slechts worden de vraagbeperkingen die deel van de gebruikte index uitmaken overwogen wanneer het berekenen van de grootte.
  Bovendien, wordt ACLs niet toegepast op de resultaten, zodat zullen de knopen die niet zichtbaar aan de huidige zitting zijn nog inbegrepen in de teruggekeerde telling zijn. Als zodanig kan het aantal geretourneerde waarden hoger zijn dan het werkelijke aantal resultaten en kan het juiste aantal alleen worden bepaald door de resultaten te doorlopen:

  • Doak.fastQuerySize=true (zie ook de Grootte van het Resultaat in documentatie van Oak)

  Voorzichtigheid: Het toelaten van fastQuerySize resulteert in snellere vraagreacties. Nochtans, AEM keert onnauwkeurige resultaattellingen voor sommige vragen terug. Als u op nauwkeurige resultaattellingen in uw toepassing vertrouwt, gebruik niet fastQuerySize.

• de indexconfiguratie van Lucene
  Open /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService en

  • laat CopyOnRead toe (die door gebrek sinds AEM 6.2 wordt toegelaten)
  • laat CopyOnWrite toe (die door gebrek sinds AEM 6.2 wordt toegelaten)
  • laat Prefetch de Dossiers van de Index toe (toegelaten door gebrek sinds AEM 6.2)

  Zie https://jackrabbit.apache.org/oak/docs/query/lucene.htmlvoor meer informatie over de beschikbare parameters
  Omdat sommige paden niet hoeven te worden geïndexeerd, kunt u het volgende doen:
  In CRXDE Lite, ga naar /oak:index/lucene, plaats een multivalue koordbezit (Koord) genoemd excludePaths met deze waarden /var, /etc/workflow/instances, /etc/replication.

• Opslag van Gegevens
  Als u AEM Assets gebruikt of een AEM toepassing hebt die veel binaire bestanden gebruikt, raadt de Adobe u aan een externe datastore te gebruiken. Het gebruik van een externe datastore helpt maximale prestaties te garanderen. Zie documentatie voor gedetailleerde instructies.
  Wanneer u een FileDataStore gebruikt, moet u cacheSizeInMB afstemmen op een percentage van de beschikbare heap. Een conservatieve waarde is 2% van de maximale heap. Bijvoorbeeld voor een 8 GB heap:

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  Merk op dat maxCachedBinarySize aan 1 MB (1048576) wordt geplaatst. Als dusdanig, geheime voorgeheugens slechts dossiers die een maximum van 1 MB zijn. Het kan ook zinvol zijn deze instelling op een lagere waarde in te stellen.
  Wanneer u met een groot aantal binaire getallen werkt, wilt u de prestaties maximaliseren. Daarom adviseert de Adobe dat een externe datastore in plaats van de standaardknoopopslag wordt gebruikt. Daarnaast wordt u door de Adobe aangeraden de volgende parameters in te stellen:

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  Nota: Het cacheSizeInMB plaatsen kan het proces van Java veroorzaken om uit geheugen te lopen als het te hoog wordt geplaatst. Als u bijvoorbeeld de maximale heapgrootte hebt ingesteld op 8 GB (-Xmx8g) en u verwacht dat AEM en uw toepassing een gecombineerde heap van 4 GB gebruiken, heeft het zin cacheSizeInMB in te stellen op 82 in plaats van 164. In het bereik van 2-10% van de maximale heap is een veilige configuratie. De Adobe raadt u echter aan wijzigingen in de instellingen te valideren door het laden te testen en het geheugengebruik te controleren.

Mongo-opslagtuning

• MongoBlobStore geheim voorgeheugengrootte: Blobstore wordt gebruikt om grote binaire voorwerpen op te slaan en te lezen. Intern, wordt de opslag met geheim voorgeheugen uitgevoerd die de binaire getallen in vrij kleine blokken (gegevens of knoeiboelcode of indirecte knoeiboel) splitst, zodat elk blok in geheugen past. In een standaardinstelling gebruikt de MongoBlobStore een vaste cachegrootte van 16 MB. Voor plaatsingen waar meer RAM beschikbaar is en de blob opslag vaak wordt betreden (bijvoorbeeld, wanneer de index van Lucene groot is), vergroot de geheim voorgeheugengrootte. Deze cachegrootte is alleen van toepassing wanneer u MongoBlobStore gebruikt (standaard), niet wanneer u een externe opslag gebruikt.

  • U kunt de geheim voorgeheugengrootte (in MB) vormen als blobCacheSize die op plaatst DocumentNodeStoreService.
    Bijvoorbeeld: blobCacheSize=1024
  • Gelieve te herzien ook AEM-MongoDB checklist.

• het geheime voorgeheugengrootte van het Document: om de prestaties van het lezen knopen van MongoDB te optimaliseren moet u de geheime voorgeheugengrootte van DocumentNodeStore stemmen. De standaardgrootte van het geheime voorgeheugen wordt geplaatst aan 256 MB, die onder diverse geheime voorgeheugens wordt verdeeld die in DocumentNodeStore worden gebruikt. Zie http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

  • U kunt de cachegrootte (MB) configureren door de cacheset in DocumentNodeStoreService in te stellen. Bijvoorbeeld cache=2048.

  • Stel alle volgende cachemonfiguraties in crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configand en laad vervolgens test met verschillende waarden om te zien wat de optimale configuratie is voor uw omgeving. Het resterende cachepercentage wordt toegewezen aan de documentcache:

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

  • Bij de bovenstaande configuratie bedragen de percentages in totaal 95%. De resterende 5% van de cache wordt aan documentCache gegeven. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • Zorg er tijdens het distribueren van de cachepercentages voor dat de resterende cache voor documentCache niet erg groot is. Dat wil zeggen dat u de cache maximaal 500 MB wilt bewaren. Een grote documentCache kan ertoe leiden dat de tijd die nodig is om de cache-ongeldigmaking uit te voeren, langer wordt.

• montages van het Geheime voorgeheugen in AEM 6.2 met Oak 1.4.x:

  • In AEM 6.2 zijn wijzigingen aangebracht in de manier waarop deze cache-instellingen werken. In AEM 6.2 met Oak 1.4 is er een nieuwe cache: prevDocCache. U kunt dit geheime voorgeheugen vormen gebruikend het plaatsen prevDocCachePercentage. De standaardwaarde is 4.
  • De documentCache gebruikt de resterende cache-MB (cache-instelling min de grootte van alle andere cache): documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• voer de MongoDB productiecontrolelijst uit:
  https://docs.mongodb.org/manual/administration/production-checklist/- volgens de steun van Mongo DB, hebben vele punten een grote invloed op prestaties. Neem voor alle vragen rechtstreeks contact op met de ondersteuning van MongoDB.

• Lees prestaties: voeg deze parameter van het vraagkoord aan uw Mongo DB URL op elke AEM toe: ?readPreference=secundairPreferred
  Deze parameter vertelt het systeem om te doen leest van secundair die wat toegevoegde leesprestaties geeft.

• de draadpool van de verhoging voor eak-observatie: open /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory Stel de naam in op observering en stel de minimale en maximale groepsgrootte in op 20.

• de lengte van de de observatierij van de verhoging: creeer een dossier genoemd com.adobe.granite.repository.impl.SlingRepositoryManager.cfg bevattende parameter oak.observatie.queue-length=50000. Plaats het onder /crx-quickstart/install omslag.

• Vermijd langdurige query's: stel de eigenschap system in de JVM-parameters in: -Doak.mongo.maxQueryTimeMS=60000 om te voorkomen dat query's langer dan 1 minuut worden uitgevoerd.

Afstelling voor tapeopslag
Met microkorrels worden bestanden waaraan geheugen is toegewezen, niet rechtstreeks aangeroepen. JDK maakt echter intern gebruik van bestanden die aan geheugen zijn toegewezen voor efficiënt lezen. In bepaalde Windows 64-bits besturingssystemen kunnen bestanden die zijn toegewezen aan het geheugen, mogelijk niet worden opgeschoond en wordt het systeemgeheugen van de oorspronkelijke besturingssysteem volledig benut. Zorg ervoor om de prestaties betrekking hebbende flarden/hotfix van microsoft (zie KB 2731284) en Oracle te installeren.

Een alternatieve optie moet de wijze van de geheugenkaart onbruikbaar maken door tarmk.mode=32 in SegmentNodeStoreService.configtoe te voegen tot de werkend systeemkwestie wordt opgelost. De nadelen van het onbruikbaar maken maken maken I/O intensief. Zorg ervoor dat u de limiet voor I/O-paginamlot verhoogt.

Reinigere TarMK-revisie (verdichting)
Vanaf AEM 6.3 is de onlinecompressie (ook wel online revisie-opruiming genoemd) standaard ingeschakeld. Zie deze paginavoor meer informatie.

Cloud Manager for Adobe Managed Services (AMS)-gebruikers
Cloud Manager(de gebruikers van AMS slechts) staat u toe om succesvolle AEM plaatsing met geleide prestaties het testen en autoscaling te verzekeren.