Otimização de desempenho performance-optimization

Um problema importante é o tempo que seu site leva para responder às solicitações do visitante. Embora esse valor varie para cada solicitação, um valor médio de público-alvo pode ser definido. Uma vez que esse valor seja comprovadamente alcançável e sustentável, ele poderá ser usado para monitorar o desempenho do site e indicar o desenvolvimento de possíveis problemas.

Os tempos de resposta que você desejará serão diferentes nos ambientes de criação e publicação, refletindo as diferentes características do público-alvo:

Ambiente de criação author-environment

Esse ambiente é usado pelos autores que inserem e atualizam o conteúdo. Ele deve atender a um pequeno número de usuários que geram um alto número de solicitações de alto desempenho ao atualizar páginas de conteúdo e os elementos individuais nessas páginas.

Ambiente de publicação publish-environment

Esse ambiente contém conteúdo que você disponibiliza para seus usuários. Neste caso, o número de pedidos é ainda maior e a velocidade é igualmente vital, mas uma vez que a natureza dos pedidos é menos dinâmica, podem ser aplicados mecanismos adicionais de melhoria do desempenho; como armazenar em cache o conteúdo ou balanceamento de carga.

Metodologia de Otimização de Desempenho performance-optimization-methodology

Uma metodologia de otimização de desempenho para projetos de AEM pode ser resumida em cinco regras muito simples que podem ser seguidas para evitar problemas de desempenho desde o início:

Essas regras, em grande medida, se aplicam a projetos da Web em geral e são relevantes para gerentes de projeto e administradores de sistema para garantir que seus projetos não enfrentarão desafios de desempenho quando a inicialização chegar.

Planejamento para otimização planning-for-optimization

Cerca de 10% do esforço do projeto deve ser planejado para a fase de otimização de desempenho. É claro que os requisitos reais de otimização de desempenho dependerão do nível de complexidade de um projeto e da experiência da equipe de desenvolvimento. Embora seu projeto possa (em última análise) não exigir todo o tempo alocado, é uma boa prática sempre planejar a otimização de desempenho na região sugerida.

Sempre que possível, um projeto deve ser lançado de forma flexível para um público-alvo limitado, a fim de coletar a experiência real e realizar mais otimizações, sem a pressão adicional que se segue a um anúncio completo.

Quando estiver "ativo", a otimização de desempenho não terminará. Este é o momento em que você experimenta a carga "real" em seu sistema. É importante planejar ajustes adicionais após o lançamento.

Como a carga do sistema muda e os perfis de desempenho do sistema mudam ao longo do tempo, uma "atualização" ou "verificação de integridade" de desempenho deve ser agendada em intervalos de 6 a 12 meses.

Simular Realidade simulate-reality

Se você entrar no ar com um site e descobrir, após o lançamento, que se deparou com problemas de desempenho, há apenas um motivo para isso: Seus testes de carga e desempenho não simularam a realidade de forma suficientemente precisa.

Simular a realidade é difícil e o esforço que você razoavelmente desejará investir para obter "real" depende da natureza do seu projeto. "Real" significa não apenas "código real" e "tráfego real", mas também "conteúdo real", especialmente em relação à dimensão e estrutura do conteúdo. Lembre-se de que seus modelos podem se comportar de forma completamente diferente dependendo do tamanho e da estrutura do repositório.

Estabelecer metas sólidas establish-solid-goals

A importância de estabelecer adequadamente objetivos de desempenho não deve ser subestimada. Frequentemente, uma vez que as pessoas se concentram em objetivos de desempenho específicos, é muito difícil alterar estes objetivos posteriormente, mesmo que se baseiem em suposições selvagens.

Estabelecer metas de desempenho boas e sólidas é realmente uma das áreas mais difíceis. Geralmente, é melhor coletar registros e benchmarks da vida real de um site comparável (por exemplo, o antecessor do novo site).

Permanecer relevante stay-relevant

É importante otimizar um gargalo de cada vez. Se você tentar fazer as coisas em paralelo sem validar o impacto de uma otimização, perderá o controle de qual medida de otimização realmente ajudou.

Ciclos de Iteração Ágil agile-iteration-cycles

O ajuste de desempenho é um processo iterativo que envolve, medição, análise, otimização e validação até que a meta seja alcançada. Para ter em conta este aspecto adequadamente, implemente um processo de validação ágil na fase de otimização, em vez de um processo de teste mais pesado após cada iteração.

