Linee guida sulle prestazioni

Questa pagina contiene linee guida generali su come ottimizzare le prestazioni della distribuzione AEM. Se non avete mai AEM, passate le pagine seguenti prima di iniziare a leggere le linee guida sulle prestazioni:

• AEM Concetti di base
• Panoramica dello storage in AEM
• Implementazioni consigliate
• Requisiti tecnici

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					Risorse
Commerce	MSRP	Apple OS									Attivazione
Dynamic Media	JSRP										Mobile
Brand Portal	J2E
AoD
LiveFyre
Screens
Doc Security
Mgt di processo
app desktop

Quando utilizzare le linee guida sulle prestazioni

Le linee guida sulle prestazioni devono essere utilizzate nelle situazioni seguenti:

• Prima distribuzione: Quando pianificate di distribuire AEM Sites o Assets per la prima volta, è 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: Quando si esegue 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 archivio dati di Amazon S3 o Microsoft Azure invece di un archivio dati file.

Introduzione

Questo capitolo offre una panoramica generale dell'architettura 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 è costituita dai seguenti componenti:

Per ulteriori informazioni sulla piattaforma AEM, vedere AEM.

Architettura AEM

Esistono tre importanti elementi di base per una distribuzione AEM. La Istanza 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 la memorizzazione nella cache e il filtraggio degli URL e che viene installato sul server Web. Per ulteriori informazioni sull'architettura AEM, vedere Scenari di distribuzione tipici.

Micro kernel

I micro kernel 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, vedere la pagina Deployments consigliati.

Nodestore

In AEM, i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. La posizione in cui sono memorizzati i dati binari è denominata Data Store, mentre la posizione dei nodi e delle proprietà di contenuto è denominata Node Store.

Archivio dati

Per gestire un numero elevato di file binari, si consiglia di utilizzare un archivio dati esterno al posto degli archivi di nodi 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 all'interno di un MongoDB.

Per ulteriori dettagli sulle opzioni di configurazione disponibili, vedere Configurazione dei nodi e dei Data Store.

Ricerca

In questa sezione sono elencati i provider di indice personalizzati utilizzati con AEM. Per ulteriori informazioni sull'indicizzazione, vedere Query Oak e Indicizzazione.

Linee guida per lo sviluppo

È necessario sviluppare per AEM mirare a prestazioni e scalabilità. Di seguito sono riportate una serie di best practice che potete 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 utilizzate le 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, leggere Developing - The Basics (Sviluppo - Nozioni di base). Per ulteriori best practice, vedere Tecniche consigliate per lo sviluppo.

Scenari di riferimento

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 + Risorse:

• Interazioni utente sui 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, vedere Scenari di distribuzione e Tar Storage.

Linee guida sull'architettura minima TarMK

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 AEM siti e AEM Assets.

Linee guida per l'architettura AEM Sites

Linee guida per l'architettura 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, vedere 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	Aggiungere questi parametri JVM nello script di avvio 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, vedere questa pagina.
Archivio dati = archivio dati S3	maxCachedBinarySize cacheSizeInMB	1048576 (1 MB) o inferiore 2-10% della dimensione massima dell'heap	Vedere anche Configurazioni 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 XMP riscrittura nel 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® Xeon® CPU E5-2407 @2,40 GHz, 8 core
RAM	32 GB
Disco	Magnetico
Java	Oracle JRE versione 8
Heap JVM	16 GB
Prodotto	AEM 6.2
Nodestore	TarMK
Datastore	File DS
Scenario	Prodotto singolo: Risorse / 30 thread simultanei

Risultati benchmark prestazioni

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, vedere Scenari di distribuzione e Mongo Storage.

Linee guida sull'architettura minima di 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

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, vedere 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	Aggiungere questi parametri JVM nello script di avvio 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, vedere questa pagina.
Archivio dati = archivio dati S3	maxCachedBinarySize cacheSizeInMB	1048576 (1 MB) o inferiore 2-10% della dimensione massima dell'heap	Vedere anche Configurazioni archivio dati.
DocumentNodeStoreService	cache nodeCachePercentage childrenCachePercentage diffCachePercentage docChildrenCachePercentage prevDocCachePercentage persistentCache	2048 35 (25) 20 (10) 30 (5) 10 (3) 4 (4) ./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® Xeon® CPU E5-2407 @2,40 GHz, 8 core	Intel® Xeon® CPU E5-2407 @2,40 GHz, 8 core
RAM	32 GB	32 GB
Disco	Magnetico - >1 k IOPS	Magnetico - >1 k IOPS
Java	Oracle JRE versione 8	N/D
Heap JVM	16 GB	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

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 persistenza. 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, vedere Implementazioni 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
• Offre un 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ù

TarMK vs MongoMK Benchmark

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	32 GB	32 GB
Disco	Magnetico - >1 k IOPS	Magnetico - >1 k IOPS
Java	Oracle JRE versione 8	N/D
Heap JVM 16 GB	16 GB	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

	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	60 GB	60 GB	60 GB
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	30 GB	30 GB	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 risorse

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

• I nodi devono essere memorizzati sul disco locale, non su uno storage NAS (Network Attached Storage)

• Quando si utilizza Amazon S3:

  • Il datastore Amazon S3 è condiviso tra il livello Autore e Pubblica
  • 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 basato sulla 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, consultare anche la pagina Implementazioni consigliate.