Richtlijnen voor prestaties performance-guidelines

Deze pagina biedt algemene richtlijnen voor het optimaliseren van de prestaties van uw AEM-implementatie. Als u nog niet eerder hebt AEM, bekijkt u eerst de volgende pagina's voordat u de prestatierichtlijnen gaat lezen:

Hieronder ziet u de implementatieopties die beschikbaar zijn voor AEM (schuiven om alle opties weer te geven):

AEM

Product

Topologie
Besturingssysteem
Toepassingsserver
JRE
Beveiliging
Micro Kernel
Datastore
Indexeren
Webserver
Browser
Experience Cloud
Sites
Niet-HA
Windows
CQSE
Oracle
LDAP
Tar
Segment
Eigenschap
Apache
Rand
Doel
Assets
Publiceren-HA
Solaris™
WebLogic
IBM®
SAML
MongoDB
Bestand
Lucene
IIS
IE
Analyse
Gemeenschappen
Auteur-CS
Rode hoed®
WebSphere®
HP
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
FireFox
Campagne
Forms
Auteur-offload
HP-UX
Tomcat
RDB/DB2
MongoDB
Chroom
Sociaal
Mobiel
Auteur-cluster
IBM® AIX®
JBoss®
RDB/MySQL
RDBMS
Safari
Publiek
Meerdere sites
ASRP
SUSE®
RDB/SQLServer
Assets
Handel
MSRP
APPLE OS
Activering
Dynamic Media
JSRP
Mobiel
Brand Portal
J2E
AoD
LiveFyre
Schermen
Documentbeveiliging
Procesbeheer
bureaubladtoepassing
NOTE
De prestatierichtsnoeren zijn voornamelijk van toepassing op AEM Sites.

Wanneer moeten de prestatierichtlijnen worden gebruikt? when-to-use-the-performance-guidelines

Gebruik de prestatierichtlijnen in de volgende situaties:

  • Eerste implementatie: Wanneer u AEM Sites of Middelen voor het eerst wilt implementeren, is het belangrijk dat u de beschikbare opties begrijpt. Vooral bij het configureren van de Micro Kernel, Node Store en Data Store (in vergelijking met de standaardinstellingen). Zo wijzigt u de standaardinstellingen van de gegevensopslag voor TarMK in de gegevensopslag van het bestand.
  • Bijwerken naar een nieuwe versie: Wanneer u een upgrade uitvoert naar een nieuwe versie, is het belangrijk dat u de verschillen in prestaties begrijpt ten opzichte van de actieve omgeving. Bijvoorbeeld, bevordering van AEM 6.1 aan 6.2, of van AEM 6.0 CRX2 aan 6.2 OAK.
  • Responstijd is traag: Wanneer de geselecteerde architectuur van Nodestore niet aan uw vereisten voldoet, is het belangrijk om de prestatiesverschillen te begrijpen vergeleken met andere topologieopties. U kunt bijvoorbeeld TarMK gebruiken in plaats van MongoMK, of een File Data Sore gebruiken in plaats van een Amazon S3 of Microsoft® Azure Data Store.
  • Meer auteurs toevoegen: Wanneer de geadviseerde topologie TarMK niet aan de prestatiesvereisten voldoet en het upsizing van de knoop van de Auteur de maximumbeschikbare capaciteit heeft bereikt, begrijp de prestatiesverschillen. Ben met het gebruiken van MongoMK met drie of meer knopen van de Auteur vergelijkbaar. U kunt bijvoorbeeld MongoMK gebruiken in plaats van TarMK.
  • Meer inhoud toevoegen: Wanneer de aanbevolen gegevensopslagarchitectuur niet aan uw vereisten voldoet, is het belangrijk dat u de prestatieverschillen begrijpt ten opzichte van andere opties voor gegevensopslag. Voorbeeld: Amazon S3 of Microsoft® Azure Data Store gebruiken in plaats van een File Data Store.

Inleiding introduction

In dit hoofdstuk wordt een algemeen overzicht gegeven van de AEM architectuur en de belangrijkste onderdelen ervan. Zij bevat ook ontwikkelingsrichtsnoeren en beschrijft de testscenario's die in de TarMK- en MongoMK-benchmarktests worden gebruikt.

Het AEM the-aem-platform

Het AEM platform bestaat uit de volgende onderdelen:

chlimage_1

Ga voor meer informatie over het AEM Wat is AEM.

De AEM architectuur the-aem-architecture