Isso significa que o desenvolvedor que implementa a otimização deve ter uma maneira rápida de saber se a otimização já atingiu o objetivo. Essas são informações valiosas, pois quando a meta é atingida, a otimização acaba.

Diretrizes básicas de desempenho basic-performance-guidelines

Geralmente, mantenha suas solicitações html não armazenadas em cache para menos de 100 ms. Mais especificamente, os seguintes podem servir como diretriz:

Os números acima assumem as seguintes condições:

Há um certo número de problemas que frequentemente contribuem para problemas de desempenho. Elas giram principalmente em torno de:

O ajuste de nível da JVM e do SO geralmente não dá grandes saltos no desempenho e, portanto, deve ser executado no final do ciclo de otimização.

A maneira como um repositório de conteúdo é estruturado também pode afetar o desempenho. Para melhor desempenho, o número de nós secundários anexados a nós individuais em um repositório de conteúdo não deve exceder 1.000 (como regra geral).

Seus melhores amigos durante um exercício normal de otimização de desempenho são:

Desempenho ao carregar e editar Ativos digitais performance-when-loading-and-editing-digital-assets

Devido ao grande volume de dados envolvidos ao carregar e editar ativos digitais, o desempenho pode se tornar um problema.

Duas coisas afetam o desempenho aqui:

Para melhorar o desempenho, considere o seguinte:

Monitoramento de desempenho performance-monitoring

O desempenho (ou a falta dele) é uma das primeiras coisas que seus usuários notam, de modo que, com qualquer aplicativo com uma interface do usuário, o desempenho é de importância fundamental. Para otimizar o desempenho da instalação do AEM, você precisa monitorar vários atributos da instância e seu comportamento.

Para obter informações sobre como executar o monitoramento de desempenho, consulte Monitorar desempenho.

Os problemas que causam problemas de desempenho geralmente são difíceis de serem rastreados, mesmo quando seus efeitos são fáceis de ver.

Um ponto de partida básico é um bom conhecimento do seu sistema quando ele está funcionando normalmente. A menos que você saiba como seu ambiente "parece" e "se comporta" quando está funcionando corretamente, pode ser difícil localizar o problema quando o desempenho piorar. Isso significa que você deve gastar algum tempo investigando seu sistema quando ele estiver funcionando sem problemas e garantir que a coleta de informações de desempenho seja uma tarefa em andamento. Isso fornecerá uma base para comparação caso o desempenho sofra.

O diagrama a seguir ilustra o caminho que uma solicitação de conteúdo AEM pode tomar e, portanto, o número de elementos diferentes que podem afetar o desempenho.

O desempenho também é um equilíbrio entre volume e capacidade:

Volume A quantidade de saída que é processada e entregue pelo sistema.

Capacidade A capacidade do sistema de fornecer o volume.

Isso pode ser ilustrado em vários locais da cadeia da Web.

Há várias áreas funcionais que geralmente são responsáveis por afetar o desempenho:

Regras básicas sobre desempenho basic-rules-regarding-performance

Algumas regras devem ser levadas em conta ao otimizar o desempenho:

Configuração para desempenho configuring-for-performance

Determinados aspectos do AEM (e/ou do repositório subjacente) podem ser configurados para otimizar o desempenho. Veja a seguir as possibilidades e sugestões, você deve ter certeza se, ou como, usará a funcionalidade em questão antes de fazer alterações.

Indexação de Pesquisa search-indexing

A partir do AEM 6.0, o Adobe Experience Manager usa uma arquitetura de repositório baseada em Oak.

Você pode encontrar as informações de indexação atualizadas aqui:

Processamento de fluxo de trabalho simultâneo concurrent-workflow-processing

Limite o número de processos de fluxo de trabalho executados simultaneamente para melhorar o desempenho. Por padrão, o mecanismo de workflow processa tantos workflows em paralelo quanto há processadores disponíveis para a Java VM. Quando as etapas do fluxo de trabalho exigem grandes quantidades de recursos de processamento (RAM ou CPU), executar vários desses fluxos de trabalho em paralelo pode colocar altas demandas nos recursos disponíveis do servidor.

