Diretrizes de desempenho

ATENÇÃO

AEM 6.4 chegou ao fim do suporte estendido e esta documentação não é mais atualizada. Para obter mais detalhes, consulte nossa períodos de assistência técnica. Encontre as versões compatíveis here.

Esta página fornece diretrizes gerais sobre como otimizar o desempenho da implantação do AEM. Se você não AEM, passe o mouse sobre as seguintes páginas antes de começar a ler as diretrizes de desempenho:

Ilustradas abaixo estão as opções de implantação disponíveis para AEM (rolar para exibir todas as opções):

AEM

Produto

Topologia

Sistema Operacional

Servidor de aplicativos

JRE

Segurança

Micro kernel

Armazenamento de dados

Indexação

Servidor Web

Navegador

Marketing Cloud

Sites

Não-HA

Windows

CQSE

Oracle

LDAP

Tar

Segmento

Propriedade

Apache

Edge

Destino

Assets

Publicar-HA

Solaris

WebLogic

IBM

SAML

MongoDB

Arquivo

Lucene

IIS

IE

Analytics

Communities

Autor-CS

Chapéu Vermelho

WebSphere

HP

Oauth

RDB/Oracle

S3/Azure

Solr

iPlanet

FireFox

Campaign

Forms

Author-Offload

HP-UX

Tomcat

RDB/DB2

MongoDB

Chrome

Social

Móvel

Cluster de Autores

IBM AIX

JBoss

RDB/MySQL

RDBMS

Safari

Público

Vários sites

ASRP

SUSE

RDB/SQLServer

Assets

Commerce

MSRP

Apple OS

Ativação

Dynamic Media

JSRP

Móvel

Brand Portal

J2E

AoD

LiveFyre

Screens

Segurança de documento

Gerenciamento de processos

Aplicativo de desktop do

OBSERVAÇÃO

As diretrizes de desempenho se aplicam principalmente ao AEM Sites.

Quando utilizar as diretrizes de desempenho

Você deve usar as diretrizes de desempenho nas seguintes situações:

  • Implantação pela primeira vez: Ao planejar a implantação do AEM Sites ou do Assets pela primeira vez, é importante entender as opções disponíveis ao configurar o Micro Kernel, a Loja de nós e a Loja de dados (em comparação com as configurações padrão). Por exemplo, alterar as configurações padrão do Data Store para TarMK para File Data Store.
  • Atualização para uma nova versão: Ao atualizar para uma nova versão, é importante entender as diferenças de desempenho em comparação ao ambiente em execução. Por exemplo, atualização do AEM 6.1 para 6.2 ou do AEM 6.0 CRX2 para 6.2 OAK.
  • O tempo de resposta é lento: Quando a arquitetura do Nodestore selecionada não estiver atendendo aos seus requisitos, é importante compreender as diferenças de desempenho em comparação com outras opções de topologia. Por exemplo, implantar o TarMK em vez do MongoMK ou usar um File Data Store em vez de um Amazon S3 ou Microsoft Azure Data Store.
  • Adicionar mais autores: Quando a topologia TarMK recomendada não atende aos requisitos de desempenho e o redimensionamento do nó Autor atingiu a capacidade máxima disponível, é importante entender as diferenças de desempenho em comparação ao uso do MongoMK com três ou mais nós Autor. Por exemplo, implantar MongoMK em vez de TarMK.
  • Adicionar mais conteúdo: Quando a arquitetura recomendada do Data Store não atender aos seus requisitos, é importante compreender as diferenças de desempenho em comparação com outras opções do Data Store. Exemplo: usando o Amazon S3 ou o Microsoft Azure Data Store em vez de um File Data Store.

Introdução

Este capítulo fornece uma visão geral da arquitetura de AEM e seus componentes mais importantes. Ele também fornece diretrizes de desenvolvimento e descreve os cenários de teste usados nos testes de benchmark TarMK e MongoMK.

A plataforma AEM

A plataforma de AEM consiste nos seguintes componentes:

chlimage_1

Para obter mais informações sobre a plataforma de AEM, consulte O que é AEM.

A arquitetura AEM

