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):
Wanneer moeten de prestatierichtlijnen worden gebruikt? when-to-use-the-performance-guidelines
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 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:
Voor meer informatie over het AEM platform, zie wat AEMis.
De AEM architectuur the-aem-architecture
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.
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 extra informatie over Micro Kernels, zie de Geadviseerde pagina van Inzet.
Nodestore 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.
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.
Voor verdere details over de beschikbare configuratieopties, zie het Vormen Knoop en de Opslag van Gegevens.
Zoeken search-features
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.
Richtlijnen voor ontwikkeling development-guidelines
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 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 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 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 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 Publish-instanties
- Twee verzenders
Hieronder ziet u de architectuurrichtlijnen voor AEM sites en AEM Assets.
de Richtlijnen van de Architectuur van de Tar voor AEM Sites
de Richtlijnen van de Architectuur van de Tar voor AEM Assets
TarMK Settings Guideline 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 deze pagina.
TarMK Performance Benchmark tarmk-performance-benchmark
Technische specificaties technical-specifications
De benchmarktests werden uitgevoerd op de volgende specificaties:
Resultaten prestatie-benchmark performance-benchmark-results
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 {de Scenario's van de Plaatsing 1} 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 Publish-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 op hoe te om de montages te veranderen, 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-1
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 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 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 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 Assets 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 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.