Richtlijnen voor prestaties

Laatst bijgewerkt: 5 mei 2025

Van toepassing op:
Experience Manager 6.5

Onderwerpen:
Configureren

Gemaakt voor:

Beheerder

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	Edge	Doel
Assets	Publish-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			Chrome	Sociaal
Mobiel	Auteur-cluster	IBM® AIX®	JBoss®			RDB/MySQL	RDBMS			Safari	Publiek
Meerdere sites	ASRP	SUSE®				RDB/SQLServer					Assets
Commerce	MSRP	APPLE OS									Activering
Dynamic Media	JSRP										Mobiel
Brand Portal	J2E
AoD
LiveFyre
Screens
Documentbeveiliging
Procesbeheer
bureaubladtoepassing

OPMERKING

De prestatierichtsnoeren zijn voornamelijk van toepassing op AEM Sites.

Wanneer moeten de prestatierichtlijnen worden gebruikt?

Gebruik de prestatierichtlijnen in de volgende situaties:

Eerste plaatsing: Wanneer het van plan zijn om AEM Sites of Assets voor het eerst op te stellen, is het belangrijk om de beschikbare opties te begrijpen. 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.
Bevorderend aan een nieuwe versie: Wanneer het bevorderen aan een nieuwe versie, is het belangrijk om de prestatiesverschillen te begrijpen in vergelijking met het lopende milieu. Bijvoorbeeld, bevordering van AEM 6.1 aan 6.2, of van AEM 6.0 CRX2 aan 6.2 OAK.
de tijd van de Reactie is langzaam: 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.
Toevoegend meer auteurs: 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.
Toevoegend meer inhoud: Wanneer de geadviseerde architectuur van de Opslag van Gegevens niet aan uw vereisten voldoet, is het belangrijk om de prestatiesverschillen in vergelijking met andere opties van de Opslag van Gegevens te begrijpen. Voorbeeld: Amazon S3 of Microsoft® Azure Data Store gebruiken in plaats van een File Data Store.

Inleiding

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

Het AEM platform bestaat uit de volgende onderdelen:

chlimage_1

Voor meer informatie over het AEM platform, zie wat AEMis.

De AEM architectuur

Er zijn drie belangrijke bouwstenen aan een AEM plaatsing. De Instantie van de Auteur die door inhoudauteurs, redacteurs, en fiatteurs wordt gebruikt om inhoud tot stand te brengen en te herzien. Wanneer de inhoud wordt goedgekeurd, wordt het gepubliceerd aan een tweede instantietype genoemd de Instantie van Publish van waar het door het eind wordt betreden - gebruikers. De derde bouwsteen is Dispatcher die een module is die caching en URL het filtreren behandelt en op de webserver geïnstalleerd is. Voor extra informatie over de AEM architectuur, zie Typische Scenario's van de Plaatsing.

chlimage_1-1

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 extra informatie over Micro Kernels, zie de Geadviseerde pagina van Inzet.

chlimage_1-2

Nodestore

In AEM kunnen binaire gegevens onafhankelijk van inhoudsknooppunten worden opgeslagen. De plaats waar het binaire gegeven wordt opgeslagen wordt bedoeld als Opslag van Gegevens, terwijl de plaats van de inhoudsknopen en de eigenschappen wordt genoemd de Opslag van de Knoop.

OPMERKING

De Adobe raadt TarMK aan om de standaardpersistentietechnologie te zijn die door klanten voor zowel de AEM Auteur als de instanties van Publish wordt gebruikt.

LET OP

De relationele Database Micro Kernel wordt beperkt ondersteund. De Zorg van de Klant van de Adobe van het contact 🔗 alvorens dit type van Micro Kernel te gebruiken.

chlimage_1-3

Gegevensopslag

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.

Voor verdere details over de beschikbare configuratieopties, zie het Vormen Knoop en de Opslag van Gegevens.

OPMERKING

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 extra documentatie op 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 vereistenpagina.

Zoeken

In deze sectie worden de aangepaste indexproviders vermeld die met AEM worden gebruikt. Om meer over het indexeren te weten, zie Vragen van Oak en het Indexeren.

OPMERKING

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

Ontwikkel voor AEM het richten op prestaties en scalability. 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

Voor verdere details over het ontwikkelen op AEM, lees het Ontwikkelen - de Grondbeginselen. Voor extra beste praktijken, zie Beste praktijken van de Ontwikkeling.

Benchmark Scenarios

OPMERKING

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 de Technische Specificatieslijst.

Enig Scenario van het Product

AEM Assets:

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

de Scenario van de Producten van de mengeling

AEM Sites + Assets:

Gebruikersinteracties voor sites: Artikelpagina lezen / Pagina lezen / Alinea maken / Alinea bewerken / Pagina Inhoud maken / Pagina Inhoud activeren / Zoeken auteur
Assets-gebruikersinteracties: Bladeren door Assets / Zoeken in Assets / Asset downloaden / Metadata van element lezen / Metagegevens van element bijwerken / Element uploaden / Workflow voor uploaden van element uitvoeren
Uitvoermodus: gelijktijdige gebruikers, gemengde interacties per gebruiker

Verticaal 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

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 adviseert TarMK om de standaardpersistentietechnologie te zijn die door klanten in alle plaatsingsscenario's, voor zowel de AEM Auteur als de instanties van Publish wordt gebruikt.