Há três blocos fundamentais importantes para uma implantação de AEM. O Instância do autor , que é usada por autores, editores e aprovadores de conteúdo para criar e revisar conteúdo. Quando o conteúdo é aprovado, ele é publicado em um segundo tipo de instância chamado de Instância de publicação de onde é acessado pelos usuários finais. O terceiro bloco de construção é o Dispatcher que é um módulo que lida com o armazenamento em cache e a filtragem de URL e é instalado no servidor da Web. Para obter mais informações sobre a arquitetura de AEM, consulte Cenários típicos de implantação.

chlimage_1-1

Micro Kernels

Micro Kernels atuam como gerentes de persistência em AEM. Existem três tipos de Micro Kernels usados com AEM: TarMK, MongoDB e Banco de Dados Relacional (sob suporte restrito). Escolher um para atender às suas necessidades depende da finalidade da sua instância e do tipo de implantação que você está considerando. Para obter mais informações sobre Micro Kernels, consulte o Implantações recomendadas página.

chlimage_1-2

Nodestore

No AEM, os dados binários podem ser armazenados independentemente dos nós de conteúdo. O local onde os dados binários são armazenados é chamado de Armazenamento de dados, enquanto a localização dos nós e propriedades de conteúdo é chamada de Loja de nós.

OBSERVAÇÃO

O Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes para as instâncias de Autor do AEM e Publicação.

ATENÇÃO

O Micro Kernel do Banco de Dados Relacional está sob suporte restrito. Contato Atendimento ao cliente do Adobe antes de usar esse tipo de Micro Kernel.

chlimage_1-3

Armazenamento de dados

Ao lidar com um grande número de binários, é recomendável usar um armazenamento de dados externo em vez dos armazenamentos de nó padrão para maximizar o desempenho. Por exemplo, se o projeto exigir um grande número de ativos de mídia, armazená-los no Arquivo ou no Data Store do Azure/S3 fará com que o acesso seja mais rápido do que armazená-los diretamente em um MongoDB.

Para obter mais detalhes sobre as opções de configuração disponíveis, consulte Configuração de nós e armazenamentos de dados.

OBSERVAÇÃO

O Adobe recomenda escolher a opção de implantar AEM no Azure ou no Amazon Web Services (AWS) usando o Adobe Managed Services, onde os clientes se beneficiarão de uma equipe que tem a experiência e as habilidades de implantar e operar AEM nesses ambientes de computação em nuvem. Consulte a documentação adicional sobre o Adobe Managed Services.

Para recomendações sobre como implantar AEM no Azure ou no AWS, fora do Adobe Managed Services, recomendamos trabalhar diretamente com o provedor de nuvem ou um de nossos parceiros que oferecem suporte à implantação do AEM no ambiente de nuvem de sua escolha. O provedor ou parceiro de nuvem selecionado é responsável pelas especificações de dimensionamento, pelo design e pela implementação da arquitetura que ele oferecerá suporte para atender aos requisitos específicos de desempenho, carga, escalabilidade e segurança.

Para obter detalhes adicionais, consulte também a seção requisitos técnicos página.

Pesquisar

Listados nesta seção são os provedores de índice personalizados usados com o AEM. Para saber mais sobre indexação, consulte Consultas e indexação do Oak.

OBSERVAÇÃO

Para a maioria das implantações, o Adobe recomenda o uso do Índice Lucene. Você deve usar o Solr somente para escalabilidade em implantações especializadas e complexas.

chlimage_1-4

Diretrizes de desenvolvimento

Você deve desenvolver AEM com o objetivo de desempenho e escalabilidade. Apresentamos abaixo uma série de práticas recomendadas que podem ser seguidas:

DO

  • Aplicar separação de apresentação, lógica e conteúdo
  • Use APIs AEM existentes (por exemplo: Sling) e ferramentas (ex: Replicação)
  • Desenvolver no contexto do conteúdo real
  • Desenvolver para otimizar a capacidade de armazenamento em cache
  • Minimize o número de salvamentos (por exemplo: ao usar workflows transitórios)
  • Certifique-se de que todos os pontos finais HTTP sejam RESTful
  • Restringir o escopo da observação do JCR
  • Considere o encadeamento assíncrono

