Show Menu
ARGOMENTI×

Linee guida sulle prestazioni

Questa pagina contiene linee guida generali su come ottimizzare le prestazioni della distribuzione AEM. Se non avete mai usato AEM, passate le pagine seguenti prima di iniziare a leggere le linee guida sulle prestazioni:
Di seguito sono illustrate le opzioni di distribuzione disponibili per AEM (scorrete per visualizzare tutte le opzioni):
AEM
Prodotto
Topologia
Sistema operativo
Application Server
JRE
Sicurezza
Micro Kernel
Datastore
Indicizzazione
Server web
Browser
Marketing Cloud
Sites
Non HA
Windows
CQSE
Oracle
LDAP
Tar
Segmento
Proprietà
Apache
Edge
Destinazione
Assets
Publish-HA
Solaris
WebLogic
IBM
SAML
MongoDB
File
Lucene
IIS
IE
Analisi
Communities
Author-CS
Cappello rosso
WebSphere
HP
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
FireFox
Campaign
Forms
Author-Offload
HP-UX
Tomcat
RDB/DB2
MongoDB
Effetto cromatura
Social network
Mobile
Author-Cluster
IBM AIX
JBoss
RDB/MySQL
RDBMS
Safari
Pubblico
Più siti
ASRP
SUSE
RDB/SQLServer
Assets
Commerce
MSRP
Apple OS
Attivazione
Dynamic Media
JSRP
Mobile
Brand Portal
J2E
AoD
LiveFyre
Screens
Doc Security
Mgt di processo
app desktop
Le linee guida sulle prestazioni sono valide soprattutto per AEM Sites.

Quando utilizzare le linee guida sulle prestazioni

Le linee guida sulle prestazioni devono essere utilizzate nelle situazioni seguenti:
  • Prima distribuzione : Quando pianifichi la prima implementazione di AEM Sites o Assets, è importante comprendere le opzioni disponibili per la configurazione del kernel Micro, dell'archivio nodi e dell'archivio dati (rispetto alle impostazioni predefinite). Ad esempio, modifica delle impostazioni predefinite di Data Store per TarMK in File Data Store.
  • Aggiornamento a una nuova versione : Durante l'aggiornamento a una nuova versione, è importante comprendere le differenze di prestazioni rispetto all'ambiente in esecuzione. Ad esempio, l’aggiornamento da AEM 6.1 a 6.2 o da AEM 6.0 CRX2 a 6.2 OAK.
  • Il tempo di risposta è lento : Se l'architettura del Nodestore selezionata non soddisfa i requisiti dell'utente, è importante comprendere le differenze di prestazioni rispetto ad altre opzioni di topologia. Ad esempio, è possibile distribuire TarMK invece di MongoMK oppure utilizzare un archivio dati file invece di un archivio dati Amazon S3 o Microsoft Azure.
  • Aggiunta di altri autori : Quando la topologia TarMK consigliata non soddisfa i requisiti di prestazioni e il ridimensionamento del nodo Author ha raggiunto la capacità massima disponibile, è importante comprendere le differenze di prestazioni rispetto all'utilizzo di MongoMK con tre o più nodi Author. Ad esempio, distribuzione di MongoMK invece di TarMK.
  • Aggiunta di altro contenuto : Se l'architettura dell'archivio dati consigliata non soddisfa i requisiti dell'utente, è importante comprendere le differenze di prestazioni rispetto alle altre opzioni dell'archivio dati. Esempio: utilizzo di Amazon S3 o Microsoft Azure Data Store invece di un archivio dati file.

Introduzione

Questo capitolo offre una panoramica generale dell’architettura di AEM e dei suoi componenti più importanti. Fornisce inoltre linee guida di sviluppo e descrive gli scenari di test utilizzati nei test di benchmark TarMK e MongoMK.

La piattaforma AEM

La piattaforma AEM è composta dai seguenti componenti:
Per ulteriori informazioni sulla piattaforma AEM, consulta Cos’è AEM .

