Linee guida per le dimensioni dell’hardware

Queste linee guida sul ridimensionamento offrono un'approssimazione delle risorse hardware necessarie per distribuire un progetto AEM. Le stime di dimensionamento dipendono dall'architettura del progetto, dalla complessità della soluzione, dal traffico previsto e dai requisiti del progetto. Questa guida consente di determinare le esigenze hardware di una soluzione specifica o di trovare una stima superiore e inferiore per i requisiti hardware.

I fattori di base da considerare sono (in questo ordine):

• Velocità di rete

  • Latenza della rete
  • Larghezza di banda disponibile

• Velocità computazionale

  • Efficienza della cache
  • Traffico previsto
  • Complessità di modelli, applicazioni e componenti
  • Autori simultanei
  • Complessità dell’operazione di authoring (semplice modifica dei contenuti, implementazione MSM ecc.)

• Prestazioni I/O

  • Prestazioni ed efficienza della memorizzazione del file o del database

• Unità disco rigido

  • almeno due o tre volte più grandi della dimensione del repository

• Memoria

  • Dimensione del sito Web (numero di oggetti-contenuto, pagine e utenti)
  • Numero di utenti/sessioni che sono attivi contemporaneamente

Architettura

Una tipica configurazione AEM consiste in un ambiente di authoring e pubblicazione. Questi ambienti presentano requisiti diversi per quanto riguarda le dimensioni hardware e la configurazione del sistema sottostanti. Considerazioni dettagliate per entrambi gli ambienti sono descritte nelle sezioni ambiente di authoring e ambiente di pubblicazione.

In una configurazione di progetto tipica, sono disponibili diversi ambienti in cui è possibile organizzare le fasi di progetto:

• Sviluppo
  dell'ambienteSviluppare nuove funzioni o apportare modifiche significative. La best practice consiste nell'utilizzare un ambiente di sviluppo per sviluppatore (in genere installazioni locali sui propri sistemi personali).

