Otimização do desempenho performance-optimization

Um problema importante é o tempo que o site leva para responder às solicitações do visitante. Embora esse valor varie para cada solicitação, um valor de target médio pode ser definido. Quando esse valor puder ser obtido e mantido, ele poderá ser usado para monitorar o desempenho do site e indicar o desenvolvimento de possíveis problemas.

Os tempos de resposta almejados sã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 conteúdo. Ele deve atender a alguns usuários, cada um deles gerando um alto número de solicitações de desempenho intensivo 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 os usuários. Aqui, o número de solicitações é ainda maior e a velocidade é tão vital. Mas como a natureza das solicitações é menos dinâmica, mecanismos adicionais de aprimoramento de desempenho podem ser aplicados, como armazenamento em cache de conteúdo ou balanceamento de carga.

Metodologia de otimização de desempenho performance-optimization-methodology

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

Essas regras se aplicam aos projetos da Web em geral e são relevantes para os gerentes de projetos e administradores de sistema, a fim de garantir que seus projetos não enfrentem desafios de desempenho na hora do lançamento.

Planejamento para otimização planning-for-optimization

Planeje cerca de 10% do esforço do projeto para a fase de otimização de desempenho. Os requisitos reais de otimização de desempenho dependem 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 o tempo alocado, é uma boa prática planejar sempre a otimização de desempenho na região sugerida.

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

Depois que você estiver "ao vivo", a otimização do desempenho não termina. Agora é quando você enfrenta a carga "real" em seu sistema. É importante planejar ajustes adicionais após o lançamento.

Como a carga do seu sistema muda e os perfis de desempenho do seu sistema mudam com o tempo, um "ajuste" ou "verificação de integridade" de desempenho deve ser programado em intervalos de 6 a 12 meses.

Simular Realidade simulate-reality

Se você acessar um site e descobrir, após o lançamento, que teve problemas de desempenho, é provável que seus testes de carga e desempenho não tenham simulado a realidade de maneira suficientemente precisa.

Simular a realidade é difícil e quanto esforço você quer investir para ficar "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 ao tamanho e à estrutura do conteúdo. Seus modelos podem se comportar de forma diferente dependendo do tamanho e da estrutura do repositório.

Estabelecer metas sólidas establish-solid-goals

Não se deve subestimar a importância de estabelecer corretamente os objetivos de desempenho. Muitas vezes, depois que as pessoas se concentram em metas de desempenho específicas, é difícil alterar essas metas posteriormente, mesmo que elas se baseiem em suposições.

Estabelecer metas de desempenho boas e sólidas é realmente uma das áreas mais complicadas. Geralmente, é melhor coletar logs da vida real e benchmarks 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, poderá perder o controle de qual medida de otimização ajudou.

Ciclos de iteração Agile agile-iteration-cycles

O ajuste de desempenho é um processo iterativo que envolve análise, otimização e validação até que a meta seja atingida. Para levar em conta esse aspecto, 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.

Esse foco significa que o desenvolvedor que implementa a otimização deve ter uma maneira rápida de saber se a otimização já atingiu a meta. Essas informações são importantes porque, quando a meta é atingida, a otimização é finalizada.

Diretrizes básicas de desempenho basic-performance-guidelines

De modo geral, mantenha suas solicitações de html não armazenadas em cache em menos de 100 milissegundos. Mais especificamente, podem servir de orientação os seguintes elementos:

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

Há alguns problemas que contribuem frequentemente para problemas de desempenho, incluindo os seguintes:

O ajuste do nível de JVM e SO geralmente não resulta em saltos significativos no desempenho e, portanto, deve ser executado no final do ciclo de otimização.

A forma como um repositório de conteúdo é estruturado também pode afetar o desempenho. Para obter o 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).

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

Desempenho ao carregar e editar o Digital Assets 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.

Dois itens 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 os usuários notam, de modo que com qualquer aplicativo com interface do usuário, o desempenho é de importância fundamental. Para otimizar o desempenho da instalação do AEM, monitore vários atributos da instância e seu comportamento.

Para obter informações sobre como executar o monitoramento do desempenho, consulte Monitoramento do Desempenho.