Architettura AEM

Esistono tre importanti elementi di base per una distribuzione AEM. Istanza di autore utilizzata da autori, editor e approvatori di contenuti per creare e rivedere i contenuti. Quando il contenuto viene approvato, viene pubblicato in un secondo tipo di istanza denominato Istanza di pubblicazione da cui gli utenti finali accedono. Il terzo blocco predefinito è il Dispatcher , un modulo che gestisce il caching e il filtraggio degli URL e che viene installato sul server Web. Per ulteriori informazioni sull’architettura di AEM, consultate Scenari di distribuzione tipici.

Micro Kernel

I microkernel agiscono come persistence manager in AEM. Esistono tre tipi di microkernel utilizzati con AEM: TarMK, MongoDB e Database relazionale (con supporto limitato). La scelta di un MicroKernel adatto alle tue esigenze dipende dallo scopo della tua istanza e dal tipo di implementazione che prevedi di effettuare. Per ulteriori informazioni sui microkernel, consultate la pagina Implementazioni Implementazioni consigliate consigliate.

Nodestore

In AEM, i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. La posizione in cui sono memorizzati i dati binari è detta archivio dati, mentre la posizione dei nodi e delle proprietà di contenuto è denominata archivio nodi.
Adobe consiglia a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti sia per le istanze AEM Author che per quelle Publish.
Supporto limitato per il Micro Kernel del database relazionale. Contatta l’Assistenza clienti di Adobe prima di utilizzare questo tipo di kernel Micro.

Data Store

Per gestire un numero elevato di file binari, si consiglia di utilizzare un archivio dati esterno al posto degli archivi nodo predefiniti, al fine di massimizzare le prestazioni. Ad esempio, se il progetto richiede un numero elevato di risorse multimediali, la loro memorizzazione nel file o nell'archivio dati di Azure/S3 consente di accedervi più rapidamente che archiviarle direttamente in un MongoDB.
Per ulteriori dettagli sulle opzioni di configurazione disponibili, consulta Configurazione di nodi e archivi dati.
Adobe consiglia di scegliere l'opzione di distribuire AEM su Azure o Amazon Web Services (AWS) tramite Adobe Managed Services, dove i clienti potranno usufruire di un team che disponga dell'esperienza e delle competenze necessarie per implementare e gestire AEM in questi ambienti cloud computing. Consulta la nostra documentazione aggiuntiva sui servizi gestiti Adobe.
Per consigli su come distribuire AEM su Azure o AWS, al di fuori di Adobe Managed Services, si consiglia di lavorare direttamente con il provider cloud o con uno dei nostri partner che supporta la distribuzione di AEM nell'ambiente cloud di tua scelta. Il fornitore o il partner cloud selezionato è responsabile delle specifiche di dimensionamento, della progettazione e dell'implementazione dell'architettura che offriranno per soddisfare i requisiti specifici di prestazioni, carico, scalabilità e sicurezza.
Per ulteriori dettagli, consulta anche la pagina sui requisiti tecnici .

Ricerca

In questa sezione sono elencati i provider di indice personalizzati utilizzati con AEM. Per ulteriori informazioni sull’indicizzazione, consultate Query Oak e indicizzazione .
Per la maggior parte delle distribuzioni, Adobe consiglia di utilizzare l'indice di Lucene. È consigliabile utilizzare Solr solo per la scalabilità in installazioni specializzate e complesse.

Linee guida per lo sviluppo

