Pruebas comparativas de rendimiento
Última actualización: 14/10/2026La conversión por lotes de QV2QS escala en múltiples núcleos de CPU. Las siguientes pruebas de rendimiento miden el rendimiento de extremo a extremo para diferentes cantidades de workers en un conjunto de datos fijo.
Entorno de pruebas
El conjunto de datos de referencia contiene 28 aplicaciones QlikView con 234 hojas y 5.377 objetos. Todas las carpetas PRJ se pregeneraron antes de las ejecuciones del benchmark. Cada ejecución desplegó las 28 aplicaciones en Qlik Cloud con la recarga y la carga binaria automática habilitadas.
La máquina de pruebas cuenta con 12 núcleos lógicos de CPU. QV2QS utiliza un grupo de procesos para la conversión local (paralelismo real de CPU) y un grupo de subprocesos para el despliegue en la nube (limitado por E/S).
Resultados de extremo a extremo
Cada columna es un recuento de trabajadores. Las filas desglosan las dos fases secuenciales —conversión local y despliegue en la nube— que componen el total de extremo a extremo.
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
- Transcurrido — Tiempo de reloj para la conversión local: análisis sintáctico del XML de PRJ, recorrido del grafo de objetos y generación del JSON de QS.
- Tiempo de CPU — Tiempo de CPU acumulado consumido por todos los procesos de trabajo durante la conversión. El tiempo de CPU aumenta con el número de workers porque cada proceso adicional añade sobrecarga de planificación y memoria.
- Nube — Tiempo transcurrido para el despliegue en la nube: creación de la aplicación, subida de contenido multimedia, compilación, recarga y carga de binarios.
- Total — Tiempo de reloj de extremo a extremo (tiempo transcurrido de conversión + Nube).
Comportamiento de escalado
- La conversión local escala linealmente hasta el número de núcleos de la CPU. Pasar de 1 a 10 workers en una máquina de 12 núcleos reduce el tiempo de conversión en un 70 %.
- El despliegue en la nube escala con el número de subprocesos porque el trabajo está limitado por E/S (solicitudes de red a la API de Qlik Cloud). La fase en la nube se reduce de 19 minutos con 1 worker a 3 minutos con 10 workers.
- Más allá del número de núcleos de la CPU, los workers adicionales añaden una sobrecarga de planificación de procesos sin ninguna mejora significativa. Las ejecuciones con 20 y 30 trabajadores son más lentas que la ejecución con 15 trabajadores.
- El rendimiento máximo se alcanza con aproximadamente 15 workers en esta máquina de 12 núcleos (una aceleración de 5,8x). El valor predeterminado de detección automática de núcleos menos uno (11 workers, aceleración de 5,1x) se encuentra a menos de un 12 % del pico sin penalización por sobresuscripción.
- El tiempo de CPU aumenta de forma constante con el número de workers. Con 11 workers, la conversión consume 7m 13s de tiempo de CPU acumulado. Con 30 workers, el mismo trabajo consume 10m 18s — un aumento del 43 % en el coste de CPU sin ninguna mejora en el tiempo de reloj.
La fase en la nube incluye una recarga mediante carga binaria para cada aplicación. Los tiempos en la nube dependen del volumen de datos de la app, la complejidad de la recarga, la carga del inquilino y la asignación del motor de Qlik Cloud. Las aplicaciones más grandes o los inquilinos con mayor actividad generarán tiempos en la nube más prolongados que los mostrados aquí.
Concurrencia de despliegue en la nube
Qlik Cloud aplica un límite al número de recargas simultáneas por inquilino. Cuando el despliegue por lotes se ejecuta con un número elevado de workers, las solicitudes de recarga que superan el límite del inquilino se ponen en cola en el lado del servidor. La aceleración de la fase en la nube se estabiliza una vez que se alcanza el límite de recargas simultáneas, independientemente de los recursos locales de CPU y subprocesos.
Para obtener detalles sobre los límites a nivel de inquilino, consulte Límites de recursos de Qlik Cloud. Para consultar la especificación completa de los límites de capacidad de Qlik Cloud, consulte Especificaciones y límites de capacidad de Qlik Cloud.