Diretrizes de dimensionamento de hardware hardware-sizing-guidelines
Essas diretrizes de dimensionamento oferecem uma aproximação dos recursos de hardware necessários para implantar um projeto AEM. As estimativas de dimensionamento dependem da arquitetura do projeto, da complexidade da solução, do tráfego esperado e dos requisitos do projeto. Este guia ajuda a determinar as necessidades de hardware de uma solução específica ou a encontrar uma estimativa superior e inferior para os requisitos de hardware.
Os fatores básicos a serem considerados são (nesta ordem):
-
Velocidade da rede
- Latência de rede
- Largura de banda disponível
-
Velocidade computacional
- Eficiência de armazenamento em cache
- Tráfego esperado
- Complexidade de modelos, aplicativos e componentes
- Autores simultâneos
- Complexidade da operação de criação (edição simples de conteúdo, implantação do MSM e assim por diante)
-
Desempenho de E/S
- Desempenho e eficiência do armazenamento de arquivos ou bancos de dados
-
Disco rígido
- pelo menos duas ou três vezes maior que o tamanho do repositório
-
Memória
- Tamanho do site (número de objetos de conteúdo, páginas e usuários)
- Número de usuários/sessões ativos ao mesmo tempo
Arquitetura architecture
Uma configuração típica do AEM consiste em um autor e um ambiente de publicação. Esses ambientes têm requisitos diferentes em relação ao tamanho do hardware subjacente e à configuração do sistema. Considerações detalhadas para ambos os ambientes estão descritas nas seções ambiente do autor e ambiente de publicação.
Em uma configuração de projeto típica, você tem vários ambientes nos quais preparar fases do projeto:
-
Ambiente de desenvolvimento
Desenvolver novos recursos ou fazer alterações significativas. A prática recomendada é trabalhar usando um ambiente de desenvolvimento por desenvolvedor (instalações locais em seus sistemas pessoais). -
Ambiente de teste do autor
Para verificar as alterações. O número de ambientes de teste pode variar dependendo dos requisitos do projeto (por exemplo, separado para controle de qualidade, teste de integração ou teste de aceitação do usuário). -
Ambiente de teste do Publish
Principalmente para testar casos de uso de colaboração social e/ou a interação entre o autor e várias instâncias de publicação. -
Criar ambiente de produção
Para autores editarem conteúdo. -
Ambiente de produção do Publish
Para fornecer conteúdo publicado.
Além disso, os ambientes podem variar, desde um sistema de servidor único executando AEM e um servidor de aplicativos até um conjunto altamente dimensionado de instâncias clusterizadas de vários servidores e várias CPUs. A Adobe recomenda que você use um computador separado para cada sistema de produção e que você não execute outros aplicativos nesses computadores.
Considerações de dimensionamento de hardware genérico generic-hardware-sizing-considerations
As seções abaixo fornecem orientação sobre como calcular os requisitos de hardware, levando em conta várias considerações. Para sistemas grandes, o Adobe sugere que você execute um conjunto simples de testes de desempenho internos em uma configuração de referência.
A otimização de desempenho é uma tarefa fundamental que precisa ser executada antes que qualquer benchmark de um projeto específico possa ser feito. Aplique a dica fornecida na documentação de Otimização de Desempenho antes de executar testes de referência de desempenho e usar seus resultados para qualquer cálculo de dimensionamento de hardware.
Os requisitos de dimensionamento de hardware para casos de uso avançados devem se basear em uma avaliação detalhada do desempenho do projeto. As características dos casos de uso avançados que exigem recursos de hardware excepcionais incluem combinações de:
- carga/taxa de transferência de alto conteúdo
- uso abrangente de código personalizado, fluxos de trabalho personalizados ou bibliotecas de software de terceiros
- integração com sistemas externos não compatíveis
Espaço em disco/disco rígido disk-space-hard-drive
O espaço em disco necessário depende muito do volume e do tipo do aplicativo Web. Os cálculos devem levar em conta o seguinte:
- a quantidade e o tamanho das páginas, dos ativos e de outras entidades armazenadas no repositório, como fluxos de trabalho, perfis etc.
- a frequência estimada de alterações de conteúdo e, portanto, a criação de versões de conteúdo
- o volume de representações de ativos do DAM que será gerado
- o crescimento geral do conteúdo ao longo do tempo
O espaço em disco é monitorado continuamente durante a Limpeza de revisão on-line e off-line. Se o espaço em disco disponível ficar abaixo de um valor crítico, o processo será cancelado. O valor crítico é 25% do espaço em disco atual do repositório e não é configurável. A Adobe recomenda dimensionar o disco pelo menos duas ou três vezes maior que o tamanho do repositório, incluindo o crescimento estimado.
Considere uma configuração de matrizes redundantes de discos independentes (RAID, por exemplo, RAID10) para redundância de dados.
Virtualização virtualization
O AEM é bem executado em ambientes virtualizados, mas pode haver fatores como CPU ou E/S que não podem ser diretamente comparados ao hardware físico. Uma recomendação é escolher uma velocidade de I/O mais alta (em geral), pois esse é um fator crítico, geralmente. A avaliação comparativa do ambiente é necessária para obter uma compreensão precisa de quais recursos são necessários.
Paralelização de instâncias de AEM parallelization-of-aem-instances
Segurança contra falhas
Um site à prova de falhas é implantado em pelo menos dois sistemas separados. Se um sistema falhar, outro sistema poderá assumir o controle e, assim, compensar a falha do sistema.
Escalabilidade dos recursos do sistema
Enquanto todos os sistemas estão em execução, um maior desempenho computacional está disponível. Esse desempenho adicional não é necessariamente linear com o número de nós de cluster, pois o relacionamento é altamente dependente do ambiente técnico. Consulte a Documentação do cluster para obter mais informações.
A estimativa de quantos nós de cluster são necessários baseia-se nos requisitos básicos e nos casos de uso específicos do projeto da Web:
- Do ponto de vista da segurança contra falhas, é necessário determinar, para todos os ambientes, o nível crítico de falha e o tempo de compensação com base no tempo necessário para a recuperação de um nó de cluster.
- Para o aspecto da escalabilidade, o número de operações de gravação é basicamente o fator mais importante; consulte Autores Trabalhando em Paralelo para o ambiente de criação e Collaboration Social para o ambiente de publicação. O balanceamento de carga pode ser estabelecido para operações que acessam o sistema apenas para processar operações de leitura; consulte Dispatcher para obter detalhes.
Cálculos específicos do ambiente do autor author-environment-specific-calculations
Para fins de benchmark, o Adobe desenvolveu alguns testes de benchmark para instâncias de autor independentes.
-
Teste de referência 1
Calcule a taxa de transferência máxima de um perfil de carga em que os usuários executam um exercício simples de criação de página sobre uma carga básica de 300 páginas existentes, todas de natureza semelhante. As etapas envolvidas eram fazer logon no site, criar uma página com um SWF e Imagem/Texto, adicionar uma nuvem de tags e ativar a página.- Resultado
A taxa de transferência máxima para um exercício de criação de página simples, como o acima—considerada como uma transação—é de 1730 transações/hora.
- Resultado
-
Teste de referência 2
Calcule a taxa de transferência máxima quando o perfil de carga tiver uma combinação de criação de página nova (10%), modificação de uma página existente (80%) e criação e modificação de uma página em sucessão (10%). A complexidade das páginas permanece a mesma do perfil do teste de benchmark 1. A modificação básica da página é feita adicionando uma imagem e modificando o conteúdo do texto. Novamente, o exercício foi executado sobre uma carga básica de 300 páginas com a mesma complexidade, conforme definido no teste de benchmark 1.- Resultado
A taxa de transferência máxima para esse cenário de operação de mix foi encontrada em 3252 transações por hora.
- Resultado
Os dois testes acima destacam claramente que o throughput varia de acordo com o tipo de operação. Use as atividades em seu ambiente como base para dimensionar seu sistema. Você obtém melhor throughput com ações menos intensivas, como modificar (o que também é mais comum).
Armazenamento em cache caching
No ambiente de criação, a eficiência do armazenamento em cache normalmente é muito menor, porque as alterações no site são mais frequentes e também o conteúdo é altamente interativo e personalizado. Usando o Dispatcher, você pode armazenar em cache bibliotecas AEM, JavaScript, arquivos CSS e imagens de layout. Isso acelera alguns aspectos do processo de criação. Configurar o servidor Web para definir cabeçalhos para o cache do navegador nesses recursos também reduz o número de solicitações HTTP e, portanto, melhora a capacidade de resposta do sistema conforme experimentado pelos autores.
Autores trabalhando em paralelo authors-working-in-parallel
No ambiente de criação, o número de autores que trabalham em paralelo e a carga que suas interações adicionam ao sistema são os principais fatores limitantes. Portanto, a Adobe recomenda dimensionar o sistema com base na taxa de transferência compartilhada de dados.
Para esses cenários, o Adobe executou testes de referência em um cluster de dois nós sem compartilhamento de instâncias de autor.
-
Teste de benchmark 1a
Com um cluster sem compartilhamento ativo-ativo de 2 instâncias de autor, calcule a taxa de transferência máxima com um perfil de carga em que os usuários executam um exercício de criação de página simples sobre uma carga base de 300 páginas existentes, todas de natureza semelhante.- Resultado
A taxa de transferência máxima para um exercício simples de criação de página, como o acima—considerada como uma transação—é de 2016 transações/hora. Isso é um aumento de aproximadamente 16% quando comparado a uma instância de autor independente para o mesmo teste de benchmark.
- Resultado
-
Teste de referência 2b
Com um cluster sem compartilhamento ativo-ativo de 2 instâncias de autor, calcule a taxa de transferência máxima quando o perfil de carregamento tiver uma combinação de criação de página nova (10%), modificação de uma página existente (80%) e criação e modificação de uma página em sucessão (10%). A complexidade da página permanece a mesma do perfil do teste de benchmark 1. A modificação básica da página é feita adicionando uma imagem e modificando o conteúdo do texto. Novamente, o exercício foi executado sobre uma carga básica de 300 páginas de complexidade, a mesma definida no teste de benchmark 1.- Resultado
A taxa de transferência máxima para esse cenário de operação mista foi de 6288 transações/hora. Isso é um aumento de aproximadamente 93% quando comparado a uma instância de autor independente para o mesmo teste de benchmark.
- Resultado
Os dois testes acima destacam claramente que o AEM é bem dimensionado para autores que estão realizando operações básicas de edição com AEM. Em geral, o AEM é mais eficaz no dimensionamento de operações de leitura.
Em um site típico, a maioria da criação ocorre durante a fase do projeto. Depois que o site entra em funcionamento, o número de autores trabalhando em paralelo geralmente desce para uma média mais baixa (modo operacional).
Você pode calcular o número de computadores (ou CPUs) necessários para o ambiente de criação da seguinte maneira:
n = numberOfParallelAuthors / 30
Essa fórmula pode servir como uma diretriz geral para dimensionar CPUs quando os autores estão executando operações básicas com AEM. Ele pressupõe que o sistema e o aplicativo estejam otimizados. No entanto, a fórmula não será verdadeira para recursos avançados, como MSM ou Assets (consulte as seções abaixo).
Consulte também Paralelização e Otimização de Desempenho.
Recommendations de hardware hardware-recommendations
Normalmente, você pode usar o mesmo hardware para o ambiente de criação que é recomendado para o ambiente de publicação. Normalmente, o tráfego do site é menor nos sistemas de criação, mas a eficiência do cache também é menor. No entanto, o fator fundamental aqui é o número de autores trabalhando em paralelo, juntamente com o tipo de ações que estão sendo feitas no sistema. Em geral, o agrupamento de AEM (do ambiente do autor) é mais eficaz no dimensionamento de operações de leitura; em outras palavras, um cluster de AEM é bem dimensionado com autores que estão executando operações básicas de edição.
Os testes de benchmark no Adobe foram executados com o sistema operacional Red Hat® 5.5, em uma plataforma de hardware Hewlett-Packard ProLiant DL380 G5, com a seguinte configuração:
- Duas CPUs Intel Xeon® X5450 de 4 núcleos a 3,00 GHz
- 8 GB de RAM
- Gigabit Ethernet Broadcom NetXtreme II BCM5708
- Controlador RAID HP Smart Array, cache de 256 MB
- Dois discos SAS de 146 GB e 10.000 RPM configurados como um conjunto de distribuição RAID0
- Pontuação do benchmark SPEC CINT2006 Rate é 110
As instâncias de AEM estavam em execução com um tamanho mínimo de heap de 256 M, um tamanho máximo de heap de 1024 M.
cálculos específicos de ambiente do Publish publish-environment-specific-calculations
Eficiência e tráfego de cache caching-efficiency-and-traffic
A eficiência do cache é fundamental para a velocidade do site. A tabela a seguir mostra quantas páginas por segundo um sistema AEM otimizado pode lidar com o uso de um proxy reverso, como o Dispatcher:
A relação de cache é a porcentagem de páginas que o Dispatcher pode retornar sem precisar acessar AEM. 100% indica que o Dispatcher responde a todas as solicitações, 0% significa que o AEM calcula cada página.
Complexidade de modelos e aplicativos complexity-of-templates-and-applications
Se você usa modelos complexos, o AEM precisa de mais tempo para renderizar uma página. As páginas retiradas do cache não são afetadas por isso, mas o tamanho da página ainda é relevante ao considerar o tempo de resposta geral. A renderização de uma página complexa pode facilmente levar dez vezes mais tempo do que a renderização de uma página simples.
Fórmula formula
Usando a seguinte fórmula, você pode calcular uma estimativa da complexidade geral da solução AEM:
complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)
Com base na complexidade, você pode determinar o número de servidores (ou núcleos de CPU) necessários para o ambiente de publicação da seguinte maneira:
n = (traffic * complexity / 1000 ) * activations
As variáveis na equação são as seguintes:
Se você tem um site mais complexo, você também precisa de servidores Web mais potentes para que o AEM possa responder a uma solicitação em um tempo aceitável.
-
Complexidade abaixo de 4:
- 1024 MB de RAM JVM*
- CPU de baixo a médio desempenho
-
Complexidade de 4 a 8:
- 2048 MB de RAM JVM*
- CPU de médio a alto desempenho
-
Complexidade acima de 8:
- 4096 MB de RAM JVM*
- CPU de alto desempenho a alto desempenho
Cálculos adicionais específicos de caso de uso additional-use-case-specific-calculations
Além do cálculo de um aplicativo web padrão, considere fatores específicos para os seguintes casos de uso. Os valores calculados devem ser adicionados ao cálculo padrão.
Considerações específicas do Assets assets-specific-considerations
O processamento extensivo de ativos digitais requer recursos de hardware otimizados. Os fatores mais relevantes são o tamanho da imagem e a taxa de transferência máxima das imagens processadas.
Aloque pelo menos 16 GB de heap e configure o fluxo de trabalho do Ativo de atualização do DAM para usar o pacote Camera Raw para a assimilação de imagens brutas.
Gerenciador de vários sites multi-site-manager
O consumo de recursos ao usar o AEM MSM em um ambiente de criação depende muito dos casos de uso específicos. Os fatores básicos são:
- Número de Live Copies
- Periodicidade das implantações
- Tamanho da árvore de conteúdo a ser implantada
- Funcionalidade conectada das ações de implantação
Testar o caso de uso planejado com um trecho de conteúdo representativo pode ajudar você a entender melhor o consumo de recursos. Se você extrapolar os resultados com o rendimento planejado, poderá avaliar os recursos adicionais necessários para o MSM AEM.
Além disso, leve em conta os autores que trabalham em paralelo. Eles perceberão os efeitos colaterais do desempenho se os casos de uso de AEM MSM consumirem mais recursos do que o planejado.
Considerações de dimensionamento do AEM Communities aem-communities-sizing-considerations
Os sites AEM que incluem recursos do AEM Communities (sites da comunidade) têm um alto nível de interação dos visitantes do site (membros) no ambiente de publicação.
As considerações de dimensionamento para um site da comunidade dependem da interação prevista pelos membros da comunidade e se o desempenho ideal para o conteúdo da página é de maior importância.
O conteúdo gerado pelo usuário (UGC) enviado pelos membros é armazenado separadamente do conteúdo da página. Embora a plataforma AEM use um armazenamento de nós que replica o conteúdo do site do autor para a publicação, o AEM Communities usa um armazenamento único e comum para UGC que nunca é replicado.
Para o armazenamento UGC, é necessário escolher um SRP (Storage Resource Provider, provedor de recursos de armazenamento), que influencia a implantação escolhida.
Consulte