È consigliabile sviluppare AEM per prestazioni e scalabilità . Di seguito sono riportate una serie di best practice da seguire:
ANNULLA
  • Applicare la separazione tra presentazione, logica e contenuto
  • Usa le API AEM esistenti (ad esempio: Sling) e utensili (ad esempio: Replica
  • Sviluppare nel contesto dei contenuti effettivi
  • Sviluppare una capacità ottimale
  • Riduci al minimo il numero di salvataggi (ad es.: utilizzando flussi di lavoro transitori)
  • Verificate che tutti i punti finali HTTP siano RESTful
  • Limitare il campo di applicazione dell'osservazione JCR
  • Attenzione al thread asincrono
NON
  • Non utilizzate direttamente le API JCR, se potete
  • Non modificate /libs, ma utilizzate invece le sovrapposizioni
  • Non utilizzare query quando possibile
  • Non utilizzate i binding Sling per ottenere i servizi OSGi nel codice Java, ma utilizzate:
    • @Reference in a DS component
    • @Inject in a Sling Model
    • sling.getService() in una classe Sightly Use
    • sling.getService() in una JSP
    • a ServiceTracker
    • accesso diretto al registro dei servizi OSGi
Per ulteriori informazioni sullo sviluppo in AEM, consulta Sviluppo - Nozioni di base . Per ulteriori best practice, consulta Tecniche consigliate per lo sviluppo.

Scenari di riferimento

Tutti i test di benchmark visualizzati in questa pagina sono stati eseguiti in laboratorio.
Gli scenari di test descritti di seguito sono utilizzati per le sezioni di riferimento dei capitoli TarMK, MongoMk e TarMK rispetto a MongoMk. Per vedere quale scenario è stato utilizzato per un particolare test di benchmark, leggere il campo Scenario dalla tabella Specifiche tecniche.
Scenario di prodotto singolo
AEM Assets:
  • Interazioni utente: Sfoglia risorse / Cerca risorse / Scarica risorsa / Leggi metadati risorsa / Aggiorna metadati risorsa / Carica risorsa / Esegui flusso di lavoro Carica risorsa
  • Modalità di esecuzione: utenti simultanei, interazione singola per utente
Scenario prodotti misti
AEM Sites + Assets:
  • Interazioni utente siti: Pagina Leggi Articolo / Pagina Leggi / Crea paragrafo / Modifica paragrafo / Crea pagina contenuto / Attiva pagina contenuto / Ricerca autore
  • Interazioni utente risorse: Sfoglia risorse / Cerca risorse / Scarica risorsa / Leggi metadati risorsa / Aggiorna metadati risorsa / Carica risorsa / Esegui flusso di lavoro Carica risorsa
  • Modalità di esecuzione: utenti simultanei, interazioni miste per utente
Scenario di utilizzo verticale
File multimediali:
  • Pagina Leggi Articolo (27,4%), Pagina Di Lettura (10,9%), Crea Sessione (2,6%), Attiva Pagina Contenuto (1,7%), Crea Pagina Contenuto (0,4%), Crea Paragrafo (4,3%), Modifica Paragrafo (0,9%), Componente Immagine (0,9%), Sfoglia Risorse (20%), Leggi Metadati Risorse (8,5%), Scarica (4,2%), Ricerca risorsa (0,2%), Aggiornamento metadati risorsa (2,4%), Caricamento risorsa (1,2%), Sfoglia progetto (4,9%), Lettura progetto (6,6%), Project Add Asset (1,2%), Project Add Site (1,2%), Creazione progetto (0,1%), Ricerca autore (0,4%)
  • Modalità di esecuzione: utenti simultanei, interazioni miste per utente

TarMK

In questo capitolo vengono fornite le linee guida generali sulle prestazioni per TarMK che specificano i requisiti minimi di architettura e la configurazione delle impostazioni. Sono inoltre previsti test di riferimento per ulteriori chiarimenti.
Adobe consiglia a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di distribuzione, sia per le istanze AEM Author che Publish.
Per ulteriori informazioni su TarMK, consulta Scenari di distribuzione e Tar Storage .

Linee guida sull'architettura minima TarMK

Le linee guida di architettura minima presentate di seguito riguardano gli ambienti di produzione e i siti a traffico elevato. Queste non sono le specifiche Prerequisiti minime necessarie per eseguire AEM.
Per ottenere buone prestazioni quando si utilizza TarMK, è necessario partire dalla seguente architettura:
  • Un'istanza Author
  • Due istanze di pubblicazione
  • Due dispatcher
Di seguito sono illustrate le linee guida dell’architettura per i siti AEM e le risorse AEM.
La replica senza binario deve essere attivata se il datastore del file è condiviso.
Linee guida per l’architettura delle barre per i siti AEM
Linee guida per l’architettura delle barre per AEM Assets

Linee guida per le impostazioni TarMK

Per ottenere buone prestazioni, seguite le linee guida delle impostazioni riportate di seguito. Per istruzioni su come modificare le impostazioni, consultate questa pagina .
Impostazione Parametro Valore Descrizione
Code di lavoro Sling queue.maxparallel Impostate il valore su metà del numero di core CPU. Per impostazione predefinita, il numero di thread simultanei per coda di processi è uguale al numero di core CPU.
Coda flusso di lavoro transitorio Granite Max Parallel Impostare il valore a metà del numero di core CPU
Parametri JVM
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
500000
100000
250000
Vero
Aggiungi questi parametri JVM nello script di avvio di AEM per evitare che query estese sovraccarichino i sistemi.
Configurazione indice Lucene
CopyOnRead
CopyOnWrite
Prefetch Index Files
Abilitato
Abilitato
Abilitato
Per ulteriori dettagli sui parametri disponibili, consultate questa pagina .
Archivio dati = archivio dati S3
maxCachedBinarySize
cacheSizeInMB
1048576 (1 MB) o inferiore
2-10% della dimensione massima dell'heap
Vedere anche Configurazioni per l'archivio dati .
Flusso di lavoro Aggiorna risorsa DAM Transient Workflow spuntato Questo flusso di lavoro gestisce l'aggiornamento delle risorse.
Writeback di metadati DAM Transient Workflow spuntato Questo flusso di lavoro gestisce la riscrittura XMP sul binario originale e imposta l'ultima data modificata in JCR.

Benchmark delle prestazioni TarMK

Specifiche tecniche

Le prove di benchmark sono state eseguite sulle seguenti specifiche:
Nodo autore
Server
Hardware Bare metal (HP)
Sistema operativo
RedHat Linux
CPU/core
Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 core
RAM
32GB
Disco
Magnetico
Java
Oracle JRE versione 8
Heap JVM
16GB
Prodotto
AEM 6.2
Nodestore
TarMK
Datastore
File DS
Scenario
Prodotto singolo: Risorse / 30 thread simultanei

Risultati Benchmark Prestazioni

I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri effettivi di throughput.

MongoMK

Il motivo principale per cui si sceglie la persistenza MongoMK al di sopra di TarMK è quello di ridimensionare le istanze orizzontalmente. Ciò significa che due o più istanze di autori attive sono sempre in esecuzione e che utilizzano MongoDB come sistema di storage persistente. La necessità di eseguire più di un'istanza di autore deriva generalmente dal fatto che la CPU e la capacità di memoria di un singolo server, che supportano tutte le attività di authoring simultanee, non sono più sostenibili.
Per ulteriori informazioni su TarMK, consulta Scenari di distribuzione e archiviazione Mongo.

Linee guida sull'architettura minima MongoMK

Per ottenere buone prestazioni quando si utilizza MongoMK, è necessario partire dalla seguente architettura:
  • Tre istanze Author
  • Due istanze di pubblicazione
  • Tre istanze MongoDB
  • Due dispatcher
Negli ambienti di produzione, MongoDB sarà sempre utilizzato come set di repliche con due secondari e primario. Le letture e le scritture vanno al primo e le letture possono passare ai secondi. Se l'archiviazione non è disponibile, uno dei secondari può essere sostituito con un arbitro, ma i set di repliche MongoDB devono sempre essere composti da un numero dispari di istanze.
La replica senza binario deve essere attivata se il datastore del file è condiviso.

Linee guida sulle impostazioni MongoMK

Per ottenere buone prestazioni, seguite le linee guida delle impostazioni riportate di seguito. Per istruzioni su come modificare le impostazioni, consultate questa pagina .
Impostazione Parametro Valore (predefinito) Descrizione
Code di lavoro Sling queue.maxparallel Impostate il valore su metà del numero di core CPU. Per impostazione predefinita, il numero di thread simultanei per coda di processi è uguale al numero di core CPU.
Coda flusso di lavoro transitorio Granite Max Parallel Impostate il valore su metà del numero di core CPU.
Parametri JVM
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
Doak.mongo.maxQueryTimeMS
500000
100000
250000
Vero
60000
Aggiungi questi parametri JVM nello script di avvio di AEM per evitare che query estese sovraccarichino i sistemi.
Configurazione indice Lucene
CopyOnRead
CopyOnWrite
Prefetch Index Files
Abilitato
Abilitato
Abilitato
Per ulteriori dettagli sui parametri disponibili, consultate questa pagina .
Archivio dati = archivio dati S3
maxCachedBinarySize
cacheSizeInMB
1048576 (1 MB) o inferiore
2-10% della dimensione massima dell'heap
Vedere anche Configurazioni per l'archivio dati .
DocumentNodeStoreService
cache
nodeCachePercentage
childrenCachePercentage
diffCachePercentage
docChildrenCachePercentage
prevDocCachePercentage
persistentCache
2048
35 (25)
20 (10)
30 (5)
10 (3)
4 (4)
"merge_preserve"./cache,size=2048,binary=0,-compact,-compress
La dimensione predefinita della cache è impostata su 256 MB.
Ha un impatto sul tempo necessario per eseguire l'annullamento della validità della cache.
osservazione della quercia
thread pool
length
min & max = 20
50000

Benchmark delle prestazioni di MongoMK

Specifiche tecniche

Le prove di benchmark sono state eseguite sulle seguenti specifiche:
Nodo autore
Nodo MongoDB
Server
Hardware Bare metal (HP)
Hardware Bare metal (HP)
Sistema operativo
RedHat Linux
RedHat Linux
CPU/core
Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 core
Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 core
RAM
32GB
32GB
Disco
Magnetico - >1 k IOPS
Magnetico - >1 k IOPS
Java
Oracle JRE versione 8
N/D
Heap JVM
16GB
N/D
Prodotto
AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore
MongoMK
N/D
Datastore
File DS
N/D
Scenario
Prodotto singolo: Risorse / 30 thread simultanei
Prodotto singolo: Risorse / 30 thread simultanei

Risultati Benchmark Prestazioni

I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri effettivi di throughput.

TarMK vs MongoMK

La regola di base che deve essere presa in considerazione nella scelta tra i due è che TarMK è progettato per le prestazioni, mentre MongoMK è utilizzato per la scalabilità. Adobe consiglia a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di distribuzione, sia per le istanze AEM Author che Publish.
Il motivo principale per cui si sceglie la persistenza MongoMK al di sopra di TarMK è quello di ridimensionare le istanze orizzontalmente. Ciò significa che due o più istanze di autori attive sono sempre in esecuzione e che utilizzano MongoDB come sistema di storage persistente. La necessità di eseguire più di un'istanza di autore in genere deriva dal fatto che la CPU e la capacità di memoria di un singolo server, che supportano tutte le attività di authoring simultanee, non sono più sostenibili.
Per ulteriori dettagli su TarMK e MongoMK, consultate Implementazioni Microkernel: quale utilizzare consigliate.

Linee guida TarMK e MongoMk

Vantaggi di TarMK
  • Progettato appositamente per le applicazioni di gestione dei contenuti
  • I file sono sempre coerenti e possono essere sottoposti a backup utilizzando qualsiasi strumento di backup basato su file
  • Meccanismo di failover: per ulteriori informazioni, vedere Cold Standby .
  • Offre storage dei dati affidabile e ad alte prestazioni con costi operativi minimi
  • TCO inferiore (costo totale di proprietà)
Criteri per la scelta di MongoMK
  • Numero di utenti denominati connessi in un giorno: in migliaia o più
  • Numero di utenti simultanei: a centinaia o più
  • Volume di invii di risorse al giorno: in centinaia di migliaia o più
  • Volume di modifiche alla pagina al giorno: in centinaia di migliaia o più
  • Volume di ricerche al giorno: in decine di migliaia o più

Benchmark TarMK vs MongoMK

I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono numeri di throughput effettivi.

Scenario 1 Specifiche tecniche

Crea nodo OAK Nodo MongoDB
Server Hardware Bare metal (HP) Hardware Bare metal (HP)
Sistema operativo RedHat Linux RedHat Linux
CPU/core Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 core Intel(R) Xeon(R) CPU E5-2407 @2,40 GHz, 8 core
RAM 32GB 32GB
Disco Magnetico - >1 k IOPS Magnetico - >1 k IOPS
Java Oracle JRE versione 8 N/D
Heap JVM 16 GB 16GB N/D
Prodotto AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK o MongoMK N/D
Datastore File DS N/D
Scenario
Prodotto singolo: Risorse / 30 thread simultanei per esecuzione

Risultati Benchmark Prestazioni Scenario 1

Scenario 2 Specifiche tecniche

Per abilitare lo stesso numero di autori con MongoDB come con un sistema TarMK, è necessario un cluster con due nodi AEM. Un cluster MongoDB a quattro nodi può gestire 1,8 volte il numero di autori rispetto a un'istanza TarMK. Un cluster MongoDB a otto nodi può gestire 2,3 volte il numero di autori rispetto a un'istanza TarMK.
Crea nodo TarMK Crea nodo MongoMK Nodo MongoDB
Server AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
Sistema operativo RedHat Linux RedHat Linux RedHat Linux
CPU/core 32 32 32
RAM 60GB 60GB 60GB
Disco SSD - 10 k IOPS SSD - 10 k IOPS SSD - 10 k IOPS
Java Oracle JRE versione 8 Oracle JRE versione 8 N/D
Heap JVM 16 GB 30GB 30GB N/D
Prodotto AEM 6.2 AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK MongoMK N/D
Datastore File DS File DS N/D
Scenario
Caso di utilizzo verticale: Media / 2000 thread simultanei

Risultati Benchmark Prestazioni Scenario 2

Linee guida sulla scalabilità dell'architettura per AEM Sites e Assets

Riepilogo delle linee guida sulle prestazioni

Le linee guida presentate in questa pagina possono essere riassunte come segue:
  • TarMK con File Datastore è l'architettura consigliata per la maggior parte dei clienti:
    • Topologia minima: un'istanza Author, due istanze Publish, due Dispatcher
    • Replica senza binario attivata se il datastore file è condiviso
  • MongoMK con File Datastore è l'architettura consigliata per la scalabilità orizzontale del livello Author:
    • Topologia minima: tre istanze Author, tre istanze MongoDB, due istanze Publish, due Dispatcher
    • Replica senza binario attivata se il datastore file è condiviso
  • Il Nodestore deve essere memorizzato sul disco locale, non su un NAS (Network Attached Storage)
  • Quando si utilizza Amazon S3 :
    • Il datastore Amazon S3 è condiviso tra il livello Author e Publish
    • La replica senza binario deve essere attivata
    • La raccolta di dati per oggetti inattivi richiede una prima esecuzione su tutti i nodi Autore e Pubblica, quindi una seconda esecuzione su Autore
  • L'indice personalizzato deve essere creato in aggiunta all'indice out of the box in base alla maggior parte delle ricerche comuni
    • Per gli indici personalizzati è necessario utilizzare gli indici Lucene
  • La personalizzazione del flusso di lavoro può migliorare notevolmente le prestazioni , ad esempio rimuovendo il passaggio video nel flusso di lavoro "Aggiorna risorsa", disattivando i listener non utilizzati, ecc.
Per ulteriori dettagli, consultate anche la pagina Implementazioni consigliate .