Er zijn drie belangrijke bouwstenen aan een AEM plaatsing. De Instantie van auteur wordt gebruikt door auteurs van inhoud, editors en fiatteurs om inhoud te maken en te reviseren. Wanneer de inhoud is goedgekeurd, wordt deze gepubliceerd naar een tweede instantietype met de naam Exemplaar publiceren vanaf waar de eindgebruiker toegang tot het apparaat heeft. De derde bouwsteen is de Dispatcher Dit is een module die het in cache plaatsen en URL filtreren behandelt en op de webserver geïnstalleerd is. Voor meer informatie over de AEM architectuur raadpleegt u Typische implementatiescenario's.

chlimage_1-1

Micro Kernels micro-kernels

Micro Kernels fungeert als persistentiemanagers in AEM. Er zijn drie soorten Micro Kernels die met AEM worden gebruikt: TarMK, MongoDB, en Relationele Gegevensbestand (onder beperkte steun). Het kiezen van één om uw behoefte te passen hangt van het doel van uw instantie en het plaatsingstype af u overweegt. Voor meer informatie over Micro Kernels raadpleegt u de Aanbevolen implementaties pagina.

chlimage_1-2

Nodestore nodestore

In AEM kunnen binaire gegevens onafhankelijk van inhoudsknooppunten worden opgeslagen. De locatie waar de binaire gegevens worden opgeslagen, wordt aangeduid als de Gegevensopslag, terwijl de locatie van de inhoudknooppunten en -eigenschappen de Node Store.

NOTE
De Adobe raadt TarMK aan om de standaardpersistentietechnologie te zijn die door klanten voor zowel de AEM Auteur als de Publish instanties wordt gebruikt.
CAUTION
De relationele Database Micro Kernel wordt beperkt ondersteund. Contact Klantenservice Adoben voordat u dit type Micro Kernel gebruikt.

chlimage_1-3

Gegevensopslag data-store

Wanneer het behandelen van groot aantal binaire getallen, adviseert men dat u een externe gegevensopslag in plaats van de standaardknoopopslag gebruikt om prestaties te maximaliseren. Als uw project bijvoorbeeld veel media-elementen vereist, kunt u deze sneller openen dan ze rechtstreeks in een MongoDB opslaan als de File of Azure/S3 Data Store.

Zie voor meer informatie over de beschikbare configuratieopties Knooppunt en gegevensopslag configureren.

NOTE
Adobe raadt u aan de optie te kiezen om AEM in Azure of Amazon Web Services (AWS) te implementeren met behulp van Adobe Managed Services. Klanten profiteren van een team dat de ervaring en vaardigheden heeft om AEM in deze cloud computing-omgevingen te implementeren en te gebruiken. Zie aanvullende documentatie over Adobe Managed Services.
Voor aanbevelingen voor de implementatie van AEM in Azure of AWS, buiten Adobe Managed Services, raadt Adobe aan rechtstreeks met de cloud provider te werken. Of werk met een van de partners van de Adobe die de implementatie van AEM in de cloud-omgeving van uw keuze ondersteunen. De geselecteerde wolkenleverancier of partner is verantwoordelijk voor de rangschikkingsspecificaties, het ontwerp, en de implementatie van de architectuur zij steunen om aan uw specifieke prestaties, lading, scalability, en veiligheidseisen te voldoen.
​>Zie ook de technische voorschriften pagina.

Zoeken search-features

In deze sectie worden de aangepaste indexproviders vermeld die met AEM worden gebruikt. Zie voor meer informatie over indexering Oak-query's en indexering.

NOTE
Voor de meeste plaatsingen, adviseert de Adobe het gebruiken van de Index van Lucene. Gebruik Solr alleen voor schaalbaarheid in gespecialiseerde en complexe implementaties.

chlimage_1-4

Richtlijnen voor ontwikkeling development-guidelines

Ontwikkelen voor AEM gericht op prestaties en schaalbaarheid. Hier volgt een overzicht van aanbevolen procedures:

DOEN

  • Scheiding van presentatie, logica en inhoud toepassen
  • Bestaande AEM-API's (bijvoorbeeld Verdelen) en gereedschappen (bijvoorbeeld Replicatie) gebruiken
  • Ontwikkelen in de context van werkelijke inhoud
  • Ontwikkelen voor optimale kakkerbaarheid
  • Minimaliseer het aantal spaarbestanden (bijv. door tijdelijke workflows te gebruiken)
  • Zorg ervoor dat alle eindpunten van HTTP RESTful zijn
  • Het bereik van de GCR-waarneming beperken
  • Onthoud asynchrone thread

