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:
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 |
|
|
|
|
|
|
|
|
|
|
|
Le linee guida sulle prestazioni si applicano principalmente a AEM Sites.
Le linee guida sulle prestazioni devono essere utilizzate nelle situazioni seguenti:
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 è costituita dai seguenti componenti:
Per ulteriori informazioni sulla piattaforma AEM, vedere 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.
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.
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.
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. Contattare l'Assistenza clienti Adobe prima di utilizzare questo tipo di kernel Micro.
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.
Adobe consiglia di scegliere l'opzione di distribuire AEM su Azure o Amazon Web Services (AWS) utilizzando Adobe Managed Services, dove i clienti potranno beneficiare di un team che possiede l'esperienza e le capacità di implementazione e funzionamento AEM in questi ambienti cloud computing. Consultare la documentazione aggiuntiva su Adobe Managed Services.
Per consigli su come distribuire AEM su Azure o AWS, al di fuori di Adobe Managed Services, si consiglia vivamente di lavorare direttamente con il provider cloud o con uno dei nostri partner che supporta la distribuzione di AEM nell'ambiente cloud di vostra 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, vedere anche la pagina Technical requirements.
In questa sezione sono elencati i provider di indice personalizzati utilizzati con AEM. Per ulteriori informazioni sull'indicizzazione, vedere Query Oak e Indicizzazione.
Per la maggior parte delle distribuzioni, Adobe consiglia di utilizzare l'indice Lucene. È consigliabile utilizzare Solr solo per la scalabilità in installazioni specializzate e complesse.
È necessario sviluppare per AEM mirare a prestazioni e scalabilità. Di seguito sono riportate una serie di best practice che potete seguire:
ANNULLA
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:
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.
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:
Scenario prodotti misti
AEM Sites + Risorse:
Scenario di utilizzo verticale
File multimediali:
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.
Le linee guida di architettura minima presentate di seguito riguardano gli ambienti di produzione e i siti a traffico elevato. Si tratta di not le specifiche minime necessarie per eseguire AEM.
Per ottenere buone prestazioni quando si utilizza TarMK, è necessario partire dalla seguente architettura:
Di seguito sono illustrate le linee guida dell'architettura per AEM siti e AEM Assets.
La replica senza binario deve essere attivata ON se il datastore del file è condiviso.
Linee guida per l'architettura AEM Sites
Linee guida per l'architettura AEM Assets
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 |
|
500000 100000 250000 Vero |
Aggiungere questi parametri JVM nello script di avvio AEM per evitare che query estese sovraccarichino i sistemi. |
Configurazione indice Lucene |
|
Abilitato Abilitato Abilitato |
Per ulteriori dettagli sui parametri disponibili, vedere questa pagina. |
Archivio dati = archivio dati S3 |
|
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. |
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 |
I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri effettivi di throughput.
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.
Per ottenere buone prestazioni quando si utilizza MongoMK, è necessario partire dalla seguente architettura:
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 ON se il datastore del file è condiviso.
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 |
|
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 |
|
Abilitato Abilitato Abilitato |
Per ulteriori dettagli sui parametri disponibili, vedere questa pagina. |
Archivio dati = archivio dati S3 |
|
1048576 (1 MB) o inferiore 2-10% della dimensione massima dell'heap |
Vedere anche Configurazioni archivio dati. |
DocumentNodeStoreService |
|
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 |
|
min & max = 20 50000 |
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 |
I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri effettivi di throughput.
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.
Vantaggi di TarMK
Criteri per la scelta di 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 | 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 |
|
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 | 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 |
|
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:
MongoMK con File Datastoreè l'architettura consigliata per la scalabilità orizzontale del livello Author:
I nodi devono essere memorizzati sul disco locale, non su uno storage NAS (Network Attached Storage)
Quando si utilizza Amazon S3:
L'indice personalizzato deve essere creato in aggiunta all'indice out of the box basato sulla maggior parte delle ricerche comuni
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.