NÃO

  • Não use APIs JCR diretamente, se você puder

  • Não altere /libs, mas use sobreposições

  • Não use consultas sempre que possível

  • Não use o Sling Bindings para obter serviços OSGi no código Java, mas use:

    • @Reference em um componente DS
    • @Inject em um Modelo Sling
    • sling.getService() em uma Classe de Uso Sightly
    • sling.getService() em um JSP
    • um ServiceTracker
    • acesso direto ao registro do serviço OSGi

Para obter mais detalhes sobre o desenvolvimento no AEM, leia Desenvolvimento - Noções básicas. Para obter mais práticas recomendadas, consulte Práticas recomendadas de desenvolvimento.

Cenários de referência

OBSERVAÇÃO

Todos os testes de benchmark exibidos nesta página foram executados em uma configuração de laboratório.

Os cenários de teste detalhados abaixo são usados para as seções de benchmark dos capítulos TarMK, MongoMk e TarMK vs MongoMk. Para ver qual cenário foi usado para um teste de referencial específico, leia o campo Cenário da Especificações técnicas tabela.

Cenário de produto único

AEM Assets:

  • Interações do usuário: Pesquise ativos / Pesquise ativos / Baixe ativos / Leia metadados do ativo / Atualize metadados do ativo / Carregar ativo / Executar fluxo de trabalho de upload de ativo
  • Modo de execução: usuários simultâneos, única interação por usuário

Cenário de combinação de produtos

AEM Sites + Ativos:

  • Interações do usuário do Sites: Ler Página Do Artigo / Ler Página / Criar Parágrafo / Editar Parágrafo / Criar Página De Conteúdo / Ativar Página De Conteúdo / Pesquisar Do Autor
  • Interações do usuário do Assets: Pesquise ativos / Pesquise ativos / Baixe ativos / Leia metadados do ativo / Atualize metadados do ativo / Carregar ativo / Executar fluxo de trabalho de upload de ativo
  • Modo de execução: usuários simultâneos, interações mistas por usuário

Cenário de caso de uso vertical

Mídia:

  • Ler Página Do Artigo (27.4%), Página De Leitura (10.9%), Criar Sessão (2.6%), Ativar Página De Conteúdo (1.7%), Criar Página De Conteúdo (0.4%), Criar Parágrafo (4.3%), Editar Parágrafo (0.9%), Componente De Imagem (0.9%), Pesquisar Ativos (20%), Ler Metadados De Ativos (8.5 %), Baixar Ativo (4.2%), Pesquisar Ativo (0.2%), Atualizar Metadados De Ativo (2.4%), Fazer Upload De Ativo (1.2%), Procurar Projeto (4.9%), Ler Projeto (6.6%), Adicionar Ativo (1.2%), Adicionar Projeto (1.2%), Criar Projeto (0.1%), Pesquisa Do Autor )
  • Modo de execução: usuários simultâneos, interações mistas por usuário

TarMK

Este capítulo fornece diretrizes gerais de desempenho para o TarMK, especificando os requisitos mínimos de arquitetura e a configuração das configurações. Os testes de referência são também fornecidos para maior clarificação.

O Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, tanto para as instâncias de Autor e Publicação do AEM.

Para obter mais informações sobre TarMK, consulte Cenários de implantação e Armazenamento Tar.

Diretrizes de arquitetura mínima do TarMK

OBSERVAÇÃO

As diretrizes mínimas de arquitetura apresentadas abaixo são para ambientes de produção e sites de alto tráfego. Estes not o especificações mínimas necessário para executar o AEM.

Para estabelecer um bom desempenho ao usar o TarMK, você deve começar com a seguinte arquitetura:

  • Uma instância de autor
  • Duas instâncias de publicação
  • Dois Dispatchers

As diretrizes de arquitetura para AEM sites e AEM Assets estão ilustradas abaixo.

OBSERVAÇÃO

A replicação sem binário deve ser desativada ATIVADO se o armazenamento de dados do arquivo for compartilhado.

Diretrizes de arquitetura Tar para a AEM Sites

