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:

Di seguito sono illustrate le opzioni di distribuzione disponibili per AEM (scorri per visualizzare tutte le opzioni):

AEM

Prodotto

Topologia

Sistema operativo

Server applicazioni

JRE

Sicurezza

Micro Kernel

Datastore

Indicizzazione

Server web

Browser

Marketing Cloud

Sites

Non HA

Windows

CQSE

Oracle

LDAP

Tar

Segmento

Proprietà

Apache

Bordo

Target

Assets

Publish-HA

Solaris

WebLogic

IBM

SAML

MongoDB

File

Lucene

IIS

IE

Analytics

Communities

Autore-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

Autore-cluster

IBM AIX

JBoss

RDB/MySQL

RDBMS

Safari

Pubblico

Sito multiplo

ASRP

SOSPENDERE

RDB/SQLServer

Risorse

Commerce

MSRP

Sistema operativo Apple

Attivazione

Dynamic Media

JSRP

Mobile

Brand Portal

J2E

AoD

LiveFyre

Screens

Sicurezza dei documenti

Mgt del processo

App desktop

NOTA

Le linee guida sulle prestazioni si applicano principalmente ad AEM Sites.

Quando utilizzare le linee guida sulle prestazioni

Utilizza le linee guida sulle prestazioni nelle situazioni seguenti:

  • Prima distribuzione: 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 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:

chlimage_1

Per ulteriori informazioni sulla piattaforma AEM, consulta AEM.

Architettura AEM

Sono disponibili tre importanti elementi di base per una distribuzione AEM. L’ Istanza autore viene utilizzata da autori di contenuti, editor e approvatori 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 vi accedono. Il terzo blocco predefinito è il Dispatcher, un modulo che gestisce la memorizzazione in cache e il filtro URL e che viene installato sul server web. Per ulteriori informazioni sull'architettura AEM, vedere Scenari di distribuzione tipici.

chlimage_1-1

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, vedere la pagina Implementazioni consigliate.

chlimage_1-2

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 Archivio dati, mentre la posizione dei nodi e delle proprietà di contenuto è denominata Archivio nodi.

NOTA

Adobe consiglia a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti sia per le istanze di authoring AEM che per quelle di pubblicazione.

ATTENZIONE

Supporto limitato per il Micro Kernel del database relazionale. Contatta l' Adobe Customer Care prima di utilizzare questo tipo di Micro Kernel.

chlimage_1-3

Archivio 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, consulta Configurazione del nodo e degli archivi dati.

NOTA

Adobe consiglia di scegliere l’opzione di distribuire AEM su Azure o Amazon Web Services (AWS) utilizzando Adobe Managed Services, in cui i clienti potranno beneficiare di un team che dispone dell’esperienza e delle competenze necessarie per distribuire e operare AEM in questi ambienti cloud computing. Consulta la nostra documentazione aggiuntiva su Adobe Managed Services.

Per raccomandazioni 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 per supportare la distribuzione di AEM nell’ambiente cloud desiderato. Il fornitore o partner cloud selezionato è responsabile delle specifiche di dimensionamento, della progettazione e dell'implementazione dell'architettura che supporterà per soddisfare i requisiti specifici di prestazioni, carico, scalabilità e sicurezza.

Per ulteriori dettagli, consulta anche la pagina requisiti tecnici .

Ricerca

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

NOTA

Per la maggior parte delle distribuzioni, Adobe consiglia di utilizzare l'Indice Lucene. Utilizza Solr solo per la scalabilità in implementazioni specializzate e complesse.

chlimage_1-4

Linee guida per lo sviluppo

Sviluppare per AEM mirare a 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 di in AEM, leggi Sviluppo - Nozioni di base. Per ulteriori best practice, consulta Best practice per lo sviluppo.

Scenari di benchmark

NOTA

Tutti i test di riferimento visualizzati in questa pagina sono stati eseguiti in un ambiente di 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, leggi il campo Scenario dalla tabella Specifiche tecniche .

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, consulta Scenari di distribuzione e Tar Storage.

Linee guida sull'architettura minima TarMK

NOTA

Le linee guida di architettura minima presentate di seguito sono per gli ambienti di produzione e i siti a traffico elevato. Si tratta di non le specifiche minime necessarie per eseguire AEM.

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.

NOTA

La replica senza binario deve essere attivata ON se il file Datastore è condiviso.

Linee guida sull’architettura Tar per AEM Sites

chlimage_1-5

Linee guida sull’architettura Tar per AEM Assets

chlimage_1-6

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, consulta questa pagina.

Impostazione Parametro Valore Descrizione
Code di lavoro Sling queue.maxparallel Imposta il valore a metà del numero di core della CPU. Per impostazione predefinita, il numero di thread simultanei per coda di lavoro è uguale al numero di core della CPU.
Coda flusso di lavoro transitorio di Granite Max Parallel Imposta il valore a metà del numero di core della CPU
Parametri JVM

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

Vero

Aggiungi questi parametri JVM nello script di avvio AEM per evitare che le query espansive sovraccarichino i sistemi.
Configurazione dell'indice Lucene

CopyOnRead

CopyOnWrite

Prefetch Index Files

Abilitato

Abilitato

