Linee guida sulle prestazioni

Questa pagina fornisce linee guida generali su come ottimizzare le prestazioni della distribuzione di AEM. Se non hai ancora AEM, passa alle 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 (scorri per visualizzare tutte le opzioni):

Quando utilizzare le linee guida sulle prestazioni

Utilizza le linee guida sulle prestazioni nelle situazioni seguenti:

• Prima implementazione: Quando prevedi di distribuire AEM Sites o Assets per la prima volta, è importante comprendere le opzioni disponibili per la configurazione del Micro Kernel, del Node Store e del Data Store (rispetto alle impostazioni predefinite). Ad esempio, la modifica delle impostazioni predefinite di Data Store per TarMK in File Data Store.
• Aggiornamento a una nuova versione: Quando esegui 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 del nodestore selezionato non soddisfa le tue esigenze, è importante comprendere le differenze di prestazioni rispetto ad altre opzioni di topologia. Ad esempio, distribuire TarMK invece di MongoMK o utilizzare un archivio dati file invece 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 Autore ha raggiunto la capacità massima disponibile, è importante comprendere le differenze di prestazioni rispetto all’utilizzo di MongoMK con tre o più nodi Autore. Ad esempio, distribuisci MongoMK invece di TarMK.
• Aggiunta di altro contenuto: Quando l’architettura consigliata dell’archivio dati non soddisfa i requisiti, è 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 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.

Piattaforma AEM

La piattaforma AEM è costituita dai seguenti componenti:

Per ulteriori informazioni sulla piattaforma AEM, consulta AEM.

Architettura AEM

Sono disponibili tre importanti elementi di base per una distribuzione AEM. La Istanza autore utilizzato da autori di contenuti, editor e approvatori per creare e rivedere contenuti. Quando il contenuto viene approvato, viene pubblicato in un secondo tipo di istanza denominato Pubblica istanza da dove è accessibile agli utenti finali. Il terzo elemento costitutivo è il Dispatcher che è un modulo che gestisce la memorizzazione in cache e il filtro URL e viene installato sul server web. Per ulteriori informazioni sull’architettura AEM, consulta Scenari di implementazione tipici.

Micro Kernel

I micro kernel agiscono come gestori di persistenza in AEM. Esistono tre tipi di Micro Kernel 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 Micro Kernel, consulta la sezione Implementazioni consigliate pagina.

Nodestore

In AEM, i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. La posizione in cui vengono memorizzati i dati binari è indicata come Archiviazione dati, mentre la posizione dei nodi e delle proprietà del contenuto è denominata Archiviazione dei nodi.

Archiviazione dati

Quando si gestisce un numero elevato di binari, si consiglia di utilizzare un archivio dati esterno al posto degli archivi nodi predefiniti per massimizzare le prestazioni. Ad esempio, se il progetto richiede un numero elevato di risorse multimediali, memorizzarle nel file o nell’archivio dati di Azure/S3 renderà l’accesso più rapido rispetto all’archiviazione diretta all’interno di un MongoDB.

Per ulteriori dettagli sulle opzioni di configurazione disponibili, vedi Configurazione di nodi e archivi dati.

Ricerca

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

Linee guida per lo sviluppo

Si dovrebbe sviluppare per AEM mirare prestazioni e scalabilità. Di seguito sono riportate alcune best practice che puoi seguire:

ANNULLA

• Applicare la separazione di presentazione, logica e contenuto
• Utilizza le API AEM esistenti (ad esempio: Sling) e utensili (ad esempio: Replica)
• Sviluppare nel contesto dei contenuti effettivi
• Sviluppare una capacità di memorizzazione ottimale
• Riduci al minimo il numero di salvataggi (ad esempio: utilizzando flussi di lavoro transitori)
• Assicurati che tutti i punti finali HTTP siano RESTful
• Limitare il campo di applicazione dell'osservazione JCR
• Presta attenzione al thread asincrono

NON

• Non utilizzare direttamente le API JCR, se puoi

• Non modificare /libs, ma utilizzare le sovrapposizioni

• Non utilizzare le query laddove possibile

• Non utilizzare i binding Sling per ottenere i servizi OSGi nel codice Java, ma utilizza piuttosto:

  • @Riferimento in un componente DS
  • @Inserisci in un modello Sling
  • sling.getService() in una classe Sightly Use
  • sling.getService() in un JSP
  • a ServiceTracker
  • accesso diretto al registro del servizio OSGi

Per ulteriori dettagli sullo sviluppo su AEM, leggi Sviluppo - Nozioni di base. Per ulteriori best practice, consulta Tecniche consigliate per lo sviluppo.

Scenari di benchmark

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, leggi il campo Scenario dal Specifiche tecniche tabella.

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 di caricamento risorsa
• Modalità di esecuzione: utenti simultanei, interazione singola per utente

Scenario di prodotti misti

AEM Sites + Risorse:

• Interazioni utente su Sites: Pagina Leggi Articolo / Pagina Leggi / Crea Paragrafo / Modifica Paragrafo / Crea Pagina Contenuto / Attiva Pagina Contenuto / Ricerca Autore
• Interazioni utente delle risorse: Sfoglia risorse / Cerca risorse / Scarica risorsa / Leggi metadati risorsa / Aggiorna metadati risorsa / Carica risorsa / Esegui flusso di lavoro di caricamento risorsa
• Modalità di esecuzione: utenti simultanei, interazioni miste per utente