chlimage_1-5

Diretrizes de arquitetura Tar para a AEM Assets

chlimage_1-6

Diretriz de configurações do TarMK

Para um bom desempenho, você deve seguir as diretrizes de configuração apresentadas abaixo. Para obter instruções sobre como alterar as configurações, veja esta página.

Configuração Parâmetro Valor Descrição
Filas de Trabalho Sling queue.maxparallel Defina o valor para metade do número de núcleos da CPU. Por padrão, o número de threads simultâneos por fila de trabalhos é igual ao número de núcleos da CPU.
Fila de Fluxo de Trabalho Transitório do Granite Max Parallel Defina o valor para metade do número de núcleos da CPU
Parâmetros da JVM

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

Verdadeiro

Adicione esses parâmetros da JVM no script de início de AEM para impedir que consultas expansivas sobrecarreguem os sistemas.
Configuração do índice Lucene

CopyOnRead

CopyOnWrite

Prefetch Index Files

Ativado

Ativado

Ativado

Para obter mais detalhes sobre os parâmetros disponíveis, consulte esta página.
Armazenamento de dados = Armazenamento de dados S3

maxCachedBinarySize

cacheSizeInMB

1048576 (1MB) ou menor

2-10% do tamanho máximo do heap

Consulte também Configurações do armazenamento de dados.
Fluxo de trabalho do Ativo de atualização DAM Transient Workflow verificado Esse fluxo de trabalho controla a atualização de ativos.
Writeback de metadados DAM Transient Workflow verificado Esse workflow gerencia XMP write-back para o binário original e define a data da última modificação no JCR.

Benchmark de desempenho do TarMK

Especificações técnicas

Os testes de benchmark foram realizados com as seguintes especificações:

Nó do autor
Servidor Hardware de metal nu (HP)
Sistema Operacional RedHat Linux
CPU / núcleos CPU Intel® Xeon® CPU E5-2407 @2,40GHz, 8 núcleos
RAM 32GB
Disco Magnético
Java Oracle JRE versão 8
Heap da JVM 16GB
Produto AEM 6.2
Nodestore TarMK
Armazenamento de dados DS de arquivo
Cenário Produto único: Ativos / 30 threads simultâneos

Resultados da marca de desempenho

OBSERVAÇÃO

Os números apresentados abaixo foram normalizados para 1 como linha de base e não são os números reais da taxa de transferência.

chlimage_1-7 chlimage_1-8

MongoMK

O motivo principal para escolher o back-end de persistência do MongoMK sobre o TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução contínua e usar o MongoDB como o sistema de armazenamento de persistência. A necessidade de executar mais de uma instância de autor geralmente resulta do fato de que a CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não são mais sustentáveis.

Para obter mais informações sobre TarMK, consulte Cenários de implantação e Armazenamento Mongo.

Diretrizes de arquitetura mínima do MongoMK

Para estabelecer um bom desempenho ao usar o MongoMK, você deve começar com a seguinte arquitetura:

  • Três instâncias de autor
  • Duas instâncias de publicação
  • Três instâncias do MongoDB
  • Dois Dispatchers
OBSERVAÇÃO

Em ambientes de produção, o MongoDB sempre será usado como um conjunto de réplicas com um primário e dois segundos. Leituras e gravações vão para o primário e as leituras podem ir para os secundários. Se o armazenamento não estiver disponível, um dos secundários pode ser substituído por um árbitro, mas os conjuntos de réplicas do MongoDB devem sempre ser compostos por um número ímpar de instâncias.

OBSERVAÇÃO

A replicação sem binário deve ser desativada ATIVADO se o armazenamento de dados do arquivo for compartilhado.

chlimage_1-9

Diretrizes de configurações do MongoMK

Para um bom desempenho, você deve seguir as diretrizes de configuração apresentadas abaixo. Para obter instruções sobre como alterar as configurações, veja esta página.

Configuração Parâmetro Value (padrão) Descrição
Filas de Trabalho Sling queue.maxparallel Defina o valor para metade do número de núcleos da CPU. Por padrão, o número de threads simultâneos por fila de trabalhos é igual ao número de núcleos da CPU.
Fila de Fluxo de Trabalho Transitório do Granite Max Parallel Defina o valor para metade do número de núcleos da CPU.
Parâmetros da JVM

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