NIET

  • Gebruik niet direct JCR-API's, als dat mogelijk is

  • Wijzig /libs niet, maar gebruik overlays

  • Gebruik waar mogelijk geen query's

  • Gebruik geen Sling Bindings om de diensten OSGi in code te krijgen Java™, maar eerder gebruik:

    • @Reference in een DS-component
    • @Injecteren in een verkoopmodel
    • sling.getService() in een klasse voor rechtmatig gebruik
    • sling.getService() in een JSP
    • een ServiceTracker
    • directe toegang tot het OSGi-serviceregister

Lees voor meer informatie over het ontwikkelen op AEM Ontwikkelen - De basisbeginselen. Zie voor aanvullende aanbevolen procedures Aanbevolen werkwijzen voor ontwikkeling.

Benchmark Scenarios benchmark-scenarios

NOTE
Alle benchmarktests die op deze pagina worden weergegeven, zijn uitgevoerd in een laboratoriumomgeving.

De hieronder beschreven testscenario's worden gebruikt voor de benchmarksecties van de hoofdstukken TarMK, MongoMk en TarMK vs MongoMk. Om te zien welk scenario voor een bepaalde benchmarktest werd gebruikt, lees het gebied van het Scenario van Technische specificaties tabel.

Scenario één product

AEM Assets:

  • Gebruikersinteracties: Zoeken in middelen / Zoeken in middelen / Elementen downloaden / Metagegevens van element lezen / Metagegevens van element bijwerken / Element uploaden / Workflow voor uploaden van element uitvoeren
  • Uitvoermodus: gelijktijdige gebruikers, enkele interactie per gebruiker

Productscenario mixen

AEM Sites + Middelen:

  • Gebruikersinteracties voor sites: Artikelpagina lezen / Pagina lezen / Alinea maken / Alinea bewerken / Pagina Inhoud maken / Pagina Inhoud activeren / Zoeken auteur
  • Interacties van gebruikers van middelen: Browse Assets / Search Assets / Download Asset / Read Asset Metadata / Update Asset Metadata / Upload Asset / Run Upload Asset Workflow
  • Uitvoermodus: gelijktijdige gebruikers, gemengde interacties per gebruiker

Het verticale Scenario van het Geval van het Gebruik

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%)
  • Uitvoermodus: gelijktijdige gebruikers, gemengde interacties per gebruiker

TarMK tarmk

Dit hoofdstuk geeft algemene prestatiesrichtlijnen voor TarMK die de minimumarchitectuurvereisten en de montageconfiguratie specificeren. Er wordt ook voorzien in benchmarktests voor verdere verduidelijking.

De Adobe raadt TarMK aan om de standaardpersistentietechnologie te zijn die door klanten in alle plaatsingsscenario's, voor zowel de AEM Auteur als Publish instanties wordt gebruikt.

Voor meer informatie over TarMK, zie Implementatiescenario's en Teeropslag.

Richtlijnen voor minimale architectuur van TarMK tarmk-minimum-architecture-guidelines

NOTE
De hieronder voorgestelde minimale architectuurrichtlijnen zijn voor productiemilieu's en hoge verkeersplaatsen. Deze richtsnoeren zijn niet de minimumspecificaties om AEM uit te voeren.

Om goede prestaties te vestigen wanneer het gebruiken van TarMK, zou u van de volgende architectuur moeten beginnen:

  • Eén instantie Auteur
  • Twee publicatie-instanties
  • Twee verzenders

Hieronder ziet u de architectuurrichtlijnen voor AEM sites en AEM Assets.

NOTE
Binair-less replicatie zou moeten worden gedraaid ON als de datastore van het Dossier wordt gedeeld.

Richtlijnen voor de Tar Architecture voor AEM Sites

chlimage_1-5

Richtlijnen voor de Tar Architecture voor AEM Assets

chlimage_1-6

TarMK Settings Guideline tarmk-settings-guideline

Voor goede prestaties, zou u de montages hieronder voorgestelde richtlijnen moeten volgen. Voor instructies over het wijzigen van de instellingen, zie deze pagina.

