Ajuste de desempenho de ativos

Este artigo descreve as configurações e soluções comuns de ajuste de ativos que ajudariam a otimizar o desempenho dos ativos.

Otimizações de desempenho de ativos

• A Adobe recomenda habilitar o HTTPS porque muitas organizações têm firewalls que detectam tráfego HTTP, o que afeta negativamente os uploads e corrompe arquivos.

• Para upload de arquivos grandes, prefira conexões com fio em vez de sem fio.

• Desative a pesquisa por texto completo de arquivos binários via índice tika 

• Defina parâmetros ideais da JVM como para um exemplo abaixo e use o Java 8:

XX:+UseConcMarkSweepGC  = Enable Concurrent Mark Sweep (CMS) Collector-Doak.queryLimitInMemory=500000 -Doak.queryLimitReads=100000 -Dupdate.limit=250000 -Doak.fastQuerySize=true

• Ajustando as filas do Job Sling: O upload em massa de ativos grandes pode exigir muitos recursos. Por padrão, o número de encadeamentos simultâneos por fila de trabalhos é igual ao número de núcleos de CPU. Isso pode causar um impacto geral no desempenho e alto consumo de heap do Java. Recomenda-se não exceder 50% dos núcleos. Para alterar esse valor, vá para: http://:/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration e defina queue.maxparallel como um valor representando 50% dos núcleos da CPU do servidor que hospeda sua instância do AEM (por exemplo, para 8 núcleos de CPU, defina o valor como 4). 

• Ajuste o tamanho do cache para CQBufferedImageCache: Considere que você tem um sistema com um heap máximo (-Xmx param) de 5 GB, um conjunto Oak BlobCache de 1 GB e um cache de documentos de 2 GB. Nesse caso, o cache em buffer usa no máximo 1,25 GB e isso deixa apenas 0,75 GB de memória para picos inesperados. Eventualmente, a VM Java falha com OutOfMemoryErrors. Para resolver o problema, reduza o tamanho máximo configurado do cache de imagem em buffer. Ao fazer upload de grandes quantidades de ativos no Adobe Experience Manager, ajuste o tamanho do cache em buffer configurando-o por meio do console da Web OSGi.1. Vá para http://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache2. Defina a propriedade cq.dam.image.cache.max.memory em bytes, por exemplo, 1073741824 é 1 GB (1024 *1024 *1024 = 1 GB). Observação: a partir do AEM 6.1 SP1, se você estiver usando um nó sling: osgiConfig para configurar essa propriedade, certifique-se de definir o tipo de dados como Long. Consulte este artigo para obter mais detalhes sobre esse assunto.

• Ajuste o cacheSizeInMB ao usar o FileDataStore para uma porcentagem de seu heap disponível (um valor conservador seria 2% do heap máximo). Por exemplo, para 8-gigabyteheap:maxCachedBinarySize=1048576cacheSizeInMB=164, observe que maxCachedBinarySize está definido como 1MB (1048576) para que ele armazene em cache somente arquivos com tamanho máximo de 1 MB. Ajustar a um valor menor poderá fazer sentido. Ao lidar com um grande número de binários, a Adobe recomenda que seja usado um armazenamento de dados externo em vez dos armazenamentos de nó padrão para maximizar o desempenho. Além disso, a Adobe recomenda que você ajuste os seguintes parâmetros:

• maxCachedBinarySize=10485760

• cacheSizeInMB=4096

Atenção: A configuração do cacheSizeInMB poderá fazer com que o processo java fique sem memória, se estiver definido como muito alto. Por exemplo, se você tiver o tamanho de heap máximo configurado para 8 GB (-Xmx8g) e espera que o AEM e seu aplicativo utilizem um heap combinado de 4 GB, faria sentido definir cacheSizeInMB como 82, em vez de 164. O intervalo de 2 a 10% do heap máximo é uma configuração segura. No entanto, é altamente recomendável validar as alterações nessas configurações pelo teste de carga, enquanto monitora a utilização da memória.

• O workflow do DAM Update Asset contém um conjunto completo de etapas configuradas para tarefas, como a geração do PTIFF Scene7 e a integração do InDesign Server. No entanto, é possível que a maioria dos usuários não necessite de várias dessas etapas. A Adobe recomenda que você crie uma cópia personalizada do modelo de worflow do DAM Update Asset e remova todas as etapas desnecessárias. Nesse caso, atualize os inicializadores do DAM Update Asset para apontar para o novo modelo.

• Workflow temporário: Para otimizar cargas altas de ingestão, a Adobe sugere mudar o workflow do DAM Update e do XMP Metadata Writeback para um workflow temporário. Como o nome indica, os dados de tempo de execução relacionados às etapas de trabalho intermediárias em workflows temporários não são mantidos no JCR quando são executados (as rendições de saída persistem, é claro). Isso causa uma redução de 10% no tempo de processamento do workflow e reduz significativamente o aumento do repositório. Workflows CRUD não são mais necessários para eliminação. Além disso, o número de arquivos TAR a serem compactados é reduzido. Se a sua empresa determina a persistência / arquivamento de dados de tempo de execução de worklfows de para fins de auditoria, não ative esse recurso.

• Geração de rendição seletiva: Gere apenas as renderizações necessárias, adicionando condições ao workflow de processamento de ativos, para que renderizações mais dispendiosas sejam geradas somente para ativos selecionados./workflow/ Dam Update Asset >> Etapa de Processamento de miniaturas.

• Armazenamento de dados compartilhados entre instâncias: A implementação de um S3 ou armazenamento de dados compartilhados poderá ajudar a economizar espaço em disco e aumentar o rendimento da rede em implementações de grande escala. No entanto, poderá haver outra tarefa adicional na manutenção de tal implantação. Mas isso pode ser uma boa compensação para um melhor desempenho.

• Manutenção: Normalmente, você deve executar workflows de limpeza semanalmente. No entanto, em cenários com uso intensivo de recursos, como durante o processamento de ativos em larga escala, você poderá executá-lo com mais frequência.