Verdadeiro

60000

Adicione esses parâmetros da JVM no script de início de AEM para impedir que consultas expansivas sobrecarreguem os sistemas.
Configuração do índice Lucene

CopyOnRead

CopyOnWrite

Prefetch Index Files

Ativado

Ativado

Ativado

Para obter mais detalhes sobre os parâmetros disponíveis, consulte esta página.
Armazenamento de dados = Armazenamento de dados S3

maxCachedBinarySize

cacheSizeInMB

1048576 (1MB) ou menor

2-10% do tamanho máximo do heap

Consulte também Configurações do armazenamento de dados.
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

35 (25)

20 (10)

30 (5)

10 (3)

4 (4)

./cache,size=2048,binary=0,-compact,-compress

O tamanho padrão do cache é definido como 256 MB.

Tem impacto no tempo necessário para executar a invalidação do cache.

oak-observation

thread pool

length

mín. e máx. = 20

50000

Benchmark de desempenho do MongoMK

Especificações técnicas

Os testes de benchmark foram realizados com as seguintes especificações:

Nó Autor Nó MongoDB
Servidor Hardware de metal nu (HP) Hardware de metal nu (HP)
Sistema Operacional RedHat Linux RedHat Linux
CPU / núcleos CPU Intel® Xeon® CPU E5-2407 @2,40GHz, 8 núcleos CPU Intel® Xeon® CPU E5-2407 @2,40GHz, 8 núcleos
RAM 32GB 32GB
Disco Magnético - >IOPS de 1k Magnético - >IOPS de 1k
Java Oracle JRE versão 8 N/A
Heap da JVM 16GB N/A
Produto AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore MongoMK N/A
Armazenamento de dados DS de arquivo N/A
Cenário Produto único: Ativos / 30 threads simultâneos Produto único: Ativos / 30 threads simultâneos

Resultados do benchmark de desempenho

OBSERVAÇÃO

Os números apresentados abaixo foram normalizados para 1 como linha de base e não são os números reais da taxa de transferência.

chlimage_1-10 chlimage_1-11

TarMK vs MongoMK

A regra básica que precisa ser levada em conta ao escolher entre os dois é que o TarMK foi projetado para desempenho, enquanto o MongoMK é usado para escalabilidade. O Adobe recomenda que o TarMK seja a tecnologia de persistência padrão usada pelos clientes em todos os cenários de implantação, tanto para as instâncias de Autor e Publicação do AEM.

O motivo principal para escolher o back-end de persistência do MongoMK sobre o TarMK é dimensionar as instâncias horizontalmente. Isso significa ter duas ou mais instâncias de autor ativas em execução contínua e usar o MongoDB como o sistema de armazenamento de persistência. A necessidade de executar mais de uma instância de autor geralmente resulta do fato de que a CPU e a capacidade de memória de um único servidor, suportando todas as atividades de criação simultâneas, não são mais sustentáveis.

Para obter mais detalhes sobre TarMK vs MongoMK, consulte Implantações recomendadas.

Diretrizes do TarMK vs MongoMk

Benefícios do TarMK

  • Propósito criado para aplicativos de gerenciamento de conteúdo
  • Os arquivos são sempre consistentes e podem ser copiados em backup usando qualquer ferramenta de backup baseada em arquivo
  • Fornece um mecanismo de failover - consulte Modo de espera a frio para obter mais detalhes
  • Fornece alto desempenho e armazenamento de dados confiável com o mínimo de sobrecarga operacional
  • TCO mais baixo (custo total de propriedade)

Critérios para escolher MongoMK

  • Número de usuários nomeados conectados em um dia: nos milhares ou mais
  • Número de usuários simultâneos: nas centenas ou mais
  • Volume de ingestões de ativos por dia: em centenas de milhares ou mais
  • Volume de edições de página por dia: em centenas de milhares ou mais
  • Volume de pesquisas por dia: em dezenas de milhares ou mais