Instelling
Parameter
Waarde
Beschrijving
Taakwachtrijen voor verkopen
queue.maxparallel
Stel waarde in op de helft van het aantal CPU-cores.
Standaard is het aantal gelijktijdige threads per taakwachtrij gelijk aan het aantal CPU-cores.
Graniet Transient Workflow Queue
Max Parallel
Stel waarde in op de helft van het aantal CPU-cores
JVM-parameters

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

Waar

Om expansieve vragen te verhinderen de systemen te overbelasten, voeg deze parameters JVM in het AEM beginmanuscript toe.
Lucene-indexconfiguratie

CopyOnRead

CopyOnWrite

Prefetch Index Files

Ingeschakeld

Ingeschakeld

Ingeschakeld

Zie voor meer informatie over de beschikbare parameters deze pagina.
Data Store = S3 Datastore

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) of kleiner

2-10% van maximale heapgrootte

Zie ook Configuraties van gegevensopslag.
Workflow voor DAM-update-middelen
Transient Workflow
ingeschakeld
Deze workflow beheert de update van elementen.
DAM MetaData Writeback
Transient Workflow
ingeschakeld
Deze workflow beheert XMP terugschrijven naar het oorspronkelijke binaire getal en stelt de datum van laatste wijziging in JCR in.

TarMK Performance Benchmark tarmk-performance-benchmark

Technische specificaties technical-specifications

De benchmarktests werden uitgevoerd op de volgende specificaties:

Auteursknooppunt
Server
Hardware voor onbewerkte metalen (HP)
Besturingssysteem
Red Hat® Linux®
CPU/kernen
Intel® Xeon® CPU E5-2407 @2,40 GHz, 8 kernen
RAM
32 GB
Schijf
Magnetisch
Java™
Oracle JRE versie 8
JVM Heap
16 GB
Product
AEM 6,2
Nodestore
TarMK
Datastore
Bestand DS
Scenario
Enkel product: elementen / 30 gelijktijdige threads

Resultaten prestatie-benchmark performance-benchmark-results

NOTE
De hieronder vermelde aantallen zijn genormaliseerd aan 1 als basislijn en zijn niet de daadwerkelijke productienummers.

chlimage_1-7 chlimage_1-8

MongoMK mongomk

De primaire reden voor het kiezen van de MongoMK persistence backend over TarMK is de instanties horizontaal te schalen. Deze mogelijkheid houdt in dat twee of meer actieve auteur-instanties altijd worden uitgevoerd en dat MongoDB wordt gebruikt als het opslagsysteem voor persistentie. De noodzaak om meer dan één auteurinstantie in werking te stellen vloeit over het algemeen voort uit het feit dat de cpu en geheugencapaciteit van één enkele server, die alle gezamenlijke auteursactiviteiten steunt, niet meer duurzaam is.

Voor meer informatie over TarMK, zie Implementatiescenario's en Mongo-opslag.

Richtlijnen voor minimale architectuur van MongoMK mongomk-minimum-architecture-guidelines

Om goede prestaties te vestigen wanneer het gebruiken van MongoMK, zou u van de volgende architectuur moeten beginnen:

  • Drie instanties van Auteur
  • Twee publicatie-instanties
  • Drie MongoDB-instanties
  • Twee verzenders
NOTE
In productieomgevingen wordt MongoDB altijd gebruikt als een replicaset met een primaire en twee secundaire server. Lezen en schrijven gaan naar de primaire website en lezen kan naar de secundaire medewerkers gaan. Als opslag niet beschikbaar is, kan een van de secundaire bestanden worden vervangen door een arbiter, maar MongoDB-replicasets moeten altijd uit een oneven aantal instanties bestaan.
NOTE
Binair-less replicatie zou moeten worden gedraaid ON als de datastore van het Dossier wordt gedeeld.

chlimage_1-9

Richtlijnen voor MongoMK-instellingen mongomk-settings-guidelines

Voor goede prestaties, zou u de montages hieronder voorgestelde richtlijnen moeten volgen. Voor instructies over het wijzigen van de instellingen, zie deze pagina.

Instelling
Parameter
Waarde (standaardwaarde)
Beschrijving
Taakwachtrijen voor verkopen
queue.maxparallel
Stel waarde in op de helft van het aantal CPU-cores.
Standaard is het aantal gelijktijdige threads per taakwachtrij gelijk aan het aantal CPU-cores.
Graniet Transient Workflow Queue
Max Parallel
Stel waarde in op de helft van het aantal CPU-cores.
JVM-parameters

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

Waar

60000

