Questa pagina fornisce linee guida generali su come ottimizzare le prestazioni della distribuzione AEM. Se hai poca esperienza con AEM, consulta le pagine seguenti prima di iniziare a leggere le linee guida sulle prestazioni:
Di seguito sono illustrate le opzioni di implementazione disponibili per l’AEM (scorri per visualizzare tutte le opzioni):
AEM Prodotto |
Topologia |
Sistema operativo |
Server applicazioni |
JRE |
Sicurezza |
Microkernel |
Archivio dati |
Indicizzazione |
Server web |
Browser |
Experience Cloud |
Sites |
Non HA |
Windows |
CQSE |
Oracle |
LDAP |
TAR |
Segmento |
Proprietà |
Apache |
Bordo |
Destinazione |
Risorse |
Publish-HA |
Solaris™ |
WebLogic |
IBM® |
SAML |
MongoDB |
File |
Lucene |
IIS |
IE |
Analytics |
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 |
|
|
Chrome |
Social network |
Mobile |
Author-Cluster |
IBM® AIX® |
JBoss® |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
Pubblico |
Multi-sito |
ASRP |
SUSE® |
|
|
|
RDB/SQLServer |
|
|
|
|
Risorse |
Commerce |
MSRP |
APPLE OS |
|
|
|
|
|
|
|
|
Attivazione |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
Mobile |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveCopy |
|
|
|
|
|
|
|
|
|
|
|
Screens |
|
|
|
|
|
|
|
|
|
|
|
Sicurezza documento |
|
|
|
|
|
|
|
|
|
|
|
Gestione processi |
|
|
|
|
|
|
|
|
|
|
|
App desktop |
|
|
|
|
|
|
|
|
|
|
|
Le linee guida sulle prestazioni si applicano principalmente ad AEM Sites.
Utilizzare le linee guida sulle prestazioni nelle situazioni seguenti:
Questo capitolo offre una panoramica generale dell’architettura dell’AEM e dei suoi componenti più importanti. Fornisce inoltre linee guida per lo sviluppo e descrive gli scenari di test utilizzati nei test di benchmark TarMK e MongoMK.
La piattaforma AEM è costituita dai seguenti elementi:
Per maggiori informazioni sulla piattaforma AEM, vedi Cos’è l’AEM.
L’attuazione dell’AEM si basa su tre importanti elementi costitutivi. Il Istanza autore che viene utilizzato 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 Pubblica istanza dal punto in cui gli utenti finali vi accedono. Il terzo elemento costitutivo è il Dispatcher modulo che gestisce il caching e il filtro URL ed è installato sul server web. Per ulteriori informazioni sull’architettura dell’AEM, consulta Scenari di implementazione tipici.
I micro kernel fungono da gestori della persistenza nell'AEM. Esistono tre tipi di micro kernel utilizzati con AEM: TarMK, MongoDB e Relational Database (con supporto limitato). La scelta di un tipo di implementazione adatto alle tue esigenze dipende dallo scopo dell’istanza e dal tipo di implementazione che stai prendendo in considerazione. Per ulteriori informazioni sui micro kernel, vedere Distribuzioni consigliate pagina.
In AEM, i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. La posizione in cui vengono memorizzati i dati binari è indicata come Archivio dati, mentre la posizione dei nodi di contenuto e delle proprietà è denominata Archivio nodi.
L’Adobe consiglia di utilizzare TarMK come tecnologia di persistenza predefinita utilizzata dai clienti sia per le istanze AEM Author che per quelle Publish.
Il supporto del micro kernel del database relazionale è limitato. Contatto Assistenza clienti Adobe prima di utilizzare questo tipo di micro kernel.
Quando si tratta di un numero elevato di file binari, si consiglia di utilizzare un archivio dati esterno invece degli archivi nodi predefiniti per massimizzare le prestazioni. Ad esempio, se il progetto richiede molte risorse multimediali, la loro memorizzazione nel file o nell’archivio dati di Azure/S3 rende l’accesso più rapido rispetto alla loro memorizzazione direttamente in un MongoDB.
Per ulteriori dettagli sulle opzioni di configurazione disponibili, vedi Configurazione di nodi e archivi dati.
L’Adobe consiglia di scegliere l’opzione di distribuzione dell’AEM in Azure o Amazon Web Services (AWS) tramite Adobe Managed Services. I clienti traggono vantaggio da un team con l’esperienza e le competenze necessarie per implementare e utilizzare AEM in questi ambienti di cloud computing. Consulta documentazione aggiuntiva su Adobe Managed Services.
Per raccomandazioni su come distribuire AEM in Azure o AWS, al di fuori di Adobe Managed Services, l’Adobe consiglia di lavorare direttamente con il provider cloud. Oppure, collabora con uno dei partner di Adobe che supportano l’implementazione dell’AEM nell’ambiente cloud desiderato. Il provider cloud o partner selezionato è responsabile delle specifiche di dimensionamento, della progettazione e dell'implementazione dell'architettura supportata per soddisfare requisiti specifici di prestazioni, carico, scalabilità e sicurezza.
Consulta anche requisiti tecnici pagina.
In questa sezione sono elencati i provider di indice personalizzati utilizzati con AEM. Per ulteriori informazioni sull’indicizzazione, consulta Query e indicizzazione Oak.
Per la maggior parte delle distribuzioni, Adobe consiglia di utilizzare l’indice Lucene. Utilizza Solr solo per la scalabilità in implementazioni specializzate e complesse.
Sviluppare per l’AEM con l’obiettivo di prestazioni e scalabilità. Di seguito sono riportate le best practice che è possibile seguire:
DO
NON
Non utilizzare direttamente le API JCR, se possibile
Non modificare /libs, ma utilizza le sovrapposizioni
Non utilizzare le query dove possibile
Non utilizzare le associazioni Sling per ottenere i servizi OSGi nel codice Java™, ma utilizza piuttosto:
Per maggiori dettagli sullo sviluppo dell'AEM, vedi Sviluppo - Nozioni di base. Per ulteriori best practice, consulta Best practice per lo sviluppo.
Tutti i test di benchmark mostrati in questa pagina sono stati eseguiti in laboratorio.
Gli scenari di test dettagliati di seguito sono utilizzati per le sezioni di benchmark dei capitoli TarMK, MongoMk e TarMK vs MongoMk. Per vedere quale scenario è stato utilizzato per un particolare test di benchmark, leggere il campo Scenario dalla sezione Specifiche tecniche tabella.
Scenario con un singolo prodotto
AEM Assets:
Scenario prodotti misti
AEM Sites + Assets:
Scenario del caso d’uso verticale
File multimediali:
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%)
Questo capitolo fornisce le linee guida generali sulle prestazioni per TarMK specificando i requisiti minimi dell’architettura e la configurazione delle impostazioni. Vengono inoltre fornite prove comparative per ulteriori chiarimenti.
L’Adobe consiglia di utilizzare TarMK come tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di implementazione, sia per le istanze AEM Author che per quelle Publish.
Per ulteriori informazioni su TarMK, consulta Scenari di implementazione e Archiviazione Tar.
Le linee guida dell’architettura minima presentate di seguito si riferiscono agli ambienti di produzione e ai siti con traffico elevato. Queste linee guida sono non il specifiche minime per il funzionamento dell'AEM.
Per stabilire buone prestazioni quando si utilizza TarMK, è necessario partire dalla seguente architettura:
Di seguito sono illustrate le linee guida sull’architettura dei siti AEM e AEM Assets.
È necessario attivare la replica senza binario ATTIVATO se l’archivio dati file è condiviso.
Linee guida sull’architettura Tar per AEM Sites
Linee guida sull’architettura Tar per AEM Assets
Per ottenere prestazioni ottimali, attieniti alle linee guida per le impostazioni riportate di seguito. Per istruzioni su come modificare le impostazioni, vedi questa pagina.
Impostazione | Parametro | Valore | Descrizione |
Code processi Sling | queue.maxparallel |
Impostare il valore su metà del numero di core della CPU. | Per impostazione predefinita, il numero di thread simultanei per coda processi è uguale al numero di core CPU. |
Coda del flusso di lavoro transitorio Granite | Max Parallel |
Imposta il valore su metà del numero di core della CPU | |
Parametri JVM |
|
500000 100000 250000 Vero |
Per evitare che query estese sovraccarichi i sistemi, aggiungi questi parametri JVM nello script iniziale dell’AEM. |
Configurazione dell’indice Lucene |
|
Abilitato Abilitato Abilitato |
Per maggiori dettagli sui parametri disponibili, vedi questa pagina. |
Archivio dati = Archivio dati S3 |
|
1048576 (1 MB) o inferiore 2-10% della dimensione heap massima |
Vedi 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 il write-back dell’XMP nel file binario originale e imposta la data dell’ultima modifica in JCR. |
I test di riferimento sono stati eseguiti sulle seguenti specifiche:
Nodo Author | |
---|---|
Server | Hardware Bare Metal (HP) |
Sistema operativo | Red Hat® Linux® |
CPU/core | CPU Intel® Xeon® E5-2407 @2.40GHz, 8 core |
RAM | 32 GB |
Disco | Magnetico |
Java™ | Oracle JRE versione 8 |
Heap JVM | 16 GB |
Prodotto | AEM 6.2 |
Nodestore | TarMK |
Archivio dati | DS file |
Scenario | Singolo prodotto: Assets / 30 thread simultanei |
I numeri presentati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri di throughput effettivi.
Il motivo principale per scegliere il back-end di persistenza MongoMK su TarMK è quello di scalare le istanze orizzontalmente. Questa funzionalità significa disporre di due o più istanze di authoring attive sempre in esecuzione e utilizzare MongoDB come sistema di storage di persistenza. La necessità di eseguire più di un’istanza di authoring deriva in genere dal fatto che la capacità di CPU e di memoria di un singolo server, che supporta tutte le attività di authoring simultanee, non è più sostenibile.
Per ulteriori informazioni su TarMK, consulta Scenari di implementazione e Archiviazione Mongo.
Per stabilire buone prestazioni quando si utilizza MongoMK, è necessario partire dalla seguente architettura:
Negli ambienti di produzione, MongoDB viene sempre utilizzato come set di repliche con un database primario e due database secondari. Le letture e le scritture vanno al primario e le letture possono andare ai secondari. Se l'archiviazione non è disponibile, è possibile sostituire uno dei database secondari con un arbitro, ma i set di repliche MongoDB devono essere sempre composti da un numero dispari di istanze.
È necessario attivare la replica senza binario ATTIVATO se l’archivio dati file è condiviso.
Per ottenere prestazioni ottimali, attieniti alle linee guida per le impostazioni riportate di seguito. Per istruzioni su come modificare le impostazioni, vedi questa pagina.
Impostazione | Parametro | Valore (predefinito) | Descrizione |
Code processi Sling | queue.maxparallel |
Impostare il valore su metà del numero di core della CPU. | Per impostazione predefinita, il numero di thread simultanei per coda processi è uguale al numero di core CPU. |
Coda del flusso di lavoro transitorio Granite | Max Parallel |
Impostare il valore su metà del numero di core della CPU. | |
Parametri JVM |
|
500000 100000 250000 Vero 60000 |
Per evitare che query estese sovraccarichi i sistemi, aggiungi questi parametri JVM nello script iniziale dell’AEM. |
Configurazione dell’indice Lucene |
|
Abilitato Abilitato Abilitato |
Per ulteriori dettagli sui parametri disponibili, vedi questa pagina. |
Archivio dati = Archivio dati S3 |
|
1048576 (1 MB) o inferiore 2-10% della dimensione heap massima |
Vedi anche Configurazioni archivio dati. |
DocumentNodeStoreService |
|
2048 35 (25) 20 (10) 30 (5) 10 (3) 4 (4) ./cache,size=2048,binario=0,-compatto,-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 oak |
|
min e max = 20 50000 |
I test di riferimento sono stati eseguiti sulle seguenti specifiche:
Nodo Author | Nodo MongoDB | |
---|---|---|
Server | Hardware Bare Metal (HP) | Hardware Bare Metal (HP) |
Sistema operativo | Red Hat® Linux® | Red Hat® Linux® |
CPU/core | CPU Intel® Xeon® E5-2407 @2.40GHz, 8 core | CPU Intel® Xeon® E5-2407 @2.40GHz, 8 core |
RAM | 32 GB | 32 GB |
Disco | Magnetico - >1.000 IOPS | Magnetico - >1.000 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 |
Archivio dati | DS file | N/D |
Scenario | Singolo prodotto: Assets / 30 thread simultanei | Singolo prodotto: Assets / 30 thread simultanei |
I numeri presentati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri di throughput effettivi.
La regola di base da tenere in considerazione quando si sceglie tra i due è che TarMK è progettato per le prestazioni, mentre MongoMK è utilizzato per la scalabilità. L’Adobe consiglia di utilizzare TarMK come tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di implementazione, sia per le istanze AEM Author che per quelle Publish.
Il motivo principale per scegliere il back-end di persistenza MongoMK su TarMK è quello di scalare le istanze orizzontalmente. Questa funzionalità significa disporre di due o più istanze di authoring attive sempre in esecuzione e utilizzare MongoDB come sistema di storage di persistenza. La necessità di eseguire più di un’istanza di authoring deriva in genere dal fatto che la capacità di CPU e di memoria di un singolo server, che supporta tutte le attività di authoring simultanee, non è più sostenibile.
Per maggiori dettagli su TarMK vs MongoMK, vedi Distribuzioni consigliate.
Vantaggi di TarMK
Criteri per scegliere MongoMK
I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono numeri di throughput effettivi.
Crea nodo OAK | Nodo MongoDB | ||
Server | Hardware Bare Metal (HP) | Hardware Bare Metal (HP) | |
Sistema operativo | Red Hat® Linux® | Red Hat® Linux® | |
CPU/core | CPU Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 core | CPU Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 core | |
RAM | 32 GB | 32 GB | |
Disco | Magnetico - >1.000 IOPS | Magnetico - >1.000 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 | |
Archivio dati | DS file | N/D | |
Scenario |
|
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 un numero di autori pari a 1,8 volte quello di un’istanza TarMK. Un cluster MongoDB a otto nodi può gestire un numero di autori 2,3 volte superiore a quello di un’istanza TarMK.
Nodo Author TarMK | Nodo MongoMK dell’autore | Nodo MongoDB | |
Server | AWS c3.8xlarge | AWS c3.8xlarge | AWS c3.8xlarge |
Sistema operativo | Red Hat® Linux® | Red Hat® Linux® | Red Hat® Linux® |
CPU/core | 32 | 32 | 32 |
RAM | 60 GB | 60 GB | 60 GB |
Disco | SSD - IOPS 10.000 | SSD - IOPS 10.000 | SSD - IOPS 10.000 |
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 |
Archivio dati | DS file | DS file |
N/D |
Scenario |
|
Le linee guida presentate in questa pagina possono essere riassunte come segue:
TarMK con archivio dati file - Architettura consigliata per la maggior parte dei clienti:
MongoMK con archivio dati file - Architettura consigliata per la scalabilità orizzontale del livello di authoring:
Nodestore - Archiviazione su disco locale, non NAS (Network Attached Storage)
Quando si utilizza Amazon S3:
È necessario creare un indice personalizzato oltre a quello predefinito - In base alle ricerche più comuni
La personalizzazione del flusso di lavoro può migliorare notevolmente le prestazioni : rimuovi il passaggio video nel flusso di lavoro "Aggiorna risorsa", disabilitando i listener non utilizzati e così via.
Per ulteriori dettagli, consulta anche Distribuzioni consigliate pagina.