Linee guida sulle prestazioni
- Si applica a:
- Experience Manager 6.5
- Argomenti:
- Configurazione
Creato per:
- Amministratore
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 | Edge | Destinazione |
| Risorse | 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 |
| Moduli | 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 |
NOTAQuando utilizzare le linee guida sulle prestazioni
Utilizzare le linee guida sulle prestazioni nelle situazioni seguenti:
- Prima distribuzione: quando si pianifica di distribuire AEM Sites o Assets per la prima volta, è importante comprendere le opzioni disponibili. In particolare durante la configurazione di Micro Kernel, Node Store e Data Store (rispetto alle impostazioni predefinite). Ad esempio, modificando le impostazioni predefinite dell’archivio dati di TarMK in Archivio dati file.
- 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: quando l'architettura Nodestore selezionata non soddisfa i requisiti, è importante comprendere le differenze di prestazioni rispetto ad altre opzioni di topologia. Ad esempio, distribuendo TarMK al posto di MongoMK oppure utilizzando un archivio dati di file al posto di un archivio dati di Amazon S3 o Microsoft® Azure.
- Aggiunta di altri autori: quando la topologia TarMK consigliata non soddisfa i requisiti di prestazioni e l'upsize del nodo di authoring ha raggiunto la capacità massima disponibile, comprendere le differenze di prestazioni. Confronta con l’utilizzo di MongoMK con tre o più nodi Author. Ad esempio, distribuendo MongoMK invece di TarMK.
- Aggiunta di altro contenuto: quando l'architettura dell'archivio dati consigliata non soddisfa le tue esigenze, è importante comprendere le differenze di prestazioni rispetto ad altre opzioni dell'archivio dati. Esempio: utilizzo dell’archivio dati di Amazon S3 o Microsoft® Azure invece di un archivio dati file.
Introduzione
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.
Piattaforma AEM
La piattaforma AEM è costituita dai seguenti elementi:
Per ulteriori informazioni sulla piattaforma AEM, vedere Informazioni sull'AEM.
Architettura dell’AEM
L’attuazione dell’AEM si basa su tre importanti elementi costitutivi. Istanza di authoring 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 Publish da cui gli utenti finali accedono. Il terzo blocco predefinito è Dispatcher, un modulo che gestisce il caching e il filtro degli URL e che è installato nel server Web. Per ulteriori informazioni sull'architettura AEM, vedere Scenari di distribuzione tipici.
Microkernel
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 la pagina Distribuzioni consigliate.
Nodestore
In AEM, i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. Il percorso in cui vengono archiviati i dati binari è indicato come Archivio dati, mentre il percorso dei nodi di contenuto e delle proprietà è denominato Archivio nodi.
NOTA
CAUTION
Archivio dati
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, vedere Configurazione di nodi e archivi dati.
NOTERicerca
In questa sezione sono elencati i provider di indice personalizzati utilizzati con AEM. Per ulteriori informazioni sull'indicizzazione, vedere Query e indicizzazione Oak.
NOTE
Linee guida per lo sviluppo
Sviluppo per AEM con obiettivo di prestazioni e scalabilità. Di seguito sono riportate le best practice che è possibile seguire:
DO
- Applicare la separazione di presentazione, logica e contenuto
- Utilizzare le API AEM esistenti (ad es. Sling) e gli strumenti (ad es. Replication)
- Sviluppa nel contesto di contenuti effettivi
- Sviluppo per una migliore capacità di memorizzazione in cache
- Riduci al minimo il numero di salvataggi (ad esempio, utilizzando flussi di lavoro transitori)
- Assicurati che tutti gli endpoint HTTP siano RESTful
- Limitare l’ambito dell’osservazione JCR
- Presta attenzione al thread asincrono
NON
-
Non utilizzare direttamente le API JCR, se possibile
-
Non modificare /libs, ma utilizzare le sovrapposizioni
-
Non utilizzare le query dove possibile
-
Non utilizzare le associazioni Sling per ottenere i servizi OSGi nel codice Java™, ma utilizza:
- @Reference in un componente DS
- @Inject in un modello Sling
- sling.getService() in una classe Sightly Use
- sling.getService() in una JSP
- a ServiceTracker
- accesso diretto al registro del servizio OSGi
Per ulteriori dettagli sullo sviluppo in AEM, leggere Sviluppo - Nozioni di base. Per ulteriori best practice, consulta Best practice per lo sviluppo.
Scenari di benchmark
NOTEGli scenari di test dettagliati di seguito sono utilizzati per le sezioni di benchmark dei capitoli TarMK, MongoMk e TarMK vs MongoMk. Per visualizzare lo scenario utilizzato per un particolare test di benchmark, leggere il campo Scenario dalla tabella Specifiche tecniche.
Scenario per singolo prodotto
AEM Assets:
- Interazioni utente: Sfoglia Assets / Cerca Assets / Scarica risorsa / Leggi metadati risorsa / Aggiorna metadati risorsa / Carica risorsa / Esegui il flusso di lavoro Carica risorsa
- Modalità di esecuzione: utenti simultanei, singola interazione per utente
Scenario prodotti misti
AEM Sites + Assets:
- Interazioni utente su Sites: leggi pagina articolo / leggi pagina / crea paragrafo / modifica paragrafo / crea pagina contenuto / attiva pagina contenuto / crea ricerca
- Interazioni degli utenti di Assets: Sfoglia Assets / Cerca Assets / Scarica risorsa / Leggi metadati risorsa / Aggiorna metadati risorsa / Carica risorsa / Esegui il flusso di lavoro Carica risorsa
- Modalità di esecuzione: utenti simultanei, interazioni miste per utente
Scenario di utilizzo verticale
Contenuti 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%)- Modalità di esecuzione: utenti simultanei, interazioni miste per utente
TarMK
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 di creazione AEM che per quelle di Publish.
Per ulteriori informazioni su TarMK, vedere Scenari di distribuzione e Archiviazione Tar.
Linee guida sull’architettura minima di TarMK
NOTEPer stabilire buone prestazioni quando si utilizza TarMK, è necessario partire dalla seguente architettura:
- Un’istanza Autore
- Due istanze di Publish
- Due dispatcher
Di seguito sono illustrate le linee guida sull’architettura dei siti AEM e AEM Assets.
NOTELinee guida sull'architettura Tar per AEM Sites
Linee guida sull'architettura Tar per AEM Assets
Linee guida per le impostazioni TarMK
Per ottenere prestazioni ottimali, attieniti alle linee guida per le impostazioni riportate di seguito. Per istruzioni su come modificare le impostazioni, vedere Ottimizzazione delle prestazioni.
queue.maxparallelMax ParallelDoak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
500000
100000
250000
Vero
CopyOnRead
CopyOnWrite
Prefetch Index Files
Abilitato
Abilitato
Abilitato
maxCachedBinarySize
cacheSizeInMB
1048576 (1 MB) o inferiore
2-10% della dimensione heap massima
Transient WorkflowTransient WorkflowBenchmark delle prestazioni TarMK
Specifiche tecniche
I test di riferimento sono stati eseguiti sulle seguenti specifiche:
Risultati benchmark prestazioni
NOTE
MongoMK
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, vedere Scenari di distribuzione e Archiviazione Mongo.
Linee guida sull’architettura minima di MongoMK
Per stabilire buone prestazioni quando si utilizza MongoMK, è necessario partire dalla seguente architettura:
- Tre istanze di authoring
- Due istanze di Publish
- Tre istanze MongoDB
- Due dispatcher
NOTENOTE
Linee guida per le impostazioni MongoMK
Per ottenere prestazioni ottimali, attieniti alle linee guida per le impostazioni riportate di seguito. Per istruzioni su come modificare le impostazioni, vedere Ottimizzazione delle prestazioni.
queue.maxparallelMax ParallelDoak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
Doak.mongo.maxQueryTimeMS
500000
100000
250000
Vero
60000
CopyOnRead
CopyOnWrite
Prefetch Index Files
Abilitato
Abilitato
Abilitato
maxCachedBinarySize
cacheSizeInMB
1048576 (1 MB) o inferiore
2-10% della dimensione heap massima
cache
nodeCachePercentage
childrenCachePercentage
diffCachePercentage
docChildrenCachePercentage
prevDocCachePercentage
persistentCache
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.
thread pool
length
min e max = 20
50000
Benchmark delle prestazioni MongoMK
Specifiche tecniche
I test di riferimento sono stati eseguiti sulle seguenti specifiche:
Risultati benchmark prestazioni
NOTE
TarMK e MongoMK
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 di creazione AEM che per quelle di 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 ulteriori dettagli su TarMK rispetto a MongoMK, vedi Distribuzioni consigliate.
Linee guida per 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
- Fornisce un meccanismo di failover. Per ulteriori dettagli, vedere Standby a freddo
- Fornisce prestazioni elevate e storage affidabile dei dati con un sovraccarico operativo minimo
- Riduzione del TCO (costo totale di proprietà)
Criteri per scegliere MongoMK
- Numero di utenti con nome connessi in un giorno: in migliaia o più
- Numero di utenti simultanei: in centinaia o più
- Volume di acquisizioni di risorse al giorno: in centinaia di migliaia o più
- Volume di modifiche di pagina al giorno: in centinaia di migliaia o più
- Volume di ricerche al giorno: in decine di migliaia o più
Confronto tra TarMK e i benchmark MongoMK
NOTEScenario 1 - Specifiche tecniche
Risultati del benchmark delle prestazioni dello scenario 1
Scenario 2 - Specifiche tecniche
NOTERisultati del benchmark delle prestazioni dello scenario 2
Linee guida per la 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 archivio dati file - Architettura consigliata per la maggior parte dei clienti:
- Topologia minima: un’istanza Author, due istanze Publish, due Dispatcher
- Replica senza binari attivata se l'archivio dati file è condiviso
-
MongoMK con archivio dati file - Architettura consigliata per la scalabilità orizzontale del livello di authoring:
- Topologia minima: tre istanze Author, tre istanze MongoDB, due istanze Publish, due Dispatcher
- Replica senza binari attivata se l'archivio dati file è condiviso
-
Nodestore - Archiviato nel disco locale, non in un NAS (Network Attached Storage)
-
Quando si utilizza Amazon S3:
- L’archivio dati Amazon S3 è condiviso tra il livello Author e Publish
- È necessario attivare la replica senza binario
- La raccolta oggetti inattivi del datastore richiede una prima esecuzione su tutti i nodi Author e Publish, quindi una seconda esecuzione su Author
-
L'indice personalizzato deve essere creato in aggiunta all'indice predefinito, in base alle ricerche più comuni
- Gli indici Lucene devono essere utilizzati per gli indici personalizzati
-
La personalizzazione del flusso di lavoro può migliorare notevolmente le prestazioni. Rimuovere il passaggio video nel flusso di lavoro "Aggiorna risorsa", disabilitare i listener non utilizzati e così via.
Per ulteriori dettagli, leggere anche la pagina Distribuzioni consigliate.