Om expansieve vragen te verhinderen de systemen te overbelasten, voeg deze parameters JVM in het AEM beginmanuscript toe.
Lucene-indexconfiguratie

CopyOnRead

CopyOnWrite

Prefetch Index Files

Ingeschakeld

Ingeschakeld

Ingeschakeld

Zie voor meer informatie over de beschikbare parameters deze pagina.
Data Store = S3 Datastore

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) of kleiner

2-10% van maximale heapgrootte

Zie ook Configuraties van gegevensopslag.
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

(25)

20

30 (5)

10

4

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

De standaardgrootte van de cache is ingesteld op 256 MB.

Heeft invloed op de tijd die nodig is om cachevalidatie uit te voeren.

eik-waarneming

thread pool

length

min & max = 20

50000

MongoMK Performance Benchmark mongomk-performance-benchmark

Technische specificaties technical-specifications-1

De benchmarktests werden uitgevoerd op de volgende specificaties:

Auteur-knooppunt
MongoDB-knooppunt
Server
Hardware voor onbewerkte metalen (HP)
Hardware voor onbewerkte metalen (HP)
Besturingssysteem
Red Hat® Linux®
Red Hat® Linux®
CPU/kernen
Intel® Xeon® CPU E5-2407 @2,40 GHz, 8 kernen
Intel® Xeon® CPU E5-2407 @2,40 GHz, 8 kernen
RAM
32 GB
32 GB
Schijf
Magnetisch - >1k IOPS
Magnetisch - >1k IOPS
Java™
Oracle JRE versie 8
NVT
JVM Heap
16 GB
NVT
Product
AEM 6,2
MongoDB 3.2 WiredTiger
Nodestore
MongoMK
NVT
Datastore
Bestand DS
NVT
Scenario
Enkel product: elementen / 30 gelijktijdige threads
Enkel product: elementen / 30 gelijktijdige threads

Resultaten prestatie-benchmark performance-benchmark-results-1

NOTE
De hieronder vermelde aantallen zijn genormaliseerd aan 1 als basislijn en zijn niet de daadwerkelijke productienummers.

chlimage_1-10 chlimage_1-11

TarMK vs MongoMK tarmk-vs-mongomk

De basisregel om voor rekening te brengen wanneer het kiezen tussen twee is dat TarMK voor prestaties wordt ontworpen, terwijl MongoMK voor scalability wordt gebruikt. De Adobe raadt TarMK aan om de standaardpersistentietechnologie te zijn die door klanten in alle plaatsingsscenario's, voor zowel de AEM Auteur als Publish instanties wordt gebruikt.

De primaire reden voor het kiezen van de MongoMK persistence backend over TarMK is de instanties horizontaal te schalen. Deze functionaliteit houdt in dat twee of meer actieve auteur-instanties altijd worden uitgevoerd en dat MongoDB wordt gebruikt als het opslagsysteem voor persistentie. De noodzaak om meer dan één auteurinstantie in werking te stellen vloeit over het algemeen voort uit het feit dat de cpu en geheugencapaciteit van één enkele server, die alle gezamenlijke auteursactiviteiten steunt, niet meer duurzaam is.

Voor meer informatie over TarMK vs MongoMK, zie Aanbevolen implementaties.

TarMK vs MongoMk Guidelines tarmk-vs-mongomk-guidelines

Voordelen van TarMK

  • Speciaal ontworpen voor toepassingen voor inhoudsbeheer
  • Bestanden zijn altijd consistent en er kunnen back-ups van worden gemaakt met elk bestandsgebaseerd back-upprogramma
  • Verstrekt een failovermechanisme - zie Koude stand-by voor meer informatie
  • Biedt hoge prestaties en betrouwbare gegevensopslag met minimale operationele overhead
  • Lagere totale eigendomskosten

Criteria voor de keuze van MongoMK

  • Aantal benoemde gebruikers verbonden op een dag: in de duizenden of meer
  • Aantal gelijktijdige gebruikers: in honderden of meer
  • Omvang van de ingenomen activa per dag: in honderdduizenden of meer
  • Volume van paginabewerkingen per dag: in honderdduizenden of meer
  • Aantal zoekopdrachten per dag: in tienduizenden of meer

TarMK vs MongoMK Benchmarks tarmk-vs-mongomk-benchmarks

NOTE
De hieronder vermelde aantallen zijn genormaliseerd aan 1 als basislijn en zijn geen daadwerkelijke productienummers.

