Benchmarks de desempenho | Centro de migração Ajuda
Ir para conteúdo principal Pular para conteúdo complementar

Benchmarks de desempenho

Última atualização: 14/10/2026

A conversão em lote do QV2QS escala em múltiplos núcleos de CPU. Os benchmarks abaixo medem o desempenho de ponta a ponta em uma variedade de contagens de workers em um conjunto de dados fixo.

Ambiente de teste

O conjunto de dados de benchmark contém 28 aplicativos QlikView com 234 pastas e 5.377 objetos. Todas as pastas PRJ foram pré-geradas antes das execuções do benchmark. Cada execução implantou todos os 28 aplicativos no Qlik Cloud com recarga e carga binária automática habilitadas.

A máquina de teste possui 12 núcleos lógicos de CPU. O QV2QS usa um pool de processos para conversão local (verdadeiro paralelismo de CPU) e um pool de threads para implementação na nuvem (I/O-bound).

Resultados de ponta a ponta

Cada coluna é uma contagem de workers. As linhas detalham as duas fases sequenciais — conversão local e implementação na nuvem — que compõem o total de ponta a ponta.

                       1w       5w      10w    ▸ 11w    ▸ 15w      20w      25w      30w
                ────────────────────────────────────────────────────────────────────────

Conversion
  Elapsed          4m 28s   1m 30s   1m 22s   1m 15s   1m 06s   1m 11s   1m 11s   1m 13s
  CPU time         3m 25s   5m 12s   8m 01s   7m 13s   7m 41s   8m 58s  10m 09s  10m 18s

Cloud             19m 12s   4m 32s   3m 26s   3m 23s   3m 00s   3m 00s   3m 09s   3m 13s
                ────────────────────────────────────────────────────────────────────────
Total             23m 40s   6m 02s   4m 48s   4m 38s   4m 06s   4m 11s   4m 20s   4m 26s
Speedup              1.0x     3.9x     4.9x     5.1x     5.8x     5.7x     5.5x     5.3x

▸ 11w = Auto-detect default (cores − 1)
▸ 15w = Observed peak
  • Decorrido — Tempo de relógio para a conversão local: análise do XML do PRJ, travessia do grafo de objetos e geração do JSON do QS.
  • Tempo de CPU — Tempo de CPU acumulado consumido por todos os processos de trabalho durante a conversão. O tempo de CPU aumenta com o número de workers porque cada processo adicional adiciona sobrecarga de escalonamento e de memória.
  • Nuvem — Tempo decorrido para implementação na nuvem: criação de aplicativo, upload de mídia, build, recarregamento e carga binária.
  • Total — Tempo de relógio de ponta a ponta (Conversão decorrida + Nuvem).

Comportamento de dimensionamento

  • A conversão local escala linearmente até o número de núcleos de CPU. Passar de 1 para 10 workers em uma máquina de 12 núcleos reduz o tempo de conversão em 70%.
  • A implementação na nuvem escala com a contagem de threads porque o trabalho é limitado por E/S (solicitações de rede para a API do Qlik Cloud). A fase de nuvem cai de 19 minutos com 1 worker para 3 minutos com 10 workers.
  • Além do número de núcleos da CPU, workers adicionais geram sobrecarga de escalonamento de processos sem nenhuma melhoria significativa. As execuções com 20 workers e 30 workers são mais lentas do que a execução com 15 workers.
  • O throughput de pico ocorre com aproximadamente 15 workers nesta máquina de 12 núcleos (aceleração de 5,8x). O padrão de detecção automática de núcleos menos um (11 workers, speedup de 5,1x) fica dentro de 12% do pico sem penalidade por sobrealocação.
  • O tempo de CPU aumenta de forma constante com o número de workers. Com 11 workers, a conversão consome 7m 13s de tempo de CPU acumulado. Com 30 workers, o mesmo trabalho consome 10m 18s — um aumento de 43% no custo de CPU sem nenhuma melhoria no tempo de relógio.
Nota informativa

A fase da nuvem inclui uma recarga usando carga binária para cada aplicativo. Os tempos na nuvem dependem do volume de dados do aplicativo, da complexidade da recarga, da carga do locatário e da alocação do mecanismo do Qlik Cloud. Aplicações maiores ou locatários mais ocupados produzirão tempos de nuvem mais longos do que os mostrados aqui.

Concorrência de implementação na nuvem

O Qlik Cloud impõe um limite ao número de recargas simultâneas por locatário. Quando a implementação em lote é executada com uma alta contagem de workers, as solicitações de recarregamento que excedem o limite do locatário são enfileiradas no lado do servidor. A aceleração da fase de nuvem atinge um patamar assim que o limite de recarregamento simultâneo é atingido, independentemente dos recursos locais de CPU e threads.

Para obter detalhes sobre limites no nível do locatário, consulte Limites de recursos do Qlik Cloud. Para obter a especificação completa dos limites de proteção de capacidade do Qlik Cloud, consulte Especificações e limites de proteção de capacidade do Qlik Cloud.

Saiba mais

Visit the discussion forum at community.qlik.com

Esta página ajudou?

Se você encontrar algum problema com esta página ou seu conteúdo – um erro de digitação, uma etapa ausente ou um erro técnico – avise-nos!