Scenario d'uso 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 risorsa (8.5%), Scarica risorsa (4,2%), Ricerca risorse (0,2%), Aggiorna metadati risorsa (2,4%), Carica risorse (1,2%), Sfoglia progetto (4,9%), Leggi progetto (6,6%), Progetto Aggiungi risorsa (1,2%), Progetto Aggiungi sito (1,2%), Crea progetto (0,1%), Ricerca autore (0,4%)
• Modalità di esecuzione: utenti simultanei, interazioni miste per utente

TarMK

Questo capitolo fornisce linee guida generali sulle prestazioni per TarMK che specificano i requisiti minimi di architettura e la configurazione delle impostazioni. Sono inoltre previste prove di riferimento per ulteriori chiarimenti.

Adobe consiglia a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di implementazione, sia per le istanze di authoring AEM che per quelle di pubblicazione.

Per ulteriori informazioni su TarMK, vedi Scenari di distribuzione e Archiviazione Tar.

Linee guida sull’architettura minima TarMK

Per stabilire 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 sull’architettura Tar per AEM Sites

Linee guida sull’architettura Tar per AEM Assets

Linee guida sulle impostazioni TarMK

Per ottenere prestazioni ottimali, segui le linee guida sulle impostazioni illustrate di seguito. Per istruzioni su come modificare le impostazioni, vedere questa pagina.

Benchmark delle prestazioni di TarMK

Specifiche tecniche

Le prove di riferimento sono state eseguite sulle seguenti specifiche:

Risultati del benchmark delle prestazioni

MongoMK

La ragione principale per scegliere il backend di persistenza MongoMK su TarMK è la scalabilità orizzontale delle istanze. Ciò significa che due o più istanze di authoring attive vengono sempre in esecuzione e utilizzano MongoDB come sistema di storage di persistenza. La necessità di eseguire più di un'istanza dell'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, vedi Scenari di distribuzione e Archiviazione Mongo.

Linee guida sull’architettura minima MongoMK

Per stabilire buone prestazioni quando si utilizza MongoMK, è necessario partire dalla seguente architettura:

• Tre istanze di authoring
• Due istanze di pubblicazione
• Tre istanze MongoDB
• Due dispatcher

Linee guida sulle impostazioni MongoMK

Per ottenere prestazioni ottimali, segui le linee guida sulle impostazioni illustrate di seguito. Per istruzioni su come modificare le impostazioni, vedere questa pagina.

Benchmark delle prestazioni MongoMK

Specifiche tecniche

Le prove di riferimento sono state eseguite sulle seguenti specifiche:

Risultati del benchmark delle prestazioni

TarMK vs MongoMK

La regola di base di cui tenere conto 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 implementazione, sia per le istanze di authoring AEM che per quelle di pubblicazione.

La ragione principale per scegliere il backend di persistenza MongoMK su TarMK è la scalabilità orizzontale delle istanze. Ciò significa che due o più istanze di authoring attive vengono sempre in esecuzione e utilizzano MongoDB come sistema di storage di persistenza. La necessità di eseguire più di un’istanza di authoring generalmente 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 maggiori dettagli su TarMK vs MongoMK, vedi Implementazioni 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 - vedi Standby a freddo per ulteriori dettagli
• Offre prestazioni elevate e un'archiviazione affidabile dei dati con costi operativi minimi
• TCO ridotto (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 ingestioni di risorse al giorno: a centinaia di migliaia o più
• Volume di modifiche alla pagina al giorno: a centinaia di migliaia o più
• Volume di ricerche al giorno: a decine di migliaia o più

Benchmark TarMK vs MongoMK

Scenario 1 Specifiche tecniche

Risultati del benchmark delle prestazioni dello scenario 1

Scenario 2 Specifiche tecniche

Risultati di 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 è l’architettura consigliata per la maggior parte dei clienti:

  • Topologia minima: un’istanza Author, due istanze Publish, due istanze Dispatcher
  • Replica senza binario attivata se File Datastore è condiviso

• MongoMK con archivio dati file è l’architettura consigliata per la scalabilità orizzontale del livello di authoring:

  • Topologia minima: tre istanze Autore, tre istanze MongoDB, due istanze Publish, due istanze Dispatcher
  • Replica senza binario attivata se File Datastore è condiviso

• Nodestore deve essere memorizzato sul disco locale, non su un NAS (Network Attached Storage)

• Quando utilizzi Amazon S3:

  • Il datastore Amazon S3 è condiviso tra il livello Author e Publish
  • La replica senza binario deve essere attivata
  • 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 preconfigurato 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, ad esempio, rimuovendo il passaggio video nel flusso di lavoro "Aggiorna risorsa", disabilitando gli ascoltatori che non vengono utilizzati, ecc.

Per ulteriori dettagli, consulta anche il Implementazioni consigliate pagina.

Risorse Business.Adobe.com

Multichannel Communication Auto Text Summarization Personalized Experiences Mobile Forms Dynamic Media Headless Cms