Abilitato

Per ulteriori dettagli sui parametri disponibili, consulta questa pagina.
Archivio dati = Datastore S3

maxCachedBinarySize

cacheSizeInMB

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 write-back del binario originale e imposta l'ultima data modificata in JCR.

Benchmark delle prestazioni di TarMK

Specifiche tecniche

Le prove di riferimento sono state eseguite sulle seguenti specifiche:

Nodo autore
Server Hardware a metallo nudo (HP)
Sistema operativo RedHat Linux
CPU/core CPU Intel® Xeon® 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

Risultati del benchmark delle prestazioni

NOTA

I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri effettivi della velocità effettiva.

chlimage_1-7 chlimage_1-8

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, consulta Scenari di distribuzione e Mongo Storage.

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
NOTA

Negli ambienti di produzione, MongoDB verrà sempre utilizzato come set di repliche con un database primario e due secondari. Le letture e le scritture vanno al primo e le letture possono andare ai secondi. Se lo spazio di archiviazione non è disponibile, è possibile sostituire uno dei secondari con un arbitro, ma i set di repliche MongoDB devono sempre essere composti da un numero dispari di istanze.

NOTA

La replica senza binario deve essere attivata ON se il file Datastore è condiviso.

chlimage_1-9

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, consulta questa pagina.

Impostazione Parametro Valore (predefinito) Descrizione
Code di lavoro Sling queue.maxparallel Imposta il valore a metà del numero di core della CPU. Per impostazione predefinita, il numero di thread simultanei per coda di lavoro è uguale al numero di core della CPU.
Coda flusso di lavoro transitorio di Granite Max Parallel Imposta il valore a metà del numero di core della CPU.
Parametri JVM

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

Vero

60000

Aggiungi questi parametri JVM nello script di avvio AEM per evitare che le query espansive sovraccarichino i sistemi.
Configurazione dell'indice Lucene

CopyOnRead

CopyOnWrite

Prefetch Index Files

Abilitato

Abilitato

Abilitato

Per ulteriori dettagli sui parametri disponibili, consulta questa pagina.
Archivio dati = Datastore S3

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) o inferiore

2-10% della dimensione massima dell'heap

Vedere anche Configurazioni archivio dati.
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

35 (25)

20 (10)

30

(3)

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

thread pool

length

min & max = 20

50000

Benchmark delle prestazioni MongoMK

Specifiche tecniche

Le prove di riferimento sono state eseguite sulle seguenti specifiche:

Nodo autore Nodo MongoDB
Server Hardware a metallo nudo (HP) Hardware a metallo nudo (HP)
Sistema operativo RedHat Linux RedHat Linux
CPU/core CPU Intel® Xeon® E5-2407 @2,40 GHz, 8 core CPU Intel® Xeon® E5-2407 @2,40 GHz, 8 core
RAM 32 GB 32 GB
Disco Magnetico - >1k IOPS Magnetico - >1k 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

Risultati del benchmark delle prestazioni

NOTA

I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono i numeri effettivi della velocità effettiva.

chlimage_1-10 chlimage_1-11

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 ulteriori dettagli su TarMK e MongoMK, consulta Implementazioni consigliate.

Linee guida TarMK vs MongoMk

Vantaggi di TarMK

  • Progettato per 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 informazioni, vedere Standby a freddo
  • 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

NOTA

I numeri riportati di seguito sono stati normalizzati a 1 come linea di base e non sono numeri effettivi del throughput.

Scenario 1 Specifiche tecniche

Nodo OAK autore Nodo MongoDB
Server Hardware a metallo nudo (HP) Hardware a metallo nudo (HP)
Sistema operativo RedHat Linux RedHat Linux
CPU/core CPU Intel(R) Xeon(R) E5-2407 @2,40 GHz, 8 core CPU Intel(R) Xeon(R) E5-2407 @2,40 GHz, 8 core
RAM 32 GB 32 GB
Disco Magnetico - >1k IOPS Magnetico - >1k IOPS
Java Oracle JRE versione 8 N/D
Heap JVM da 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


Prodotto singolo: Risorse / 30 thread simultanei per esecuzione

Risultati benchmark prestazioni scenario 1

chlimage_1-12

Scenario 2 Specifiche tecniche

NOTA

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.

Nodo TarMK autore Nodo MongoMK autore 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.000 IOPS SSD - 10.000 IOPS SSD - 10.000 IOPS
Java Oracle JRE versione 8
Oracle JRE versione 8
N/D
Heap JVM da 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



Caso di utilizzo verticale: Thread simultanei di Media / 2000

Risultati benchmark prestazioni scenario 2

chlimage_1-13

Linee guida per la scalabilità dell’architettura per AEM Sites e Assets

chlimage_1-14

Riepilogo delle linee guida sulle prestazioni

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:

    • Topologia minima: un’istanza Author, due istanze Publish, due istanze Dispatcher
    • Replica senza binario attivata se File Datastore è condiviso
  • MongoMK con File Datastoreè 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
  • ​I nodi devono essere memorizzati sul disco locale, non su uno storage NAS (Network Attached Storage).

  • Quando si utilizza 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 la pagina Implementazioni consigliate .

In questa pagina

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now