Por exemplo, quando imagens (ou ativos DAM em geral) são carregadas, os fluxos de trabalho importam automaticamente as imagens para o DAM. As imagens geralmente são de alta resolução e podem facilmente consumir centenas de MB de heap para processamento. Manipular essas imagens em paralelo coloca uma alta carga no subsistema da memória e no coletor de lixo.

O mecanismo de workflow usa as filas de job do Apache Sling para manusear e agendar o processamento de itens de trabalho. Os seguintes serviços de fila de trabalhos foram criados por padrão a partir do Apache Sling Job Queue Configuration fatory para processar trabalhos de fluxo de trabalho:

Configure esses serviços para limitar o número máximo de processos de workflow em execução simultânea.

Observação: A configuração dessas filas de trabalhos afeta todos os fluxos de trabalho, a menos que tenha criado uma fila de trabalhos para um modelo de fluxo de trabalho específico (consulte Configurar a fila para um modelo de fluxo de trabalho específico abaixo).

Configuração no Repositório configuration-in-the-repo

Se você estiver configurando os serviços usando um nó sling:OsgiConfig, é necessário encontrar o PID dos serviços existentes, por exemplo: org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Você pode descobrir o PID usando o Console da Web.

Você precisa configurar a propriedade chamada queue.maxparallel.

Configuração no Console da Web configuration-in-the-web-console

Para configurar esses serviços usando o Console da Web, localize os itens de configuração existentes abaixo da fábrica do serviço Configuração da fila de trabalhos do Apache Sling.

Você precisa configurar a propriedade chamada Máximo de trabalhos paralelos.

Configurar a fila para um fluxo de trabalho específico configure-the-queue-for-a-specific-workflow

Crie uma fila de trabalhos para um modelo de fluxo de trabalho específico para configurar a manipulação de tarefas para esse modelo de fluxo de trabalho. Dessa forma, suas configurações afetam o processamento de um fluxo de trabalho específico, enquanto a configuração padrão da Fila de fluxo de trabalho do Granite controla o processamento de outros fluxos de trabalho.

Quando modelos de fluxo de trabalho são executados, eles criam trabalhos do Sling para um tópico específico. Por padrão, o tópico corresponde aos tópicos configurados para a fila geral de fluxo de trabalho do Granite ou para a fila de trabalhos do processo externo do fluxo de trabalho do Granite:

Os tópicos reais do job que os modelos de workflow geram incluem o sufixo específico do modelo. Por exemplo, o modelo de fluxo de trabalho Ativo de atualização DAM gera trabalhos com o seguinte tópico:

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

Portanto, você pode criar uma fila de trabalhos para o tópico que corresponda aos tópicos de tarefa do seu modelo de fluxo de trabalho. Configurar as propriedades relacionadas ao desempenho da fila afeta apenas o modelo de fluxo de trabalho que gera trabalhos que correspondem ao tópico da fila.

O procedimento a seguir cria uma fila de trabalhos para um fluxo de trabalho, usando o fluxo de trabalho Ativo de atualização DAM como exemplo.

Serviço de sincronização de ativos DAM AEM cq-dam-asset-synchronization-service

O AssetSynchronizationService O é usado para sincronizar ativos de repositórios montados (incluindo LiveLink, Documentum, entre outros). Por padrão, isso faz uma verificação regular a cada 300 segundos (5 minutos), portanto, se você não usar repositórios montados, poderá desativar esse serviço.

Isso é feito por configuração do serviço OSGi Serviço de sincronização de ativos DAM CQ para definir a variável Período de sincronização ( scheduler.period) a (no mínimo) 1 ano (definido em segundos).

Várias instâncias do DAM multiple-dam-instances

Implantar várias instâncias de DAM pode ajudar no desempenho quando, por exemplo:

Considerações adicionais são:

Práticas recomendadas para garantia de qualidade best-practices-for-quality-assurance

O desempenho é de extrema importância para o seu ambiente de publicação. Portanto, é necessário planejar e analisar cuidadosamente os testes de desempenho que você fará para o ambiente de publicação ao implementar seu projeto.

Esta seção tem como objetivo fornecer uma visão geral padronizada dos problemas envolvidos na definição de um conceito de teste especificamente para testes de desempenho em seu publicar ambiente. Isso é de interesse principalmente para engenheiros de controle de qualidade, gerentes de projeto e administradores de sistema.

Abrange uma abordagem padronizada para testes de desempenho para uma aplicação AEM no Publicar ambiente. Isso envolve as 5 seguintes fases:

O controle é um processo adicional e abrangente - necessário, mas não limitado a testes.

Verificação dos conhecimentos verification-of-knowledge

Uma primeira etapa é documentar as informações básicas que você precisa saber antes de iniciar os testes:

Arquitetura de teste test-architecture

Você deve documentar claramente a arquitetura do ambiente de teste que está sendo usado para seus testes de desempenho.

Você precisará de uma reprodução do ambiente de publicação de produção planejado, juntamente com o Dispatcher e o Balanceador de carga.

Mapa de aplicativos application-map

Para obter uma visão geral clara, você pode criar um mapa de todo o aplicativo (é possível que tenha isso dos testes no ambiente Autor).

Uma representação gráfica dos elementos internos do pedido pode dar uma visão geral dos requisitos de ensaio; com a codificação por cores, também pode servir de base para o relatório.

Definição de escopo scope-definition

Geralmente, um aplicativo terá uma seleção de casos de uso. Alguns serão muito importantes, outros menos.

Para focalizar o escopo do teste de desempenho na publicação, recomendamos que você defina o seguinte:

O número de casos de uso depende de você, mas deve se limitar a um número facilmente gerenciável (por exemplo, entre 5 e 10).

Depois que os principais casos de uso forem selecionados, os KPI (indicadores-chave de desempenho) e as ferramentas usadas para avaliá-los poderão ser definidos para cada caso. Exemplos de KPIs comuns incluem:

Metodologias de teste test-methodologies

Esse conceito tem quatro cenários usados para definir e testar as metas de desempenho:

Baseado nos seguintes princípios:

Pontos de interrupção de componente component-breakpoints

Transações transactions

Definir as metas de desempenho defining-the-performance-goals

Depois que o escopo e os KPIs relacionados forem definidos, as metas de desempenho específicas poderão ser definidas. Isso envolve a concepção de cenários de teste, juntamente com valores de target.

Você precisará testar o desempenho em condições médias e de pico. Além disso, você precisará de testes de cenário do Google Live para garantir que possa atender a um interesse maior em seu site quando ele for disponibilizado pela primeira vez.

Qualquer experiência ou estatística que você tenha coletado de um site existente também pode ser útil para determinar objetivos futuros; por exemplo, o tráfego principal de seu site ativo.

Testes de componente único single-component-tests

Os componentes críticos terão de ser testados em condições médias e de pico.

Em ambos os casos, é possível definir o número esperado de transações por segundo quando um número predefinido de usuários estiver usando o sistema.

Testes de componentes combinados combined-component-tests

Testar os componentes em combinação oferece uma reflexão mais próxima do comportamento dos aplicativos. Devem ser testadas novamente as condições médias e de pico.

Indo para testes em tempo real going-live-tests

Durante os primeiros dias após o seu site ser disponibilizado, você pode esperar um nível maior de interesse. Isso provavelmente será ainda maior que os valores de pico que você tem testado. É altamente recomendável testar cenários do Google Live para garantir que o sistema possa atender a essa situação.

Testes de cenário de erro error-scenario-tests

Os cenários de erro também devem ser testados para garantir que o sistema reaja corretamente e adequadamente. Não apenas na forma como o erro em si é tratado, mas no impacto que ele pode ter no desempenho. Por exemplo:

Ao elaborar esses testes, deve-se lembrar que nem todos os cenários ocorrerão regularmente. No entanto, o seu impacto em todo o sistema é importante.

Testes de resistência endurance-tests

Certos problemas só serão encontrados depois de o sistema estar em funcionamento durante um período de tempo contínuo; seja horas ou mesmo dias. É utilizado um ensaio de resistência para testar uma carga média constante durante um período de tempo necessário. Qualquer degradação de desempenho pode ser analisada.

Otimização optimization

Nos estágios posteriores de implementação, você precisará otimizar o aplicativo para atingir/maximizar as metas de desempenho.

Todas as otimizações feitas devem ser testadas para garantir que elas tenham:

Uma seleção de ferramentas está disponível para ajudá-lo com a geração de carga, monitoramento de desempenho e/ou análise de resultados:

Após a otimização, será necessário testar novamente para confirmar o impacto.

Relatório reporting

Os relatórios em andamento serão necessários para manter todos informados sobre o status. Como mencionado anteriormente com codificação por cores, o mapa de arquitetura pode ser usado para isso.

