性能基准测试
上次更新日期：2026/10/14QV2QS 批量转换可跨多个 CPU 核心进行扩展。以下基准测试衡量了在固定数据集上不同 worker 数量下的端到端性能。
测试环境
基准数据集包含 28 个 QlikView 应用程序，共有 234 个工作表和 5,377 个对象。所有 PRJ 文件夹均在基准测试运行前预先生成。每次运行都将所有 28 个应用程序部署到 Qlik Cloud，并启用了重新加载和自动二进制加载。
测试机拥有 12 个逻辑 CPU 核心。QV2QS 在本地转换中使用进程池（真正的 CPU 并行），在云部署中使用线程池（I/O 密集型）。
端到端结果
每列代表一个 Worker 数量。这些行细分了构成端到端总计的两个先后阶段——本地转换和云部署。
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
- 已用时间 — 本地转换的挂钟时间：PRJ XML 解析、对象图遍历以及 QS JSON 生成。
- CPU 时间 — 转换期间所有工作进程消耗的累计 CPU 时间。CPU 时间会随着 worker 数量的增加而增长，因为每增加一个进程都会带来调度和内存开销。
- 云 — 云部署的挂钟时间：应用程序创建、媒体上传、构建、重新加载和二进制加载。
- 总计 — 端到端实际耗时（转换耗时 + 云端）。
伸缩行为
- 本地转换可线性扩展，最高可达 CPU 核心数。在 12 核机器上，将 worker 数量从 1 增加到 10 可将转换时间缩短 70%。
- 云部署会随线程数进行扩展，因为工作属于 I/O 密集型（对 Qlik Cloud API 的网络请求）。云阶段耗时从 1 个 worker 时的 19 分钟降至 10 个 worker 时的 3 分钟。
- 超过 CPU 核心数后，增加额外的 worker 进程只会增加进程调度开销，而不会带来任何实质性的提升。20 个 worker 和 30 个 worker 的运行速度比 15 个 worker 的运行更慢。
- 在这台 12 核机器上，峰值吞吐量出现在大约 15 个 worker 时（5.8 倍加速比）。核心数减一的自动检测默认值（11 个 worker，5.1 倍加速比）与峰值性能相差在 12% 以内，且不会产生超额订阅惩罚。
- CPU 时间随 Worker 数量的增加而稳步增长。在 11 个 worker 时，转换消耗了 7 分 13 秒的累计 CPU 时间。在 30 个 worker 的情况下，相同的工作耗时 10 分 18 秒——CPU 开销增加了 43%，而实际耗时却没有任何改善。
信息注释
云阶段包括为每个应用程序使用二进制加载进行重新加载。云端时间取决于应用程序数据量、重新加载复杂性、租户负载和 Qlik Cloud 引擎分配。规模更大的应用程序或更繁忙的租户产生的云时间会比此处显示的更长。
云部署并发
Qlik Cloud 对每个租户的并发重新加载数量实施限制。当批量部署以较高的 Worker 数量运行时，超过租户限制的重新加载请求将在服务器端排队。一旦达到并发重新加载限制，无论本地 CPU 和线程资源如何，云阶段的加速效果都会趋于平稳。
有关租户级别限制的详细信息，请参阅 Qlik Cloud 资源限制。有关 Qlik Cloud 容量护栏的完整规格，请参阅 Qlik Cloud 规格和容量护栏。