TarMK vs. Benchmarks do MongoMK

OBSERVAÇÃO

Os números apresentados abaixo foram normalizados para 1 como linha de base e não são números reais da taxa de transferência.

Especificações técnicas do cenário 1

Nó OAK do autor Nó MongoDB
Servidor Hardware de metal nu (HP) Hardware de metal nu (HP)
Sistema Operacional RedHat Linux RedHat Linux
CPU / núcleos CPU Intel(R) Xeon(R) CPU E5-2407 @2,40GHz, 8 núcleos CPU Intel(R) Xeon(R) CPU E5-2407 @2,40GHz, 8 núcleos
RAM 32GB 32GB
Disco Magnético - >IOPS de 1k Magnético - >IOPS de 1k
Java Oracle JRE versão 8 N/A
JVM Heap16GB 16GB N/A
Produto AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK ou MongoMK N/A
Armazenamento de dados DS de arquivo N/A
Cenário


Produto único: Ativos / 30 threads simultâneos por execução

Resultados do benchmark de desempenho do cenário 1

chlimage_1-12

Cenário 2 Especificações técnicas

OBSERVAÇÃO

Para ativar o mesmo número de Autores com MongoDB como com um sistema TarMK, você precisa de um cluster com dois nós AEM. Um cluster MongoDB de quatro nós pode lidar com 1,8 vezes o número de Autores de uma instância TarMK. Um cluster MongoDB de oito nós pode lidar com 2,3 vezes o número de Autores de uma instância TarMK.

Nó TarMK do autor Nó MongoMK do autor Nó MongoDB
Servidor AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
Sistema Operacional RedHat Linux RedHat Linux RedHat Linux
CPU / núcleos 32 32 32
RAM 60GB 60GB 60GB
Disco SSD - IOPS de 10 mil SSD - IOPS de 10 mil SSD - IOPS de 10 mil
Java Oracle JRE versão 8
Oracle JRE versão 8
N/A
JVM Heap16GB 30GB 30GB N/A
Produto AEM 6.2 AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore TarMK MongoMK
N/A
Armazenamento de dados DS de arquivo
DS de arquivo

N/A
Cenário



Caso de uso vertical: Mídia / 2000 threads simultâneos

Resultados do benchmark de desempenho do cenário 2

chlimage_1-13

Diretrizes De Escalabilidade Da Arquitetura Para AEM Sites E Ativos

chlimage_1-14

Resumo das diretrizes de desempenho

As diretrizes apresentadas nesta página podem ser resumidas da seguinte maneira:

  • TarMK com armazenamento de dados de arquivo é a arquitetura recomendada para a maioria dos clientes:

    • Topologia mínima: uma instância de Autor, duas instâncias de Publicação, dois Dispatchers
    • Replicação sem binário ativada se o armazenamento de dados do arquivo for compartilhado
  • MongoMK com armazenamento de dados de arquivo é a arquitetura recomendada para a escalabilidade horizontal do nível Autor:

    • Topologia mínima: três instâncias de Autor, três instâncias de MongoDB, duas instâncias de Publicação, dois Dispatchers
    • Replicação sem binário ativada se o armazenamento de dados do arquivo for compartilhado
  • Nodestore deve ser armazenado no disco local, não em um NAS (Network Attached Storage, armazenamento conectado à rede)

  • Ao usar Amazon S3:

    • O armazenamento de dados do Amazon S3 é compartilhado entre a camada Autor e Publicação
    • A replicação sem binário deve ser ativada
    • A coleta de lixo do armazenamento de dados requer uma primeira execução em todos os nós Autor e Publicação e, em seguida, uma segunda execução no Autor
  • O índice personalizado deve ser criado além do índice predefinido com base nas pesquisas mais comuns

    • Índices Lucene devem ser usados para índices personalizados
  • A personalização do fluxo de trabalho pode melhorar substancialmente o desempenho, por exemplo, remoção da etapa de vídeo no fluxo de trabalho "Atualizar ativo", desativação de ouvintes que não são usados etc.

Para obter mais detalhes, leia também a Implantações recomendadas página.

Nesta página