Linee guida sulle prestazioni

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

Bordo

Destinazione

Risorse

Publish-HA

Solaris™

WebLogic

IBM®

SAML

MongoDB

File

Lucene

IIS

IE

Analytics

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

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

NOTA

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

Quando utilizzare le linee guida sulle prestazioni

Utilizzare le linee guida sulle prestazioni nelle situazioni seguenti:

  • Prima implementazione: quando pianifichi la prima distribuzione di AEM Sites o Assets, è 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: quando si esegue 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 tuoi 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, comprendi 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 i tuoi 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 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:

chlimage_1

Per maggiori informazioni sulla piattaforma AEM, vedi Cos’è l’AEM.

Architettura dell’AEM

L’attuazione dell’AEM si basa su tre importanti elementi costitutivi. Il Istanza autore che viene utilizzato 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 Pubblica istanza dal punto in cui gli utenti finali vi accedono. Il terzo elemento costitutivo è il Dispatcher modulo che gestisce il caching e il filtro URL ed è installato sul server web. Per ulteriori informazioni sull’architettura dell’AEM, consulta Scenari di implementazione tipici.

chlimage_1-1

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 Distribuzioni consigliate pagina.

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 di contenuto e delle proprietà è denominata Archivio nodi.

NOTA

L’Adobe consiglia di utilizzare TarMK come tecnologia di persistenza predefinita utilizzata dai clienti sia per le istanze AEM Author che per quelle Publish.

ATTENZIONE

Il supporto del micro kernel del database relazionale è limitato. Contatto Assistenza clienti Adobe prima di utilizzare questo tipo di micro kernel.

chlimage_1-3

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, vedi Configurazione di nodi e archivi dati.

NOTA

L’Adobe consiglia di scegliere l’opzione di distribuzione dell’AEM in Azure o Amazon Web Services (AWS) tramite Adobe Managed Services. I clienti traggono vantaggio da un team con l’esperienza e le competenze necessarie per implementare e utilizzare AEM in questi ambienti di cloud computing. Consulta documentazione aggiuntiva su Adobe Managed Services.

Per raccomandazioni su come distribuire AEM in Azure o AWS, al di fuori di Adobe Managed Services, l’Adobe consiglia di lavorare direttamente con il provider cloud. Oppure, collabora con uno dei partner di Adobe che supportano l’implementazione dell’AEM nell’ambiente cloud desiderato. Il provider cloud o partner selezionato è responsabile delle specifiche di dimensionamento, della progettazione e dell'implementazione dell'architettura supportata per soddisfare requisiti specifici di prestazioni, carico, scalabilità e sicurezza.
Consulta anche requisiti tecnici pagina.

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 l’AEM con l’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 utilizza le sovrapposizioni

  • Non utilizzare le query dove possibile

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

    • @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 maggiori dettagli sullo sviluppo dell'AEM, vedi Sviluppo - Nozioni di base. Per ulteriori best practice, consulta Best practice per lo sviluppo.

Scenari di benchmark

NOTA

Tutti i test di benchmark mostrati in questa pagina sono stati eseguiti in laboratorio.

Gli scenari di test dettagliati di seguito sono utilizzati per le sezioni di benchmark dei capitoli TarMK, MongoMk e TarMK vs MongoMk. Per vedere quale scenario è stato utilizzato per un particolare test di benchmark, leggere il campo Scenario dalla sezione Specifiche tecniche tabella.

Scenario con un singolo prodotto

AEM Assets:

  • Interazioni utente: sfogliare le risorse / cercare le risorse / scaricare le risorse / leggere i metadati delle risorse / aggiornare i metadati delle risorse / caricare le risorse / eseguire il flusso di lavoro di caricamento delle risorse
  • 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 utente di Assets: sfogliare le risorse/cercare le risorse/scaricare le risorse/leggere i metadati delle risorse/aggiornare i metadati delle risorse/caricare le risorse/eseguire il flusso di lavoro di caricamento delle risorse
  • Modalità di esecuzione: utenti simultanei, interazioni miste per utente

Scenario del caso d’uso verticale

File 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 AEM Author che per quelle Publish.

Per ulteriori informazioni su TarMK, consulta Scenari di implementazione e Archiviazione Tar.

Linee guida sull’architettura minima di TarMK

NOTA

Le linee guida dell’architettura minima presentate di seguito si riferiscono agli ambienti di produzione e ai siti con traffico elevato. Queste linee guida sono non il specifiche minime per il funzionamento dell'AEM.

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

  • Un’istanza Autore
  • Due istanze di pubblicazione
  • Due dispatcher

Di seguito sono illustrate le linee guida sull’architettura dei siti AEM e AEM Assets.

NOTA

È necessario attivare la replica senza binario ATTIVATO se l’archivio dati file è 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 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, vedi questa pagina.

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

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

Vero

Per evitare che query estese sovraccarichi i sistemi, aggiungi questi parametri JVM nello script iniziale dell’AEM.
Configurazione dell’indice Lucene