Depois que todos os testes forem concluídos, você deverá informar sobre:

Otimizar o desempenho ao usar o Dispatcher optimizing-performance-when-using-the-dispatcher

O Dispatcher é balanceamento de carga e/ou Adobe. Ao usar o Dispatcher, você deve considerar a otimização do seu site para o desempenho do cache.

O Dispatcher oferece vários mecanismos integrados que você pode usar para otimizar o desempenho se o seu site aproveitar. Esta seção informa como projetar seu site para potencializar os benefícios do armazenamento em cache.

Calculando a Taxa de Cache do Dispatcher calculating-the-dispatcher-cache-ratio

A fórmula da taxa de cache estima a porcentagem de solicitações tratadas pelo cache do número total de solicitações que entram no sistema. Para calcular a taxa de cache, você precisa do seguinte:

A fórmula para calcular a taxa de cache é:

Por exemplo, se o número total de solicitações for 129491 e o número de solicitações atendidas pela instância de publicação for 58959, a taxa de cache será: (129491 - 58959)/129491= 54,5%.

Se você não tiver um emparelhamento de um para um editor/dispatcher, precisará adicionar solicitações de todos os dispatchers e editores juntos para obter uma medição precisa. Consulte também Implantações recomendadas.

Uso de codificação de página consistente using-consistent-page-encoding

Com o Dispatcher versão 4.1.11, é possível armazenar em cache os cabeçalhos de resposta. Se você não estiver armazenando cabeçalhos de resposta em cache no Dispatcher, poderão ocorrer problemas se você armazenar informações de codificação de página no cabeçalho. Nessa situação, quando o Dispatcher fornece uma página do cache, a codificação padrão do servidor Web é usada para a página. Há duas maneiras de evitar esse problema:

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Evitar parâmetros de URL avoid-url-parameters

Se possível, evite parâmetros de URL para páginas que você deseja armazenar em cache. Por exemplo, se você tiver uma galeria de imagens, o URL a seguir nunca será armazenado em cache (a menos que o Dispatcher esteja configurado adequadamente):

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

No entanto, você pode colocar esses parâmetros no URL da página, da seguinte maneira:

www.myCompany.com/pictures/gallery.christmas.1.html

Personalizar por URL customize-by-url

Se você permitir que os usuários alterem o tamanho da fonte (ou qualquer outra personalização de layout), verifique se as diferentes personalizações são refletidas no URL.

Por exemplo, os cookies não são armazenados em cache. Dessa forma, se você armazenar o tamanho da fonte em um cookie (ou mecanismo semelhante), o tamanho da fonte não será preservado para a página em cache. Como resultado, o Dispatcher retorna documentos de qualquer tamanho de fonte aleatoriamente.

Incluir o tamanho da fonte no URL como um seletor evita esse problema:

www.myCompany.com/news/main.large.html

Invalidar arquivos de imagem usados como títulos invalidating-image-files-used-as-titles

Se você renderizar títulos de página, ou outro texto, como imagens, é recomendável armazenar os arquivos para que eles sejam excluídos após uma atualização de conteúdo na página:

Por exemplo, você pode armazenar o título da página myPage.html no arquivo myPage.title.gif. Esse arquivo será automaticamente excluído se a página for atualizada, de modo que qualquer alteração no título da página será refletida automaticamente no cache.

Invalidar arquivos de imagem usados para navegação invalidating-image-files-used-for-navigation

Se você usar imagens para as entradas de navegação, o método é basicamente o mesmo com títulos, apenas ligeiramente mais complexos. Armazene todas as imagens de navegação com as páginas de destino. Se você usar duas imagens para o normal e o ativo, poderá usar os seguintes scripts:

É importante criar essas imagens com o mesmo identificador de nome da página, para garantir que uma atualização de conteúdo exclua essas imagens, bem como a página.

Para páginas que não são modificadas, as imagens ainda permanecem no cache, embora as próprias páginas sejam normalmente invalidadas automaticamente.

Personalização personalization

É recomendável limitar a personalização ao local necessário. Para ilustrar o motivo:

Se você personalizar cada página (por exemplo, colocando o nome do usuário na barra de título), isso pode afetar o desempenho.

