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, moet u de volgende pagina's doorlopen voordat u de prestatierichtlijnen gaat lezen:
Hieronder ziet u de implementatieopties die beschikbaar zijn voor AEM (schuiven om alle opties weer te geven):
Wanneer moeten de prestatierichtlijnen worden gebruikt? when-to-use-the-performance-guidelines
In de volgende situaties moet u de prestatierichtlijnen gebruiken:
- Eerste implementatie: Wanneer u AEM Sites of Middelen voor het eerst wilt implementeren, is het belangrijk dat u weet welke opties beschikbaar zijn wanneer u de Micro Kernel, Node Store en Data Store configureert (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, is het belangrijk om de prestatiesverschillen te begrijpen vergeleken bij het gebruiken van MongoMK met drie of meer knopen van de Auteur. U kunt bijvoorbeeld MongoMK gebruiken in plaats van TarMK.
- Meer inhoud toevoegen: Als de aanbevolen gegevensopslagarchitectuur niet aan uw vereisten voldoet, is het belangrijk dat u weet welke prestatieverschillen er zijn ten opzichte van andere gegevensopslagopties. Voorbeeld: met de Amazon S3 of Microsoft Azure Data Store 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 Platform AEM the-aem-platform
Het AEM platform bestaat uit de volgende onderdelen:
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.
Micro Kernels 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 behoeften 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 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 data-store
Wanneer het behandelen van groot aantal binaire getallen, adviseert men dat een externe gegevensopslag in plaats van de standaardknoopopslag wordt gebruikt om prestaties te maximaliseren. Als uw project bijvoorbeeld een groot aantal media-elementen vereist, kunt u deze sneller openen dan ze rechtstreeks in een MongoDB opslaan als u ze onder de File of Azure/S3 Data Store opslaat.
Voor meer informatie over de beschikbare configuratieopties raadpleegt u Knooppunt en gegevensopslag configureren.
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.
Richtlijnen voor ontwikkeling development-guidelines
U moet zich ontwikkelen voor AEM gericht op prestaties en schaalbaarheid. Hieronder vindt u een aantal aanbevolen procedures die u kunt volgen:
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 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
-
Geen /libs-wijziging, maar gebruik overlays
-
Gebruik waar mogelijk geen query's
-
Gebruik geen Sling Bindings om de diensten OSGi in code van Java te krijgen, 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 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:
- Artikelpagina lezen (27,4%), Pagina lezen (10,9%), Sessie maken (2,6%), Pagina met inhoud activeren (1,7%), Pagina met inhoud maken (0,4%), Alinea maken (4,3%), Alinea bewerken (0,9%), Afbeeldingscomponent (0,9%), Bladeren-elementen (20%), Metagegevens van element lezen (8,5%), Downloadmiddel (4,2%), Zoekmiddel (0,2%), Asset-metagegevens bijwerken (2,4%), Element uploaden (1,2%), Bladeren project (4,9%), Project lezen (6,6%), Project toevoegen element (1,2%), Project toevoegen Site (1,2%), Project maken (0,1%), Auteur zoeken (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.
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 tarmk-minimum-architecture-guidelines
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 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 tarmk-performance-benchmark
Technische specificaties technical-specifications
De benchmarktests werden uitgevoerd op de volgende specificaties:
Resultaten van Bechmark-prestaties performance-bechmark-results
MongoMK mongomk
De primaire reden voor het kiezen van de MongoMK persistence backend over TarMK is de instanties horizontaal te schalen. Dit betekent dat er altijd twee of meer actieve auteur-instanties moeten worden uitgevoerd en dat MongoDB moet worden 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
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.
MongoMK Performance Benchmark mongomk-performance-benchmark
Technische specificaties technical-specifications-1
De benchmarktests werden uitgevoerd op de volgende specificaties:
Resultaten prestatie-benchmark performance-benchmark-results
TarMK vs MongoMK tarmk-vs-mongomk
De basisregel die in overweging moet worden genomen 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. Dit betekent dat er altijd twee of meer actieve auteur-instanties moeten worden uitgevoerd en dat MongoDB moet worden 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 (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 tarmk-vs-mongomk-benchmarks
Scenario 1 — Technische specificaties scenario-technical-specifications
Scenario 1 prestatie-benchmarkresultaten scenario-performance-benchmark-results
Scenario 2 — Technische specificaties scenario-technical-specifications-1
Scenario 2 prestatie-benchmarkresultaten scenario-performance-benchmark-results-1
Richtlijnen voor schaalbaarheid van architectuur voor AEM Sites en bedrijfsmiddelen architecture-scalability-guidelines-for-aem-sites-and-assets
Samenvatting van de prestatierichtlijnen summary-of-performance-guidelines
De richtsnoeren op deze pagina kunnen als volgt worden samengevat:
-
TarMK met bestandsdatastore is 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 is de geadviseerde architectuur voor horizontale scalability van het niveau van de 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 moet worden opgeslagen op de lokale schijf, niet op een NAS (Network Attached Storage)
-
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 op basis van de meeste gangbare zoekopdrachten
- Lucene-indexen moeten worden gebruikt voor aangepaste indexen
-
De prestaties kunnen aanzienlijk worden verbeterd door de workflow aan te passen bijvoorbeeld het verwijderen van de videostap in de workflow Element bijwerken, het uitschakelen van listeners die niet worden gebruikt, enzovoort.
Lees voor meer informatie ook de Aanbevolen implementaties pagina.