CopyOnRead

CopyOnWrite

Prefetch Index Files

Abilitato

Abilitato

Abilitato

Per maggiori dettagli sui parametri disponibili, vedi questa pagina.
Archivio dati = Archivio dati S3

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) o inferiore

2-10% della dimensione heap massima

Vedi 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 il write-back dell’XMP nel file binario originale e imposta la data dell’ultima modifica in JCR.

Benchmark delle prestazioni TarMK

Specifiche tecniche

I test di riferimento sono stati eseguiti sulle seguenti specifiche:

Nodo Author
Server Hardware Bare Metal (HP)
Sistema operativo Red Hat® Linux®
CPU/core CPU Intel® Xeon® E5-2407 @2.40GHz, 8 core
RAM 32 GB
Disco Magnetico
Java™ Oracle JRE versione 8
Heap JVM 16 GB
Prodotto AEM 6.2
Nodestore TarMK
Archivio dati DS file
Scenario Singolo prodotto: Assets / 30 thread simultanei

Risultati benchmark prestazioni

NOTA

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

chlimage_1-7 chlimage_1-8

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, consulta Scenari di implementazione 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 pubblicazione
  • Tre istanze MongoDB
  • Due dispatcher
NOTA

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

NOTA

È necessario attivare la replica senza binario ATTIVATO se l’archivio dati file è condiviso.

chlimage_1-9

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

Impostazione Parametro Valore (predefinito) Descrizione
Code processi Sling queue.maxparallel Impostare il valore su metà del numero di core della CPU. Per impostazione predefinita, il numero di thread simultanei per coda processi è uguale al numero di core CPU.
Coda del flusso di lavoro transitorio Granite Max Parallel Impostare il valore su 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

Per evitare che query estese sovraccarichi i sistemi, aggiungi questi parametri JVM nello script iniziale dell’AEM.
Configurazione dell’indice Lucene

CopyOnRead

CopyOnWrite

Prefetch Index Files

Abilitato

Abilitato

Abilitato

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

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) o inferiore

2-10% della dimensione heap massima

Vedi anche Configurazioni archivio dati.
DocumentNodeStoreService

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.

osservazione oak

thread pool

length

min e max = 20

50000

Benchmark delle prestazioni MongoMK

Specifiche tecniche

I test di riferimento sono stati eseguiti sulle seguenti specifiche:

Nodo Author Nodo MongoDB
Server Hardware Bare Metal (HP) Hardware Bare Metal (HP)
Sistema operativo Red Hat® Linux® Red Hat® Linux®
CPU/core CPU Intel® Xeon® E5-2407 @2.40GHz, 8 core CPU Intel® Xeon® E5-2407 @2.40GHz, 8 core
RAM 32 GB 32 GB
Disco Magnetico - >1.000 IOPS Magnetico - >1.000 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
Archivio dati DS file N/D
Scenario Singolo prodotto: Assets / 30 thread simultanei Singolo prodotto: Assets / 30 thread simultanei

Risultati benchmark prestazioni

NOTA

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

chlimage_1-10 chlimage_1-11

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 AEM Author che per quelle 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 maggiori dettagli su TarMK vs 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. Vedere Standby a freddo per ulteriori dettagli
  • 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

NOTA

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

Scenario 1 - Specifiche tecniche

Crea nodo OAK Nodo MongoDB
Server Hardware Bare Metal (HP) Hardware Bare Metal (HP)
Sistema operativo Red Hat® Linux® Red Hat® Linux®
CPU/core CPU Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 core CPU Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 core
RAM 32 GB 32 GB
Disco Magnetico - >1.000 IOPS Magnetico - >1.000 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
Archivio dati DS file N/D
Scenario


Prodotto singolo: Assets / 30 thread simultanei per esecuzione

Risultati del benchmark delle prestazioni dello 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 un numero di autori pari a 1,8 volte quello di un’istanza TarMK. Un cluster MongoDB a otto nodi può gestire un numero di autori 2,3 volte superiore a quello di un’istanza TarMK.

Nodo Author TarMK Nodo MongoMK dell’autore Nodo MongoDB
Server AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
Sistema operativo Red Hat® Linux® Red Hat® Linux® Red Hat® Linux®
CPU/core 32 32 32
RAM 60 GB 60 GB 60 GB
Disco SSD - IOPS 10.000 SSD - IOPS 10.000 SSD - IOPS 10.000
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
Archivio dati DS file
DS file

N/D
Scenario



Caso di utilizzo verticale: thread simultanei Media/2000

Risultati del benchmark delle prestazioni dello 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 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 - Archiviazione su disco locale, non 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
  • È necessario creare un indice personalizzato oltre a quello 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 : rimuovi il passaggio video nel flusso di lavoro "Aggiorna risorsa", disabilitando i listener non utilizzati e così via.

Per ulteriori dettagli, consulta anche Distribuzioni consigliate pagina.

In questa pagina