Os problemas que causam problemas de desempenho geralmente são difíceis de rastrear, 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 a aparência e o comportamento do seu ambiente quando ele funciona corretamente, é difícil localizar o problema quando o desempenho piora. Gaste tempo investigando o sistema quando ele estiver funcionando sem problemas e garanta que a coleta de informações de desempenho seja uma tarefa contínua. Isso fornece uma base de 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 diferentes elementos que podem afetar o desempenho.

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

O desempenho pode ser ilustrado em vários locais na cadeia da Web.

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

Regras Básicas De Desempenho basic-rules-regarding-performance

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

Configuração do para desempenho configuring-for-performance

Certos aspectos do AEM (e/ou do repositório subjacente) podem ser configurados para otimizar o desempenho. Veja a seguir possibilidades e sugestões. Certifique-se de usar a funcionalidade em questão ou de como usá-la 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

Para melhorar o desempenho, limite o número de processos de workflow em execução simultânea. Por padrão, o motor 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), a execução de 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 têm alta resolução e podem consumir facilmente centenas de MB de heap para processamento. O manuseio dessas imagens em paralelo coloca uma alta carga no subsistema de memória e no coletor de lixo.

O mecanismo de fluxo de trabalho usa as filas de trabalho do Apache Sling para manipular e agendar o processamento do item de trabalho. Os seguintes serviços de fila de trabalhos foram criados por padrão na fábrica do serviço de configuração da fila de trabalhos do Apache Sling para processar trabalhos de fluxo de trabalho:

Configure esses serviços para limitar o número máximo de processos de fluxo de trabalho simultâneos.

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

Se você estiver configurando os serviços usando um nó sling:OsgiConfig, localize 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.

Configure 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 de Configuração da Fila de Trabalhos do Apache Sling.

Configure 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 poder configurar o manuseio de trabalhos para esse modelo de fluxo de trabalho. Dessa forma, suas configurações afetam o processamento de um workflow específico, enquanto a configuração da Fila de workflow padrão do Granite controla o processamento de outros workflows.

Quando os 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 fluxos de trabalho do Granite ou a Fila de trabalho do processo externo do Granite:

Os tópicos de trabalho reais que os modelos de fluxo de trabalho geram incluem o sufixo específico do modelo. Por exemplo, o modelo de fluxo de trabalho Ativo de atualização do 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 trabalho do seu modelo de fluxo de trabalho. A configuração das propriedades relacionadas ao desempenho da fila afeta somente o modelo de fluxo de trabalho que gera as tarefas 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 do DAM como exemplo.

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

O AssetSynchronizationService é usado para sincronizar ativos de repositórios montados (incluindo LiveLink, Documentum®, entre outros). Por padrão, essa sincronização 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.

A desabilitação do serviço é feita por configuração do serviço OSGi Serviço de Sincronização de Ativos DAM CQ para definir o Período de sincronização ( scheduler.period) para (no mínimo) um ano (definido em segundos).

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

A implantação de várias instâncias do DAM pode ajudar no desempenho quando, por exemplo:

Outras considerações são:

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

O desempenho é de suma importância para o ambiente de publicação. Portanto, você deve planejar e analisar cuidadosamente os testes de desempenho feitos 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 no seu ambiente publicar. Essas informações são de interesse principalmente para engenheiros de controle de qualidade, gerentes de projeto e administradores de sistema.

O documento a seguir aborda uma abordagem padronizada para testes de desempenho de um aplicativo AEM no ambiente Publish. Este teste de desempenho envolve as cinco fases a seguir:

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

Verificação do conhecimento verification-of-knowledge

Uma primeira etapa é documentar as informações básicas que você deve saber antes de iniciar o teste:

Arquitetura de teste test-architecture

Documente a arquitetura do ambiente de teste que está sendo usado para seu teste de desempenho.

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

Mapa de aplicativos application-map

Obtenha uma visão geral clara a partir da qual é possível criar um mapa do aplicativo inteiro (talvez você já tenha esse mapa a partir de testes no ambiente do Autor).

Uma representação de diagrama dos elementos internos do aplicativo pode fornecer uma visão geral dos requisitos de teste; com a codificação por cores, também pode servir como base para os relatórios.

Definição do escopo scope-definition

Um aplicativo geralmente tem uma seleção de casos de uso. Alguns casos de uso são importantes, outros menos.