Scenario 1 — Technische specificaties scenario-technical-specifications

Auteur-OAK-knooppunt
MongoDB-knooppunt
Server
Hardware voor onbewerkte metalen (HP)
Hardware voor onbewerkte metalen (HP)
Besturingssysteem
Red Hat® Linux®
Red Hat® Linux®
CPU/kernen
Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 kernen
Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 kernen
RAM
32 GB
32 GB
Schijf
Magnetisch - >1k IOPS
Magnetisch - >1k IOPS
Java™
Oracle JRE versie 8
NVT
JVM Heap16 GB
16 GB
NVT
Product
AEM 6,2
MongoDB 3.2 WiredTiger
Nodestore
TarMK of MongoMK
NVT
Datastore
Bestand DS
NVT
Scenario
Enkel product: middelen / 30 gelijktijdige threads per run

Scenario 1 prestatie-benchmarkresultaten scenario-performance-benchmark-results

chlimage_1-12

Scenario 2 — Technische specificaties scenario-technical-specifications-1

NOTE
Als u hetzelfde aantal auteurs met MongoDB wilt inschakelen als met één TarMK-systeem, hebt u een cluster met twee AEM knooppunten nodig. Een cluster met vier knooppunten in MongoDB kan 1,8 keer het aantal auteurs afhandelen dan één TarMK-instantie. Een achtnodencluster MongoDB kan 2.3 keer het aantal Auteurs behandelen dan één instantie TarMK.
Auteur TarMK-knooppunt
Auteur MongoMK Node
MongoDB-knooppunt
Server
AWS c3.8xlarge
AWS c3.8xlarge
AWS c3.8xlarge
Besturingssysteem
Red Hat® Linux®
Red Hat® Linux®
Red Hat® Linux®
CPU/kernen
32
32
32
RAM
60 GB
60 GB
60 GB
Schijf
SSD - 10.000 IOPS
SSD - 10.000 IOPS
SSD - 10.000 IOPS
Java™
Oracle JRE versie 8
Oracle JRE versie 8
NVT
JVM Heap16 GB
30 GB
30 GB
NVT
Product
AEM 6,2
AEM 6,2
MongoDB 3.2 WiredTiger
Nodestore
TarMK
MongoMK
NVT
Datastore
Bestand DS
Bestand DS
NVT
Scenario
Verticaal gebruik: Media / 2000 gelijktijdige threads

Scenario 2 prestatie-benchmarkresultaten scenario-performance-benchmark-results-1

chlimage_1-13

Richtlijnen voor schaalbaarheid van architectuur voor AEM Sites en bedrijfsmiddelen architecture-scalability-guidelines-for-aem-sites-and-assets

chlimage_1-14

Samenvatting van de prestatierichtlijnen summary-of-performance-guidelines

De richtsnoeren op deze pagina kunnen als volgt worden samengevat:

  • TarMK met bestandsdatastore - De aanbevolen architectuur voor de meeste klanten:

    • Minimale topologie: één instantie van de Auteur, twee Publish instanties, twee Verzenders
    • Binair-less replicatie aangezet als de Datastore van het Dossier wordt gedeeld
  • MongoMK met bestandsdatastore - De aanbevolen architectuur voor horizontale schaalbaarheid van het niveau Auteur:

    • Minimale topologie: drie instanties Auteur, drie instanties MongoDB, twee instanties Publish, twee Verzenders
    • Binair-less replicatie aangezet als de Datastore van het Dossier wordt gedeeld
  • Nodestore - Opgeslagen op de lokale schijf, niet een netwerk aangesloten opslag (NAS)

  • Wanneer u Amazon S3:

    • De Amazon S3-datastore wordt gedeeld tussen de laag Auteur en Publiceren
    • Binair-less replicatie moet worden aangezet
    • Voor de afvalophaling van Datastore is een eerste uitvoering vereist voor alle auteur- en publicatieknooppunten en vervolgens een tweede uitvoering voor Auteur
  • De aangepaste index moet worden gemaakt naast de index voor het uiteinde van het vak - Gebaseerd op de meeste gangbare zoekopdrachten

    • Lucene-indexen moeten worden gebruikt voor aangepaste indexen
  • De prestaties kunnen aanzienlijk worden verbeterd door de workflow aan te passen - Verwijder de videostap in de workflow Element bijwerken, schakel listeners uit die niet worden gebruikt, enzovoort.

Lees voor meer informatie ook de Aanbevolen implementaties pagina.

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