Voor meer informatie over TarMK, zie {de Scenario's van de Plaatsing 1} en Opslag van de Tar.🔗

Richtlijnen voor minimale architectuur van TarMK

OPMERKING

De hieronder voorgestelde minimale architectuurrichtlijnen zijn voor productiemilieu's en hoge verkeersplaatsen. Deze richtlijnen zijn niet de minimumspecificatiesom AEM in werking te stellen.

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

Eén instantie Auteur
Twee Publish-instanties
Twee verzenders

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

OPMERKING

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

de Richtlijnen van de Architectuur van de Tar voor AEM Sites

chlimage_1-5

de Richtlijnen van de Architectuur van de Tar voor AEM Assets

chlimage_1-6

TarMK Settings Guideline

Voor goede prestaties, zou u de montages hieronder voorgestelde richtlijnen moeten volgen. Voor instructies op hoe te om de montages te veranderen, zie Optimalisering van Prestaties.

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	Voor meer details over de beschikbare parameters, zie deze pagina.
Data Store = S3 Datastore	`maxCachedBinarySize` `cacheSizeInMB`	1048576 (1 MB) of kleiner 2-10% van maximale heapgrootte	Zie ook Configuraties van de Opslag van Gegevens.
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

Technische specificaties

De benchmarktests werden uitgevoerd op de volgende specificaties:

	Knoop van de Auteur
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	Eén product: Assets / 30 gelijktijdige threads

Resultaten prestatie-benchmark

OPMERKING

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

chlimage_1-7 chlimage_1-8

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 {de Scenario's van de Plaatsing 1} en Mongo Opslag.🔗

Richtlijnen voor minimale architectuur van MongoMK

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

Drie instanties van Auteur
Twee Publish-instanties
Drie MongoDB-instanties
Twee verzenders

OPMERKING

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.

OPMERKING

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

chlimage_1-9

Richtlijnen voor MongoMK-instellingen

Voor goede prestaties, zou u de montages hieronder voorgestelde richtlijnen moeten volgen. Voor instructies op hoe te om de montages te veranderen, zie Optimalisering van Prestaties.

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	Voor meer details over beschikbare parameters, zie deze pagina.
Data Store = S3 Datastore	`maxCachedBinarySize` `cacheSizeInMB`	1048576 (1 MB) of kleiner 2-10% van maximale heapgrootte	Zie ook Configuraties van de Opslag van Gegevens.
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

Technische specificaties

De benchmarktests werden uitgevoerd op de volgende specificaties:

	de knoop van de Auteur	knoop MongoDB
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	Eén product: Assets / 30 gelijktijdige threads	Eén product: Assets / 30 gelijktijdige threads

Resultaten prestatie-benchmark

OPMERKING

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

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 adviseert TarMK om de standaardpersistentietechnologie te zijn die door klanten in alle plaatsingsscenario's, voor zowel de AEM Auteur als de instanties van Publish 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 verdere details op TarMK vs MongoMK, zie Geadviseerde Plaatsingen.

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 Reservevoor meer details
Biedt hoge prestaties en betrouwbare gegevensopslag met minimale operationele overhead
Lagere totale eigendomskosten

Criteria om MongoMK te kiezen

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

OPMERKING

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

Scenario 1 — Technische specificaties

	Oak-knooppunt voor auteur	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	Eén product: Assets / 30 gelijktijdige threads per run

Scenario 1 prestatie-benchmarkresultaten

chlimage_1-12

Scenario 2 — Technische specificaties

OPMERKING

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

chlimage_1-13

Richtlijnen voor schaalbaarheid van architectuur voor AEM Sites en Assets

chlimage_1-14

Samenvatting van de prestatierichtlijnen

De richtsnoeren op deze pagina kunnen als volgt worden samengevat:

TarMK met de Datastore van het Dossier - de geadviseerde architectuur voor de meeste klanten:
- Minimale topologie: één instantie van de Auteur, twee instanties van Publish, twee Verzenders
- Binair-less replicatie aangezet als de Datastore van het Dossier wordt gedeeld
MongoMK met de Datastore van het Dossier - de geadviseerde architectuur voor horizontale scalability van de rij van de Auteur:
- Minimale topologie: drie instanties van de Auteur, drie instanties MongoDB, twee instanties van Publish, twee Verzenders
- Binair-less replicatie aangezet als de Datastore van het Dossier wordt gedeeld
Nodestore - opgeslagen op de lokale schijf, niet een netwerk in bijlage opslag (NAS)
Wanneer het gebruiken van Amazon S3:
- De Amazon S3-datastore wordt gedeeld door de Auteur en de Publish-laag
- Binair-less replicatie moet worden aangezet
- Voor de afvalophaling van Datastore is een eerste uitvoering vereist voor alle Auteur- en Publish-knooppunten en een tweede uitvoering voor Auteur
de index van de Douane zou naast uit de doos index - moeten worden gecreeerd die op de meeste gemeenschappelijke onderzoeken wordt gebaseerd
- Lucene-indexen moeten worden gebruikt voor aangepaste indexen
het Aanpassen van werkschema kan de prestaties wezenlijk verbeteren - verwijder de videostap in het werkschema "van de Activa van de Update", die luisteraars onbruikbaar maken die niet worden gebruikt, etc.

Voor meer details, lees ook de Geadviseerde pagina van Inzet.

recommendation-more-help