Para focalizar o escopo do teste de desempenho em publicação, a Adobe recomenda que você defina o seguinte:

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

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

Metodologias de teste test-methodologies

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

Com base nos seguintes princípios:

Pontos de interrupção do componente component-breakpoints

Transações transactions

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

Após o escopo e os KPIs relacionados serem definidos, as metas de desempenho específicas são definidas. Esse processo envolve a concepção de cenários de teste, juntamente com valores de destino.

Testar o desempenho em condições médias e de pico. Além disso, você precisa de testes de cenário de ativação para garantir que possa atender ao aumento do interesse no 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 metas futuras. Por exemplo, tráfego superior no seu site ativo.

Testes de componente único single-component-tests

Os componentes críticos devem ser ensaiados tanto em condições de média como de pico.

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

Testes de componente combinado combined-component-tests

Testar os componentes em combinação faz com que o comportamento dos aplicativos se reflita melhor. Mais uma vez, as condições médias e de pico devem ser testadas.

Testes de ativação going-live-tests

Durante os primeiros dias após o site ser disponibilizado, você pode esperar um aumento no nível de interesse. Esse cenário é ainda maior do que os valores de pico que você está testando. A Adobe recomenda testar os cenários de ativação para garantir que o sistema possa atender a essa situação.

Testes de Cenário de Erro error-scenario-tests

Teste cenários de erro para garantir que o sistema reaja corretamente e adequadamente. Não apenas em como o erro em si é tratado, mas o impacto que ele pode ter no desempenho. Por exemplo:

Ao conceber estes testes, deve-se lembrar que nem todos os cenários ocorrem regularmente. No entanto, seu impacto em todo o sistema é importante.

Testes de resistência endurance-tests

Certos problemas só são encontrados depois que o sistema é executado por um período de tempo contínuo, seja em horas ou dias. Um teste de resistência é usado 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 da implementação, otimize o aplicativo para atender e maximizar as metas de desempenho.

Quaisquer otimizações feitas devem ser testadas para garantir que tenham:

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

Após a otimização, teste novamente para confirmar o impacto.

Relatório reporting

Relatórios contínuos mantêm todos informados sobre o status. Como mencionado anteriormente com a codificação por cores, o mapa da arquitetura pode ser usado para esse status.

Após a conclusão de todos os testes, relatar o seguinte:

Otimização do desempenho ao usar o Dispatcher optimizing-performance-when-using-the-dispatcher

O Dispatcher é uma ferramenta de armazenamento em cache e/ou balanceamento de carga Adobe. Ao usar o Dispatcher, considere otimizar seu site para o desempenho do cache.

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

Cálculo da taxa de cache do Dispatcher calculating-the-dispatcher-cache-ratio

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

A fórmula para calcular a proporção do cache é:

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

Se você não tiver um emparelhamento de editor/dispatcher um para um, adicione 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 a versão 4.1.11 do Dispatcher, você pode armazenar em cache 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 em file 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, mas ligeiramente mais complexo. 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 e 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 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 colocando o nome do usuário na barra de título (por exemplo), isso terá um impacto no desempenho.

Em relação à combinação de conteúdo restrito e público em uma página, considere uma estratégia que use inclusões do lado do servidor no Dispatcher ou 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á. Para armazenar todos os documentos que exigem conexões adesivas para o site, defina uma pasta. Tente não manter outros documentos nela. Esse cenário afeta 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 a versão 4.1.11 do Dispatcher, você pode armazenar em cache cabeçalhos de resposta. Se você não armazenar cabeçalhos de resposta em cache no Dispatcher, o tipo MIME fará parte do cabeçalho HTTP. Dessa forma, se o aplicativo AEM retornar arquivos que não têm um final de arquivo reconhecido 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 por AEM e os efeitos da atividade de backup sobre o desempenho do aplicativo. Os backups por AEM apresentam uma carga significativa no sistema enquanto ele é executado, e o Adobe mede esse impacto e 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, e 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 de benchmarks executados em um ambiente de referência com a seguinte configuração: Essa configuração é semelhante a um ambiente de produção típico em um data center:

O subsistema de discos neste servidor é 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 nesse ambiente refletem o desempenho em uma configuração RAID rápida. A imagem VMWare é configurada para ter um único grande volume de disco que reside fisicamente no armazenamento de disco local, no array RAID.

