Richtlijnen voor prestaties

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:

• Basisconcepten AEM
• Overzicht van opslag in AEM
• Aanbevolen implementaties
• Technische vereisten

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

Wanneer moeten de prestatierichtlijnen worden gebruikt?

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). Bijvoorbeeld, veranderend de standaardmontages van het Opslag van Gegevens voor TarMK in de Opslag van de Gegevens van het Dossier.
• 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: met de Amazon S3 of Microsoft® Azure Data Store 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 Platform AEM

Het AEM platform bestaat uit de volgende onderdelen:

Ga voor meer informatie over het AEM Wat is AEM.

De AEM architectuur

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.

Micro Kernels

Micro Kernels fungeert als persistentiemanagers in AEM. Er worden drie soorten Micro Kernels gebruikt met AEM: 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.

Nodestore

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

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 meer informatie over de beschikbare configuratieopties raadpleegt u Knooppunt en gegevensopslag configureren.

Zoeken

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

Richtlijnen voor ontwikkeling

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

DO

• Scheiding van presentatie, logica en inhoud toepassen
• Bestaande AEM-API's gebruiken (bijvoorbeeld: Sling) en gereedschap (bv. Replicatie)
• Ontwikkelen in de context van werkelijke inhoud
• Ontwikkelen voor optimale kakkerbaarheid
• Aantal spaarbestanden minimaliseren (bijv.: door gebruik te maken van tijdelijke workflows)
• 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 geen /libs, 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 meer tips en trucs Aanbevolen werkwijzen voor ontwikkeling.

Benchmark Scenarios

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: Blader middelen / zoekmiddelen / element 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 plaatsen/Zoeken in auteur activeren
• Gebruikersinteracties voor middelen: Blader middelen / zoekmiddelen / element downloaden / Metagegevens van element lezen / Metagegevens van element bijwerken / element uploaden / workflow voor uploaden van element uitvoeren
• 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

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

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

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

Richtlijnen voor minimale architectuur van TarMK

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.

Richtlijnen voor de Tar Architecture voor AEM Sites

Richtlijnen voor de Tar Architecture voor AEM Assets

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.

TarMK Performance Benchmark

Technische specificaties

De benchmarktests werden uitgevoerd op de volgende specificaties:

Resultaten prestatie-benchmark

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

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

Richtlijnen voor MongoMK-instellingen

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

MongoMK Performance Benchmark

Technische specificaties

De benchmarktests werden uitgevoerd op de volgende specificaties:

Resultaten prestatie-benchmark

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. Adobe raadt TarMK aan om de standaardpersistentietechnologie te zijn die door klanten in alle plaatsingsscenario's, voor zowel auteur AEM 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

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 (totale eigendomskosten)

Criteria voor de keuze van MongoMK

• Aantal benoemde gebruikers verbonden in een dag: in 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
• Volume zoekopdrachten per dag: in tienduizenden of meer

TarMK vs MongoMK Benchmarks

Scenario 1 — Technische specificaties

Scenario 1 prestatie-benchmarkresultaten

Scenario 2 — Technische specificaties

Scenario 2 prestatie-benchmarkresultaten

Richtlijnen voor schaalbaarheid van architectuur voor AEM Sites en bedrijfsmiddelen

Samenvatting van de prestatierichtlijnen

De richtsnoeren op deze pagina kunnen als volgt worden samengevat:

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

  • Minimale topologie: één instantie Auteur, twee instanties Publish, 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.

Business.Adobe.com-bronnen

Multichannel Communication Auto Text Summarization Personalized Experiences Mobile Forms Dynamic Media Headless Cms