• Ambiente di test dell'autorePer verificare
  le modifiche. Il numero di ambienti di test può variare a seconda dei requisiti del progetto (ad esempio, separati per il controllo della qualità, il test di integrazione o il test di accettazione da parte dell'utente).

• Pubblica
  l’ambiente di provaPrincipalmente per testare i casi di utilizzo della collaborazione mediante social network e/o l’interazione tra l’autore e più istanze di pubblicazione.

• Ambiente di produzione
  dell'autoreConsente agli autori di modificare il contenuto.

• Pubblica
  ambiente di produzionePer distribuire il contenuto pubblicato.

Inoltre, gli ambienti possono variare, da un sistema a server singolo che esegue AEM e un server applicazione, a un set di istanze cluster multi-server e multi-CPU. È consigliabile utilizzare un computer separato per ciascun sistema di produzione e non eseguire altre applicazioni su questi computer.

Considerazioni generali sul ridimensionamento hardware

Le sezioni seguenti forniscono indicazioni su come calcolare i requisiti hardware, tenendo conto di varie considerazioni. Per i sistemi di grandi dimensioni, consigliamo di eseguire una semplice serie di test di benchmark interni su una configurazione di riferimento.

L'ottimizzazione delle prestazioni è un'attività fondamentale che deve essere eseguita prima che sia possibile eseguire il benchmarking per un progetto specifico. Prima di eseguire qualsiasi test di benchmark e di utilizzare i relativi risultati per qualsiasi calcolo del ridimensionamento hardware, assicurarsi di applicare i consigli forniti nella Documentazione sull'ottimizzazione delle prestazioni.

I requisiti di dimensionamento hardware per i casi di utilizzo avanzati devono essere basati su una valutazione dettagliata delle prestazioni del progetto. Le caratteristiche dei casi d'uso avanzati che richiedono risorse hardware eccezionali includono combinazioni di:

• payload/throughput ad alto contenuto
• uso esteso di codice personalizzato, flussi di lavoro personalizzati o librerie software di terze parti
• integrazione con sistemi esterni non supportati

Spazio su disco/Unità disco rigido

Lo spazio su disco richiesto dipende in larga misura dal volume e dal tipo dell'applicazione Web. I calcoli dovrebbero tener conto:

• la quantità e le dimensioni di pagine, risorse e altre entità memorizzate nel repository, come flussi di lavoro, profili ecc.
• la frequenza stimata delle modifiche dei contenuti e quindi la creazione di versioni dei contenuti
• il volume delle rappresentazioni delle risorse DAM che verranno generate
• la crescita complessiva del contenuto nel tempo

Lo spazio su disco viene monitorato continuamente durante la pulizia online e offline delle revisioni. Se lo spazio disponibile su disco scende al di sotto di un valore critico, il processo verrà annullato. Il valore critico è il 25% dell'attuale spazio su disco del repository e non è configurabile. Si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione del repository, inclusa la crescita stimata.

È consigliabile configurare array ridondanti di dischi indipendenti (RAID, ad esempio RAID10) per la ridondanza dei dati.

Virtualizzazione

AEM funziona bene in ambienti virtualizzati, ma ci possono essere fattori come CPU o I/O che non possono essere direttamente equiparati all'hardware fisico. Una raccomandazione consiste nel scegliere una velocità di I/O più elevata (in generale), in quanto questo è un fattore critico nella maggior parte dei casi. Per comprendere con precisione quali risorse saranno necessarie, è necessario eseguire il benchmarking del proprio ambiente.

Parallelizzazione delle istanze AEM

Sicurezza non corretta

Un sito Web sicuro per errore viene distribuito in almeno due sistemi separati. Se un sistema si rompe, un altro sistema può subentrare e quindi compensare il guasto del sistema.

Scalabilità delle risorse di sistema

Mentre tutti i sistemi sono in esecuzione, è disponibile un aumento delle prestazioni computazionali. che le prestazioni aggiuntive non sono necessariamente lineari con il numero di nodi del cluster, in quanto la relazione dipende fortemente dall'ambiente tecnico; per ulteriori informazioni, consultare la Documentazione cluster.

La stima del numero di nodi del cluster necessari si basa sui requisiti di base e sui casi di utilizzo specifici del progetto Web specifico:

• Dal punto di vista della sicurezza in caso di fallimento, è necessario determinare, per tutti gli ambienti, quanto sia critico il fallimento e il tempo di compensazione in caso di guasto in base al tempo necessario per il ripristino di un nodo del cluster.
• Per l'aspetto della scalabilità, il numero di operazioni di scrittura è sostanzialmente il fattore più importante; consultate Autori che lavorano in parallelo per l'ambiente di authoring e Social Collaboration per l'ambiente di pubblicazione. Il bilanciamento del carico può essere stabilito per le operazioni che accedono al sistema esclusivamente per il processo di lettura; per ulteriori informazioni, vedere Dispatcher.

Calcoli specifici dell'ambiente di authoring

A scopo di benchmarking, Adobe ha sviluppato alcuni test di benchmark per gli autori indipendenti.

• Benchmark test 1
  Consente di calcolare il throughput massimo di un profilo di carico in cui gli utenti eseguono un semplice esercizio di creazione della pagina oltre a un carico di base di 300 pagine esistenti tutte di natura simile. I passaggi necessari erano l’accesso al sito, la creazione di una pagina con un file SWF e un file immagine/testo, l’aggiunta di un tag cloud e l’attivazione della pagina.

  • ​
    Risultato: il throughput massimo per un semplice esercizio di creazione di pagine come sopra (considerato come una transazione) è stato rilevato come 1730 transazioni/ora.

• Test Benchmark 2
  Consente di calcolare il throughput massimo quando il profilo di carico presenta una combinazione di creazione di nuove pagine (10%), modifica di una pagina esistente (80%) e creazione e successiva modifica di una pagina in successione (10%). La complessità delle pagine rimane la stessa del profilo del test di benchmark 1. La modifica di base della pagina viene eseguita aggiungendo un'immagine e modificando il contenuto del testo. Anche in questo caso, l'esercizio è stato eseguito su un carico di base di 300 pagine della stessa complessità definita nel test di riferimento 1.

  • Il throughput
    ResultMaximum per uno scenario di operazione mix di questo tipo è risultato essere 3252 transazioni all'ora.

Le due prove di cui sopra evidenziano chiaramente che il throughput varia a seconda del tipo di operazione. Utilizzate le attività nell'ambiente come base per il ridimensionamento del sistema. Potrai ottenere un throughput migliore con azioni meno complesse come la modifica (anch’essa più comune).

Cache

Nell’ambiente di authoring, l’efficienza di memorizzazione nella cache è in genere molto inferiore, perché le modifiche al sito Web sono più frequenti e anche il contenuto è altamente interattivo e personalizzato. Utilizzando il dispatcher, potete memorizzare nella cache AEM librerie, JavaScript, file CSS e immagini di layout. Questo consente di velocizzare alcuni aspetti del processo di authoring. La configurazione del server Web per impostare intestazioni aggiuntive per il caching dei browser su queste risorse riduce il numero di richieste HTTP e migliora quindi la capacità di risposta del sistema, come sperimentato dagli autori.

Autori in parallelo

Nell’ambiente di authoring, il numero di autori che lavorano in parallelo e il caricamento delle loro interazioni aggiungono al sistema sono i principali fattori di limitazione. Pertanto, consigliamo di ridimensionare il sistema in base al flusso condiviso di dati.

Per tali scenari Adobe ha eseguito test di benchmark su un cluster di istanze dell'autore con elementi condivisi a due nodi.

• Test Benchmark 1
  aCon un cluster attivo-attivo shared-nothing di 2 istanze di autori, calcolare il throughput massimo con un profilo di carico in cui gli utenti eseguono un semplice esercizio di creazione di pagina oltre a un carico base di 300 pagine esistenti, il tutto di natura simile.

  • Il throughput
    massimo per un semplice esercizio di creazione delle pagine, come sopra, (considerato come una transazione) è risultato essere 2016 transazioni/ora. Si tratta di un aumento di circa il 16% rispetto a un'istanza di autore standalone per lo stesso test di benchmark.

• Test Benchmark 2
  bCon un cluster attivo-attivo shared-nothing di 2 istanze di creazione, calcolare il throughput massimo quando il profilo di caricamento include una combinazione di creazione di nuove pagine (10%), modifica di pagine esistenti (80%) e creazione e modifica di una pagina in successione (10%). La complessità della pagina rimane la stessa del profilo del test di benchmark 1. La modifica di base della pagina viene eseguita aggiungendo un'immagine e modificando il contenuto del testo. Anche in questo caso, l'esercizio è stato eseguito su un carico di base di 300 pagine di complessità, come definito nel test di riferimento 1.

  • Il throughput
    ResultMaximum per uno scenario di operazione mista è risultato essere 6288 transazioni/ora. Si tratta di un aumento di circa il 93% rispetto a un'istanza di autore standalone per lo stesso test di benchmark.

I due test di cui sopra evidenziano chiaramente che la AEM viene ridimensionata correttamente per gli autori che eseguono operazioni di modifica di base con AEM. In generale, AEM è più efficace nel ridimensionare le operazioni di lettura.

In un sito Web tipico, la maggior parte delle operazioni di authoring avviene durante la fase di progettazione. Dopo che il sito Web è attivo, il numero di autori che lavorano in parallelo passa solitamente a una media inferiore (modalità operativa).

Potete calcolare il numero di computer (o CPU) necessari per l’ambiente di authoring come segue:

n = numberOfParallelAuthors / 30

Questa formula può essere utilizzata come linea guida generale per ridimensionare le CPU quando gli autori eseguono operazioni di base con AEM. Si presuppone che il sistema e l'applicazione siano ottimizzati. Tuttavia, la formula non rimarrà valida per le funzioni avanzate come MSM o Assets (vedere le sezioni seguenti).

Consultare anche i commenti aggiuntivi su Parallelizzazione e Ottimizzazione prestazioni.

Recommendations hardware

In genere, per l’ambiente di authoring è possibile utilizzare lo stesso hardware consigliato per l’ambiente di pubblicazione. In genere, il traffico dei siti Web è molto inferiore nei sistemi di authoring, ma anche l’efficienza della cache è inferiore. Tuttavia, il fattore fondamentale in questo caso è il numero di autori che lavorano in parallelo, insieme al tipo di azioni che vengono intraprese per il sistema. In generale AEM cluster (dell'ambiente di authoring) è più efficace nel scalare le operazioni di lettura; in altre parole, un cluster AEM può essere ridimensionato in modo ottimale con gli autori che eseguono operazioni di modifica di base.

I test di benchmark Adobe sono stati eseguiti utilizzando il sistema operativo RedHat 5.5, eseguito su una piattaforma hardware Hewlett-Packard ProLiant DL380 G5 con la seguente configurazione:

• Due CPU Intel Xeon X5450 quad-core a 3,00 GHz
• 8 GB di RAM
• Broadcom NetXtreme II BCM5708 Gigabit Ethernet
• Controller RAID Smart Array HP, 256 MB di cache
• Due dischi SAS da 146 GB e 10.000 rpm configurati come set a strisce RAID0
• SPEC CINT2006 Il punteggio di riferimento del tasso è 110

AEM istanze venivano eseguite con una dimensione di heap minima di 256M, con una dimensione massima di 1024M.

Calcoli specifici dell'ambiente di pubblicazione

Efficienza della cache e traffico

L'efficienza della cache è fondamentale per la velocità del sito Web. La tabella seguente mostra il numero di pagine al secondo che un sistema AEM ottimizzato può gestire utilizzando un proxy inverso, come il dispatcher:

Il rapporto della cache è la percentuale di pagine che il dispatcher può restituire senza dover accedere AEM. 100% indica che il dispatcher risponde a tutte le richieste, 0% indica che AEM calcolare ogni singola pagina.

Complessità di modelli e applicazioni

Se utilizzate modelli complessi AEM sarà necessario più tempo per eseguire il rendering di una pagina. Le pagine estratte dalla cache non sono interessate da questo problema, ma la dimensione della pagina è comunque pertinente quando si considera il tempo di risposta complessivo. Il rendering di una pagina complessa può richiedere dieci volte più tempo del rendering di una pagina semplice.

Formula

Utilizzando la seguente formula, potete calcolare una stima della complessità complessiva della soluzione AEM:

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

In base alla complessità, potete determinare il numero di server (o core CPU) necessari per l’ambiente di pubblicazione come segue:

n = (traffic * complexity / 1000 ) * activations

Le variabili dell'equazione sono le seguenti:

Se disponete di un sito Web più complesso, avete anche bisogno di server Web più potenti in modo che AEM rispondere a una richiesta in un momento accettabile.

• Complessità inferiore a 4:
  ・ 1024 MB di RAM JVM*
  ・ CPU a prestazioni ridotte o medie

• Complessità tra 4 e 8:
  ・ 2048 MB di RAM JVM*
  ・ CPU mid-to high performance

• Complessità superiore a 8:
  ・ 4096 MB di RAM JVM*
  CPU ad alte prestazioni

Calcoli aggiuntivi specifici per casi d'uso

Oltre al calcolo per un'applicazione Web predefinita, potrebbe essere necessario considerare fattori specifici per i seguenti casi d'uso. I valori calcolati devono essere aggiunti al calcolo predefinito.

Considerazioni specifiche per le risorse

L'ampia elaborazione delle risorse digitali richiede risorse hardware ottimizzate, i fattori più importanti sono la dimensione delle immagini e il volume di elaborazione delle immagini.

Assegnate almeno 16 GB di heap e configurate il flusso di lavoro DAM Update Asset per utilizzare il pacchetto Camera Raw per l'assimilazione di immagini non elaborate.

Multi-Site Manager

Il consumo di risorse quando si utilizza AEM MSM in un ambiente di authoring dipende in larga misura dai casi di utilizzo specifici. I fattori di base sono:

• Numero di Live-Copy
• Periodicità dei rollout
• Dimensione della struttura del contenuto da distribuire
• Funzionalità collegata delle azioni di rollout

La verifica del caso di utilizzo pianificato con un estratto di contenuto rappresentativo può facilitare la comprensione del consumo delle risorse. Se si estrapolano i risultati con il throughput pianificato, è possibile valutare le risorse aggiuntive necessarie per l'MSM AEM.

Si prega inoltre di tenere in considerazione che gli autori che lavorano in parallelo percepiranno effetti collaterali delle prestazioni se AEM casi d'uso MSM consumano più risorse di quanto pianificato.

considerazioni sul ridimensionamento AEM Communities

AEM siti che includono funzioni AEM Communities (siti community) sperimentano un elevato livello di interazione da parte dei visitatori (membri) del sito nell’ambiente di pubblicazione.

Le considerazioni relative al ridimensionamento di un sito community dipendono dall'interazione prevista dai membri della community e dalla maggiore importanza che rivestono le prestazioni ottimali per il contenuto della pagina.

I membri inviati del contenuto generato dall'utente (UGC) vengono memorizzati separatamente dal contenuto della pagina. Mentre la piattaforma AEM utilizza un archivio nodi che replica il contenuto del sito dall'autore alla pubblicazione, AEM Communities utilizza un singolo archivio comune per UGC che non viene mai replicato.

Per lo store UGC, è necessario scegliere un provider di risorse di storage (SRP), che influenza la distribuzione scelta.
Consulta

• Memorizzazione dei contenuti community
• Topologie consigliate per community