A configuração do AEM coloca o repositório e o armazenamento de dados no mesmo volume lógico, juntamente com o sistema operacional e o software AEM. O diretório de destino para backups também reside nesse 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 inicial da linha de base é instalado primeiro e, em seguida, quantidades adicionais conhecidas de dados são adicionadas para aumentar o tamanho do conteúdo de backup. Os backups são criados em incrementos específicos para representar um grande aumento no conteúdo e o que pode ser produzido em um dia. A distribuição de conteúdo (páginas, imagens, tags) baseia-se aproximadamente na composição realista do ativo de produção. Páginas, imagens e tags são limitadas a no máximo 800 páginas secundárias. Cada página inclui componentes de título, Flash, texto/imagem, vídeo, apresentação de slides, formulário, tabela, nuvem e carrossel. As imagens são carregadas de um pool de 400 arquivos exclusivos com tamanho de 37 KB a 594 KB.

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

Cenários de benchmark 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 o AEM estiver o mais ocioso possível, há situações em que é necessário que o backup seja executado quando o sistema estiver sob carga.

Os tempos de backup e o tamanho do backup resultante são obtidos dos registros do servidor AEM. Normalmente, recomenda-se que os backups sejam agendados para períodos fora do horário de expediente quando o AEM estiver ocioso, por exemplo, no meio da noite. Este cenário é representativo da abordagem recomendada.

O carregamento consiste em páginas criadas, páginas excluídas, percursos e consultas com a maioria das cargas provenientes de percursos e consultas de página. Adicionar e remover muitas páginas aumenta continuamente o tamanho do espaço de trabalho e impede que os backups sejam concluídos. A distribuição de carga que o script usa é de 75% de percursos de página, 24% de consultas e 1% de criações de página (nível único sem subpáginas aninhadas). A média de pico de transações por segundo em um sistema ocioso é alcançada com quatro threads simultâneos, que são usados ao testar backups sob carga.

O impacto da carga no desempenho de backup pode ser estimado pela diferença entre o desempenho com e sem essa carga de aplicativo. O impacto do backup no throughput do aplicativo é encontrado ao comparar o throughput do cenário em transações por hora com e sem um backup simultâneo em andamento e com backups em operação com diferentes configurações de "atraso de backup".

Resumo dos resultados summary-of-results

Tempo e throughput do backup 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, em função do número total de páginas.

Os tempos de backup em uma instância ociosa são bastante consistentes, com uma média de 0,608 MB por segundo, independentemente de backups completos ou incrementais (consulte o gráfico abaixo). O tempo de backup é simplesmente uma função do volume de dados do backup. O tempo para concluir um backup completo aumenta claramente de acordo 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 em uma taxa muito menor. O tempo necessário para concluir o backup incremental é muito menor devido à quantidade relativamente pequena de dados cujo backup está sendo feito.

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 quanto os completos seguem um padrão simples de tamanho e tempo que o Adobe pode medir como throughput. Os tempos de backup em uma instância ociosa são bastante consistentes, com uma média de 0,61 MB por segundo, independentemente de backups completos ou incrementais no ambiente de benchmark.

Atraso de backup backup-delay

O parâmetro de atraso de backup é fornecido para limitar a extensão em que os backups podem interferir nas cargas de trabalho de produção. O parâmetro especifica um tempo de espera em milissegundos, que é alternado para a operação de backup em cada arquivo. O efeito geral depende em parte do tamanho dos arquivos afetados. A medição do desempenho do backup em MB/s oferece uma maneira razoável de comparar os efeitos do atraso no backup.

Para comparação, o throughput obtido usando um backup do sistema de arquivos ("tar") para fazer backup dos mesmos arquivos do repositório. O desempenho do tar é comparável, mas ligeiramente superior ao do backup com atraso definido como zero. Mesmo um pequeno atraso reduz muito o throughput de backup, e o atraso padrão de 10 milissegundos resulta em um throughput bastante reduzido. Em situações em que os backups podem ser programados quando o uso geral do aplicativo for baixo ou o aplicativo puder estar ocioso, reduza o atraso abaixo do valor padrão para permitir que o backup prossiga mais rapidamente.

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

Referências references