如何选择更适合虚幻引擎的版本控制系统？Perforce P4与Lore基准测试对比
本文来源Perforce 官方博客，由 Perforce 中国授权合作伙伴——龙智（DragonSoft Digital，简称DSD）编译整理。
原作者 Robert Cowham 是 Perforce 首席顾问，也是 P4 专业服务团队的技术负责人，对 P4 平台拥有十余年的咨询经验。
在日常工作中，他经常为团队提供咨询，帮助对比虚幻引擎版本控制的性能，并评估 Perforce P4 是否适合其项目。基于这些交流，他开发了一套可重复使用的框架，供其他人能够客观地将 Perforce P4 与其他版本控制系统进行基准测试对比。
在本文中，Robert Cowham 解释了为什么虚幻引擎版本控制的性能应当针对真实的项目需求进行测试，概述了用于对 P4 和 Lore 进行基准测试的 AWS 环境和文件数据集，并分享了复现该测试所需的命令和配置细节。他还在文中讨论了这些结果对于为虚幻引擎项目选择版本控制的团队意味着什么。
以下为全文内容，供国内游戏开发与版本控制相关团队参考。
Perforce P4 与 Lore 基准测试的关键结论
Lore 是 Epic Games 此前在Unreal Fest Chicago上发布的一款版本控制系统。Robert 团队收到了关于Lore的一些疑问，因此想通过实际数据来了解它的性能。
为了评估 P4 和 Lore 系统在真实虚幻引擎工作负载下的表现，Robert 使用了一个中等规模的虚幻引擎数据集，并对两个平台进行了测试，衡量了常见的版本控制操作，包括添加（add）、提交（submit）、同步（sync）和克隆（clone）。
基准测试的关键结论总结如下：
通过Perforce的服务器部署包（SDP）配置的 P4 服务器，在提交合理大小的文件时，速度比 Lore 快 2.7 倍。
对于初始拉取（在 P4 中称为“同步”，在 Lore 中称为“克隆”），P4 和 Lore 的速度相近，但 Lore 占用的内存几乎是P4的 14 倍。
如何对虚幻引擎版本控制性能进行基准测试？
虚幻引擎已成为各行业创建沉浸式体验和可视化内容的可信游戏引擎。虚幻引擎项目带来了独特的版本控制挑战，包括耗时的项目设置、大型资产和二进制文件的存储与传输，以及跨团队和角色的复杂依赖关系。在虚幻引擎中，有效的版本控制对于保护工作成果、管理并发更改，以及防止项目和团队在规模扩大时出现协作瓶颈至关重要。
游戏开发领域的规模跨度极大，从小型独立团队到拥有 TB 甚至 PB 级数据需要管理的 AAA 游戏公司不等。
虚幻引擎示例代表：
大量文本源文件
大量二进制资产（.uasset/.umap），以及图形、视频和音频——其中许多可以很好地压缩
Robert 选择使用 SDP（服务器部署包）来部署 P4。SDP 是一套适用于 Linux（或 Windows）的脚本，不仅帮助快速、一致地安装具有良好初始配置的 P4 服务器，还包含能够简化常见操作的脚本（例如升级服务器、设置副本服务器、创建代理服务器等）。Robert 团队持续根据客户需求（包括大型企业部署）开发 SDP。
实际的服务器可执行文件与软件包安装的完全相同。
测试环境
Perforce 的许多客户使用云基础设施，来获得灵活性和地理分布式性能，因此在云端进行基准测试是合理的，且该环境易于复现。
对于 AWS 中等规模的配置，Robert 团队使用 EC2 实例 m7a.2xlarge（8 核 CPU，32GB 内存）——这是处理虚幻引擎项目时的常见安装配置。
基准测试的软件版本为：
Perforce 2026.1（补丁 2）
Lore 0.8.5
AWS 服务器和客户端配置
为了便于设置，Robert 团队部署了服务器和客户端。由于客户端设备距离服务器非常近，延迟极低，无法真正代表团队成员通常从家中或办公室访问服务器的真实情况。为了更贴近真实场景，他们在客户端上人为引入了 30 毫秒的延迟。
AWS 中运行 Ubuntu 24.04 的 2 个 EC2 实例：
- Benchserver：m7a.2xlarge，配备 gp3 卷（并列出 IOPS/吞吐量设置）：
| 文件系统 | 大小 | 挂载点 | IOPS | 吞吐量(MB/s) |
|---|---|---|---|---|
| ev/nvme2n1p1 | 40G | /hxlogs | 10k | 500 |
| /dev/nvme3n1p1 | 50G | /hxmetadata | 10k | 500 |
| /dev/nvme1n1p1 | 750G | /hxdepots | 10k | 700 |
这是使用 SDP（服务器部署包）的基础最佳实践安装，包含操作系统根卷，以及 3 个数据卷，分别用于事务日志/运行日志、数据库以及库文件或版本文件。
- Lore 服务器部署在 /hxdepots 上（所有测试中两台服务器同时运行，但测试期间只有 P4d 或 lore 处于活跃状态）
- Benchclient：稍小的 c7a.xlarge，配备 200GB /数据卷（10k IOPS，500MB/s 吞吐量）
- 使用 tc 将其与 benchserver 之间的延迟人为增加到 30 毫秒
Git 虚幻引擎仓库是从 Epic 的 GitHub 仓库下载的 （–depth 1），因此使用以下 commit：
commit 71fe36aac5a8df5ccd66c763ffc902b29b6a9c43 (grafted, HEAD -> release, origin/release, origin/HEAD)
Author: UnrealBot <unrealbot@noreply.users.github.com>
Date: Tue Jul 2812:02:512026 +0000
5.8.1 release
安装软件包依赖项，并运行 Setup.sh 生成各种中间文件。
构建真实的虚幻引擎测试数据集
Git 仓库中的纯源文件并不能代表真实的虚幻引擎项目，因为它们约包含 22.3 万个文件，但数据量仅为 2.68GB。
真实的项目包含更多数据，如图形、音频、视频等。
因此，选择使用“Engine”目录及其内容，在运行 Setup.sh 之后，显示出更为真实的 36.2 万个文件，总数据量为 91GB。
第一条命令显示了 Git 仓库中的源文件：
perforce@benchclient:/data/UnrealEngine$ git ls-files –cached –others –exclude-standard -z |
xargs -0 stat -c ‘%s’ |
awk ‘{s+=$1} END {
printf “Files: %d\nSize: %.2f GiB\n”, NR, s/1024/1024/1024
}’
Files: 223987
Size: 2.68 GiB
因此，使用 Engine 目录作为一个真实数据集的近似：
perforce@benchclient:/data/UnrealEngine$ du -sh Engine/
91G Engine/
perforce@benchclient:/data/UnrealEngine$ find Engine/ -type f | grep -v .git | wc -l
362,028
软件版本与安装
Perforce p4d：按照 SDP 安装说明进行安装。
Lore：按照《部署本地 Lore 服务器 – Lore 开发者文档》进行安装。
性能衡量方法
Robert 还在客户端和服务器上安装了 P4Prometheus、node_exporter 和 Grafana，并设置抓取间隔为 15 秒，以便查看图表并记录数据，以进行性能分析。
基准测试结果：Perforce P4 与 Lore 在虚幻引擎项目中的对比
添加和提交虚幻引擎文件
添加新文件时，P4 使用的命令是：p4 add + p4 submit。对于 Lore，则是 stage + commit + push。Robert 将 P4 配置为使用并行线程提交，以便与 Lore 进行对等比较。
关于 P4 需要注意的一点是文件类型的指定或检测。默认情况下，文本文件以压缩（gzip）形式存储。某些二进制文件不应在服务器上压缩（例如 *.gz 或某些图像格式）。大多数情况下，可以使用 p4 typemap 命令，来指定标准文件类型。
如果不指定文件类型，传统上 P4 客户端会读取每个文件的可配置长度（默认 64K字节），来查找不可打印字符。对于 36.2 万个文件来说，这其实是不必要的开销。P4 2026.1 避免了这一开销。如果你使用的是较早版本，可能希望使用能识别类型映射的脚本，例如 add_files_by_typemap.py。
正面交锋总计（P4 = add + 10 线程submit；Lore = stage + commit + push）：
| 指标 | P4总计 | Lore总计 | 谁更优 |
|---|---|---|---|
| 实际耗时（速度） | 5:15 | 14:30 | P4 更快 – Lore 耗时是 P4的 2.76 倍 |
| 客户端用户 CPU (越低越好) |
178.16s | 1,278.59s | P4 更轻量 – Lore 使用的用户 CPU 多 7.18 倍 |
| 客户端系统 CPU (越低越好) |
81.42s | 152.85s | P4 更轻量 – Lore 使用的系统 CPU 多 1.88 倍 |
| 客户端最大RSS/内存（越低越好） | 108 MB | 13,392 MB | P4 内存占用极低 – Lore 使用的内存多 124 倍 |
说明：
- P4 的大部分服务器端工作发生在提交阶段：CPU 繁忙率为 69.1%，磁盘写入量为 32.51 GB
- P4 submit操作在并行处理时扩展良好
- lore stage 操作实际上完全在客户端进行，这是 lore 的瓶颈所在
- lore commit 在服务器写入的集中程度与 p4 submit 类似：磁盘写入 35.43 GB，磁盘繁忙率 18.6%，但服务器 CPU 繁忙率较低，为13.8%
- lore push 仍然只是元数据/轻量 I/O：网络和磁盘写入量可忽略不计
获取文件：P4 Sync与 Lore Clone 的对比
| 指标 | P4同步 -4 线程 |
Lore克隆 | 谁更优 |
|---|---|---|---|
| 实际耗时（速度） | 3:10.09 | 3:22.12 | P4 更快 – Lore 耗时是P4的 1.06 倍 |
| 用户 CPU(越低越好) | 278.47s | 211.10s | Lore 更轻量 – 使用的用户 CPU 少 1.32 倍 |
| 系统 CPU(越低越好) | 55.37s | 170.01s | P4 更轻量 – Lore 使用的系统 CPU 多 3.07 倍 |
| CPU 使用率 | 175% | 188% | 大致持平 |
| 最大RSS/内存(越低越好) | 988 MB | 13,720 MB | P4 内存占用极低 – Lore使用的内存多 13.9 倍 |
说明：
- P4 Sync 在 4 线程和 10 线程下表现相似——明显受 I/O 限制
- 在服务器端，Lore Clone 传输了更多的网络数据：发送 51.95 GB，而 P4 为 37.68 GB（高出约 38%），而磁盘读取量相近（38.59 GB， 37.15 GB）。
- 服务器端资源争用情况不同：Lore Clone显示出更高的 iowait 和繁忙率：iowait 为33.1%，繁忙率为40.4%；相比之下， P4 Sync的iowait 为14.9%，繁忙率为18.3%。
配置与命令：复现虚幻引擎版本控制基准测试
P4 服务器设置
在服务器上创建一个合适的 depot（例如 UE5）（使用 P4Admin，CLI 如下所示）
通常在该 depot 内创建一个合适的 stream（使用 P4V），例如 //UE5/main
创建一个包含所有待添加文件的列表文件
在客户端上创建指定该 stream 的客户端工作区
运行 p4 add 命令
运行 p4 submit 命令
使用 CLI 的步骤：
$ p4 --field Type=stream depot -o UE5 | p4 depot -i
$ p4 stream -t mainline -o //UE5/main | p4 stream -i
$ cd /data/UnrealEngine
$ find Engine/ -type f | grep -v .git > ../filelist.txt
$ p4 --field Stream=//UE5/main client -o Bench_ws | p4 client -i
$ nohup /usr/bin/time -v p4 -Ztrack -x ../filelist.txt add > ../add.out &
$ nohup /usr/bin/time -v p4 -Ztrack submit -d “New files” > ../submit.out &
请注意，使用 /usr/bin/time 会输出详细的时序信息。p4 -Ztrack 选项还会输出跟踪信息，帮助衡量性能。
然后，你可以在输出文件中查看数据。
对于文件同步：
在客户端创建一个新的客户端工作区
运行 p4 sync 命令
步骤：
$ mkdir /data/ws2
$ cd /data/ws2
$ p4 --field Stream=//UE5/main client -o Bench_ws2 | p4 client -i
$ nohup /usr/bin/time -v p4 -Ztrack sync --parallel=threads=4 > ../sync.out &
Lore 设置与命令
$ lore repository create lore://benchserver:41337/UE5
$ cd /data/UnrealEngine
$ nohup /usr/bin/time -v lore stage --targets ../file_list.txt > ../stage.txt &
$ nohup /usr/bin/time -v lore commit “Test of UE5 Engine” > ../commit.txt &
$ nohup /usr/bin/time -v lore push > ../push.txt &
然后进行同步：
$ mkdir /data/lore_ws
$ cd /data/lore_ws
$ nohup /usr/bin/time -v lore clone lore://benchserver:41337/UE5 > ../clone.txt &
P4 服务器可配置项
这些是 SDP 设置的标准配置。默认的并行设置通常为 4 线程，但可以针对特定命令增加到 20。其中一项设置是 filesys.binaryscan=0 ，以避免不必要的文件扫描。
$ p4 configure show
P4ROOT=/p4/1/root (-r)
P4PORT=ssl:1666 (-p)
P4JOURNAL=/p4/1/logs/journal (-J)
P4NAME=master.1 (serverid)
P4LOG=/p4/1/logs/log (-L)
P4TICKETS=/p4/1/.p4tickets
P4TRUST=/p4/1/.p4trust
security=4 (configure)
monitor=2 (configure)
journalPrefix=/p4/1/checkpoints/p4_1 (configure)
filesys.P4ROOT.min=100M (configure)
filesys.P4JOURNAL.min=100M (configure)
filesys.P4LOG.min=100M (configure)
filesys.TEMP.min=100M (configure)
filesys.depot.min=100M (configure)
server.depot.root=/p4/1/depots (configure)
server.extensions.dir=/p4/1/logs/p4-extensions (configure)
serverlog.file.1=/p4/1/logs/auth.csv (configure)
serverlog.file.3=/p4/1/logs/errors.csv (configure)
serverlog.file.7=/p4/1/logs/events.csv (configure)
serverlog.file.8=/p4/1/logs/integrity.csv (configure)
serverlog.file.11=/p4/1/logs/triggers.csv (configure)
serverlog.retain.1=21 (configure)
serverlog.retain.3=21 (configure)
serverlog.retain.7=21 (configure)
serverlog.retain.8=21 (configure)
serverlog.retain.11=21 (configure)
server.rolechecks=1 (configure)
rejectList=P4EXP,version=2014.2 (configure)
monitor.lsof=sudo /usr/bin/lsof -F pln (configure)
auth.id=p4_1 (configure)
client.readonly.dir=client.readonly.dir (configure)
client.sendq.dir=client.readonly.dir (configure)
rt.monitorfile=monfile.mem (configure)
server: 4 (configure)
track: 1 (configure)
db.monitor.shared: 4096 (configure)
db.reorg.disable: 1 (configure)
dm.info.hide: 1 (configure)
dm.keys.hide: 2 (configure)
dm.protects.hide: 1 (configure)
dm.shelve.promote: 1 (configure)
dm.user.loginattempts: 7 (configure)
dm.user.noautocreate: 2 (configure)
dm.user.resetpassword: 1 (configure)
dm.user.setinitialpasswd: 0 (configure)
filesys.binaryscan: 0 (configure)
filesys.bufsize: 1048576 (configure)
lbr.autocompress: 1 (configure)
lbr.bufsize: 1048576 (configure)
lbr.unloaddepot.compress: 1 (configure)
net.keepalive.disable: 0 (configure)
net.keepalive.idle: 180 (configure)
net.keepalive.interval: 15 (configure)
net.keepalive.count: 9 (configure)
net.parallel.max: 20 (configure)
net.parallel.threads: 4 (configure)
net.parallel.submit.threads: 4 (configure)
net.parallel.sync.svrthreads: 150 (configure)
net.backlog: 2048 (configure)
proxy.monitor.level: 3 (configure)
rpl.checksum.auto: 1 (configure)
rpl.checksum.change: 2 (configure)
rpl.checksum.table: 1 (configure)
rpl.compress: 4 (configure)
run.users.authorize: 1 (configure)
server.commandlimits: 2 (configure)
server.locks.global: 1 (configure)
server.global.client.views: 1 (configure)
server.maxcommands: 2500 (configure)
server.start.unlicensed: 1 (configure)
filetype.bypasslock: 1 (configure)
submit.noretransfer: 1 (configure)
sys.pressure.mem.high: 0 (configure)
sys.pressure.mem.medium: 0 (configure)
rpl.forward.login: 1 (configure)
auth.sso.allow.passwd: 1 (configure)
auth.sso.nonldap: 1 (configure)
serverid=master.1 (serverid)
在虚幻引擎项目中，Perforce P4 和Lore 该如何选择？
只要部署得当，Lore 和 Perforce P4 都表现出色。然而，Lore 默认使用大量并行处理，并且默认情况下的内存占用较高。
在添加和提交大型虚幻引擎数据集时，P4 的速度明显快于 Lore。
P4 在同步方面比 Lore 克隆略快，且出口流量成本更低（数据传输量减少约 38%），同时客户端内存占用也低得多。对于资产密集型的工作负载，Lore 可能仍通过服务器端去重来抵消部分成本，但这需要与更高的传输量和更大的客户端实例规模进行量化对比。
P4 更低的出口流量和显著更低的客户端内存占用，可能在云端大规模部署时，带来合理的成本优势（允许部署更小、更便宜的客户端实例）。
为什么Perforce P4 是更适合虚幻引擎团队的版本控制系统？
版本控制仓库通常是组织的“皇冠明珠”，因为它保护着宝贵的知识产权。在当今快速发展的游戏开发环境中，选择一款性能强大，并能够持续支持全球分布式团队的版本控制系统至关重要。
Perforce P4 长期以来被应用于游戏开发，有其充分理由。它能够可靠地扩展至 TB 级数据，针对二进制和其他不可合并文件，提供独占锁定等功能，兼顾了开发人员和美术人员的工作流程。P4 还拥有广泛的生态支持、与虚幻引擎的深度集成以及丰富的图形化工具，让团队能够充分依托行业的知识和经验。在 Perforce 世界级支持下，这些功能使 Perforce P4 成为虚幻引擎开发的行业标准版本控制平台。
关于原作者：
Robert Cowham，Perforce 首席顾问
Robert 是 Perforce 的高级首席顾问，也是 P4 专业服务团队的技术负责人。他在 P4 平台方面拥有十余年的咨询经验。他的团队与客户合作，处理 P4 服务器实施和故障排除的各个方面，并协助大型客户设计合适的 P4 服务器拓扑结构。
Robert 是 P4Prometheus 的主要作者，这是一套用于 P4 部署最佳实践监控的工具，被众多 Perforce 客户以及 P4 远程管理团队用于监控和告警。他还拥有丰富的经验，致力于开发和使用各类工具，将数据及完整历史记录从其他系统（包括 CVS、Subversion (SVN)、ClearCase、PTC Integrity 和 Git）迁移至 P4 中。他长期专注于配置管理以及改进企业范围内的软件开发实践。
龙智服务与支持
作为Perforce 中国授权合作伙伴，龙智（DragonSoft Digital，DSD）为国内游戏开发团队提供覆盖 P4 全生命周期的专业服务。从版本控制方案选型、服务器部署与架构咨询，到数据迁移、性能调优、系统升级与日常运维支持，龙智团队均可提供本地化、原厂水准的技术支持。
无论您的团队规模大小、项目资产轻重，我们都能结合 Perforce 原厂最佳实践与国内团队的实际需求，帮助您搭建稳定高效的版本控制体系，让开发与美术团队专注于创作本身。
如需进一步了解 Perforce P4 在虚幻引擎项目中的落地实践，欢迎联系龙智团队：
官网：www.shdsd.com
电话：400-666-7732
邮箱：marketing@shdsd.com
最新文章
相关产品