Com relação à mistura de conteúdo restrito e público em uma página, você pode considerar uma estratégia que aproveita as inclusões do lado do servidor no Dispatcher ou as inclusões do lado do cliente por meio do Ajax no navegador.

Conexões adesivas sticky-connections

As conexões adesivas garantem que os documentos de um usuário sejam todos compostos no mesmo servidor. Se um usuário sair dessa pasta e posteriormente retornar a ela, a conexão ainda permanecerá. Defina uma pasta para armazenar todos os documentos que exigem conexões adesivas para o site. Tente não manter outros documentos nela. Isso impactará o balanceamento de carga se você usar páginas personalizadas e dados de sessão.

Tipos MIME mime-types

Há duas maneiras pelas quais um navegador pode determinar o tipo de arquivo:

Para a maioria dos arquivos, o tipo MIME está implícito na extensão de arquivo. Ou seja:

Se o nome do arquivo não tiver extensão, ele será exibido como texto sem formatação.

Com o Dispatcher versão 4.1.11, é possível armazenar em cache os cabeçalhos de resposta. Se você não armazenar em cache os cabeçalhos de resposta no Dispatcher, esteja ciente de que o tipo MIME faz parte do cabeçalho HTTP. Dessa forma, se o aplicativo de AEM retornar arquivos que não têm um arquivo reconhecido terminado e depender do tipo MIME, esses arquivos poderão ser exibidos incorretamente.

Para garantir que os arquivos sejam armazenados em cache corretamente, siga estas diretrizes:

Desempenho do backup backup-performance

Esta seção apresenta uma série de benchmarks usados para avaliar o desempenho de backups AEM e os efeitos da atividade de backup no desempenho do aplicativo. Um backup AEM apresenta uma carga significativa no sistema enquanto ele é executado, e nós medimos isso, bem como os efeitos das configurações de atraso de backup que tentam modular esses efeitos. O objetivo é oferecer alguns dados de referência sobre o desempenho esperado dos backups em configurações realistas e quantidades de dados de produção, além de fornecer orientação sobre como estimar os tempos de backup para sistemas planejados.

Ambiente de referência reference-environment

Sistema físico physical-system

Os resultados relatados neste documento foram obtidos a partir de benchmarks executados em um ambiente de referência com a seguinte configuração: Essa configuração foi projetada para ser semelhante a um ambiente de produção típico em um data center:

O subsistema de disco deste servidor é bastante rápido, representativo de uma configuração RAID de alto desempenho que pode ser usada em um servidor de produção. O desempenho do backup pode ser sensível ao desempenho do disco e os resultados neste ambiente refletem o desempenho em uma configuração RAID muito rápida. A imagem VMWare é configurada para ter um único grande volume de disco que reside fisicamente no armazenamento de disco local, na matriz RAID.

A configuração de AEM coloca o repositório e o armazenamento de dados no mesmo volume lógico, juntamente com todo o sistema operacional e software AEM. O diretório de destino para backups também reside neste sistema de arquivos lógico.

Volumes de dados data-volumes

A tabela a seguir ilustra o tamanho dos volumes de dados usados nos benchmarks de backup. O conteúdo da linha de base inicial é instalado pela primeira vez, e quantidades conhecidas de dados adicionais são adicionadas para aumentar o tamanho do conteúdo do backup. Os backups serão criados em incrementos específicos para representar um grande aumento no conteúdo e no que pode ser produzido em um dia. A distribuição de conteúdo (páginas, imagens, tags) será basicamente baseada na composição realista do ativo de produção. As páginas, imagens e tags serão limitadas a no máximo 800 páginas secundárias. Cada página incluirá componentes de título, Flash, texto/imagem, vídeo, apresentação de slides, formulário, tabela, nuvem e carrossel. As imagens serão carregadas de um pool de 400 arquivos exclusivos que variam de 37 kB a 594 kB.

O referencial de backup é repetido com os conjuntos de conteúdo adicionais adicionados a cada repetição.

Cenários de referência benchmark-scenarios

Os benchmarks de backup abrangem dois cenários principais: backups quando o sistema está sob carga significativa de aplicativos e backups quando o sistema está ocioso. Embora a recomendação geral seja que os backups sejam executados quando AEM estiver o mais ocioso possível, há situações em que é necessário que o backup seja executado quando o sistema estiver sob carregamento.

