近期，我们在云端渲染场景中，对 100 至 3000 节点的 JuiceFS Windows 客户端进行了性能测试。测试内容为渲染前置任务，即在渲染任务之前执行所有存储相关操作。
与实际使用场景相比，本次测试采用了更为苛刻的条件，使用了大量小文件的数据进行测试。任务要求 1000 台机器平均时间在 30分钟内完成。客户原来使用SMB 服务，随着渲染机器数量增加，网络带宽、负载均衡等因素会降低性能表现，在 2000 台以上就基本无法使用。而 JuiceFS 测试结果在 3000 台并发渲染任务中依旧性能平稳，平均执行时间为 22 分 22 秒。
目前，JuiceFS Windows 客户端 Beta 版本已集成于社区版 v1.3 和 企业版 v5.2 中，具体优化历程可参考：首个 Windows Beta 版的优化之路。希望有需求的用户积极尝试并进行测试，并欢迎大家在使用过程中反馈问题和改进建议。
01 Windows 渲染场景用例与资源配置
渲染场景测试用例文件大小分布
此次测试样本共包含 65,113 个文件，其中大小在 128KB 以下的文件占比为 95.77%，相比日常的渲染场景，本次测试特别增加了小文件的占比，以更严苛的条件进行测试。
- ≤1K: 11,053 个文件
- 1K~4K: 1,804 个文件
- 4K~128K: 49,504 个文件
- 128K~1M: 1,675 个文件
- 1>1M: 1,077 个文件
各组件硬件配置
部署方案
在此次测试中，我们使用了 JuiceFS 企业版，企业版采用了自研的高性能元数据引擎，并提供了分布式缓存支持，关于分布式缓存可参考文章：从资源闲置到弹性高吞吐，JuiceFS 如何构建 70GB/s 吞吐的缓存池。
为了获得最佳性能，我们将 35GB 的样本完全预热到分布式缓存中。部署架构图如下：
JuiceFS 挂载参数设置
缓存服务器挂载参数：
bash
juicefs mount jfs /jfs-mem \
--buffer-size=4096 \
--cache-dir=/dev/shm \
--cache-group=cache-mem \
--cache-size=122400 \
--free-space-ratio=0.02 Windows 客户端挂载参数：
bash
juicefs.exe mount jfs J: --buffer-size=4096 --cache-group=cache-mem --no-sharing --console-url http://console:8080 --enable-kernel-cache注意：
--console-url：指定控制台的URL，第一次挂载或者新建文件系统后须输入。--enable-kernel-cache：启用 WinFSP 内核缓存：默认是不启用，大量随机 512 字节读取时性能比较差，
建议打开，请求就会聚合成 4K。
02 测试结果
数据存储在 JuiceFS 中，100 至 3000 台远端 windows 客户端读取这些数据时，渲染前置存储读取任务的耗时如下表所示。
从上面的数据中，我们可以看到：
- JuiceFS 能够在不同规模的渲染前置存储任务中保持高效的性能，随着设备数量的增加，系统的吞吐量和 IOPS 性能提升。
- 当设备规模达到 3000 台时，JuiceFS 能够稳定承受每秒 127 万次的元数据请求，分布式缓存吞吐14.7GB/s，Windows 客户端聚合吞吐达到 23.8GB/s，渲染任务完成耗时平均 22 分钟 22 秒。
03 总结
该测试场景基于实际渲染环境设计，但具有更高的负载与性能要求，旨在验证 JuiceFS 在渲染任务中的数据处理能力。测试内容涵盖 JuiceFS 的整体产品能力，包括 Windows 客户端、元数据服务器软件和分布式缓存集群软件。测试结果表明，JuiceFS 能够支持至少 3000 台 Windows 设备同时进行渲染前置存储相关读取的任务，平均完成时间为 22 分钟 22 秒，最大任务完成时间在 34 分钟以内，显示了 JuiceFS 在大多数渲染场景中能够有效满足实际业务对存储的需求。