Benchmarks de performance
Dernière mise à jour : 14/10/2026La conversion par lots QV2QS passe à l'échelle sur plusieurs cœurs de processeur. Les benchmarks ci-dessous mesurent les performances de bout en bout pour différents nombres de workers sur un jeu de données fixe.
Environnement de test
Le jeu de données de référence contient 28 applications QlikView avec 234 feuilles et 5 377 objets. Tous les dossiers PRJ ont été prégénérés avant l'exécution des benchmarks. Chaque exécution a déployé l'ensemble des 28 applications sur Qlik Cloud avec le rechargement et le chargement du binaire automatique activés.
La machine de test possède 12 cœurs CPU logiques. QV2QS utilise un pool de processus pour la conversion locale (véritable parallélisme CPU) et un pool de threads pour le déploiement cloud (limité par les E/S).
Résultats de bout en bout
Chaque colonne correspond à un nombre de workers. Les lignes décomposent les deux phases séquentielles — conversion locale et déploiement cloud — qui constituent le total de bout en bout.
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
- Temps écoulé — Temps réel pour la conversion locale : analyse syntaxique du XML PRJ, parcours du graphe d'objets et génération du JSON QS.
- Temps processeur — Temps processeur cumulé consommé par l'ensemble des processus de travail lors de la conversion. Le temps processeur augmente avec le nombre de workers, car chaque processus supplémentaire ajoute une surcharge d'ordonnancement et de mémoire.
- Cloud — Temps réel pour le déploiement cloud : création de l'application, téléversement des médias, build, rechargement et chargement du binaire.
- Total — Temps réel de bout en bout (temps de conversion écoulé + Cloud).
Comportement de mise à l'échelle
- La conversion locale évolue de manière linéaire jusqu'au nombre de cœurs de processeur. Passer de 1 à 10 workers sur une machine à 12 cœurs réduit le temps de conversion de 70 %.
- Le déploiement Cloud évolue en fonction du nombre de threads car le travail est limité par les E/S (requêtes réseau vers l'API Qlik Cloud). La phase cloud passe de 19 minutes avec 1 worker à 3 minutes avec 10 workers.
- Au-delà du nombre de cœurs du processeur, les workers supplémentaires ajoutent une surcharge d'ordonnancement des processus sans amélioration significative. Les exécutions à 20 et 30 workers sont plus lentes que l'exécution à 15 workers.
- Le débit maximal est atteint avec environ 15 workers sur cette machine à 12 cœurs (accélération de 5,8x). La valeur par défaut de détection automatique, soit le nombre de cœurs moins un (11 workers, accélération de 5,1x), se situe à moins de 12 % du pic sans pénalité de sursouscription.
- Le temps processeur augmente régulièrement avec le nombre de workers. Avec 11 workers, la conversion consomme 7m 13s de temps CPU cumulé. Avec 30 workers, le même travail consomme 10m 18s — soit une augmentation de 43 % du coût CPU sans aucune amélioration du temps d'horloge.
La phase cloud inclut un rechargement utilisant un chargement du binaire pour chaque application. Les durées dans le cloud dépendent du volume de données de l'application, de la complexité du rechargement, de la charge du client et de l'allocation du moteur Qlik Cloud. Les applications plus volumineuses ou les tenants plus actifs généreront des temps cloud plus longs que ceux présentés ici.
Simultanéité des déploiements cloud
Qlik Cloud applique une limite au nombre de rechargements simultanés par client. Lorsqu'un déploiement par lots s'exécute avec un nombre élevé de workers, les requêtes de rechargement qui dépassent la limite du client sont mises en file d'attente côté serveur. L'accélération de la phase cloud plafonne une fois la limite de rechargements simultanés atteinte, indépendamment des ressources locales en CPU et en threads.
Pour plus de détails sur les limites au niveau du client, consultez Limites de ressources Qlik Cloud. Pour obtenir les spécifications complètes des garde-fous de capacité de Qlik Cloud, consultez Spécifications et garde-fous de capacité de Qlik Cloud.