Os tempos de backup e o tamanho do backup resultante são obtidos dos registros do servidor de AEM. Normalmente, é recomendável que os backups sejam programados para horários off-times quando AEM estiver inativo, como no meio da noite. Esse cenário é representativo da abordagem recomendada.

O carregamento consistirá em criar/excluir páginas, navegações e consultas com a maioria da carga proveniente de passagens de página e consultas. Adicionar e remover muitas páginas continuamente aumenta o tamanho do espaço de trabalho e impede que as cópias de segurança sejam concluídas. A distribuição do carregamento que o script usará é 75% de passagens da página, 24% de consultas e 1% de criações de página (nível único sem subpáginas aninhadas). O pico médio de transações por segundo em um sistema ocioso é obtido com 4 threads simultâneos, que é o que será usado ao testar backups sob carga.

O impacto da carga no desempenho do backup pode ser estimado pela diferença entre o desempenho com e sem essa carga de aplicativo. O impacto do backup na taxa de transferência do aplicativo é encontrado comparando a taxa de transferência de cenário em transações por hora com e sem um backup simultâneo em andamento e com backups operando com diferentes configurações de "atraso de backup".

Resumo dos resultados summary-of-results

Tempo de backup e throughput backup-time-and-throughput

O principal resultado desses benchmarks é mostrar como os tempos de backup variam em função do tipo de backup e da quantidade geral de dados. O gráfico a seguir mostra o tempo de backup obtido usando a configuração de backup padrão, como uma função do número total de páginas.

Os tempos de backup em uma instância inativa são bastante consistentes, com uma média de 0,608 MB/s independentemente dos backups completos ou incrementais (consulte o gráfico abaixo). O tempo de backup é simplesmente uma função da quantidade de dados que estão sendo copiados em backup. O tempo para concluir um backup completo aumenta claramente com o número total de páginas. O tempo para concluir um backup incremental também aumenta com o número total de páginas, mas a uma taxa muito menor. O tempo necessário para concluir o backup incremental é muito menor devido à quantidade relativamente pequena de dados que estão sendo copiados em backup.

O tamanho do backup produzido é o principal determinante do tempo necessário para concluir um backup. O gráfico a seguir mostra o tempo gasto em função do tamanho final do backup.

Este gráfico ilustra que tanto os backups incrementais como completos seguem um padrão de tamanho e tempo simples que podemos medir como throughput. Os tempos de backup em uma instância inativa são bastante consistentes, com uma média de 0,61 MB/s independentemente dos backups completos ou incrementais no ambiente de benchmark.

Atraso de backup backup-delay

O parâmetro de atraso de backup é fornecido para limitar até que ponto os backups podem interferir nas cargas de trabalho de produção. O parâmetro especifica um tempo de espera em milissegundos, que é intercalado na operação de backup com base em arquivo por arquivo. O efeito geral depende em parte do tamanho dos arquivos afetados. Medir o desempenho do backup em MB/s fornece uma maneira razoável de comparar os efeitos do atraso no backup.

Para comparar, a taxa de transferência obtida usando um backup de sistema de arquivos (usando 'tar') para fazer backup dos mesmos arquivos de repositório. O desempenho do tar é comparável, mas ligeiramente maior que o backup com atraso definido como zero. A configuração de até mesmo um pequeno atraso reduz bastante a taxa de transferência de backup e o atraso padrão de 10 ms resulta em uma taxa de transferência muito reduzida. Em situações em que os backups podem ser programados quando o uso geral do aplicativo é muito baixo ou o aplicativo pode ficar completamente inativo, provavelmente é desejável reduzir o atraso abaixo do valor padrão para permitir que o backup continue mais rapidamente.

O impacto real do throughput do aplicativo de um backup contínuo depende dos detalhes do aplicativo e da infraestrutura. A escolha do valor de atraso deve ser feita por análise empírica do aplicativo, mas deve ser escolhida o mais pequeno possível, para que os backups possam ser concluídos o mais rápido possível. Como há apenas uma correlação fraca entre a escolha do valor de atraso e o impacto na taxa de transferência do aplicativo, a escolha do atraso deve favorecer tempos de backup gerais mais curtos, a fim de minimizar o impacto geral dos backups. Um backup que leva 8 horas para ser concluído, mas afeta a taxa de transferência em -20% provavelmente terá um impacto geral maior do que um, o que leva 2 horas para ser concluído, mas afeta a taxa de transferência em -30%.

Referências references