虚拟世界的懒猫

FileHunter 性能测试：三种搜索模式基准测试实战

· · 约 13 分钟阅读 · 技术分享

本文介绍如何对 FileHunter 的三种搜索模式（sequential、concurrent、latest_modified）进行性能基准测试。使用 wrk 和 curl 工具，从吞吐量、延迟、并发表现三个维度评估各模式在本地磁盘和多目录场景下的性能差异。附完整测试脚本和结果分析方法，帮助你根据实际存储架构选择最优搜索模式。

测试环境准备

git拉代码

1
git clone https://github.com/finch-xu/filehunter.git

1. 编译 Release 版本

1
cargo build --release

Release 模式启用 LTO + strip，性能远优于 debug 构建。

你也可以直接下载release版本，不需要自己编译。

2. 准备测试数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 创建测试目录结构
mkdir -p /tmp/fh-bench/{root-a,root-b,root-c}

# 生成不同大小的测试文件
dd if=/dev/urandom of=/tmp/fh-bench/root-a/small.bin bs=1K count=10
dd if=/dev/urandom of=/tmp/fh-bench/root-a/medium.bin bs=1K count=500
dd if=/dev/urandom of=/tmp/fh-bench/root-a/large.bin bs=1M count=5

# 在多个目录中放置同名文件（用于测试 concurrent 和 latest_modified）
cp /tmp/fh-bench/root-a/small.bin /tmp/fh-bench/root-b/small.bin
cp /tmp/fh-bench/root-a/small.bin /tmp/fh-bench/root-c/small.bin

# 让 root-b 的文件更新（用于验证 latest_modified）
sleep 1
touch /tmp/fh-bench/root-b/small.bin

3. 安装测试工具

1
2
3
4
5
# macOS
brew install wrk

# Ubuntu/Debian
apt-get install wrk

三种模式的测试配置

为每种搜索模式编写独立配置文件：

config-sequential.toml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[server]
bind = "0.0.0.0:8080"

[[locations]]
prefix = "/"
mode = "sequential"

[[locations.paths]]
root = "/tmp/fh-bench/root-a"

[[locations.paths]]
root = "/tmp/fh-bench/root-b"

[[locations.paths]]
root = "/tmp/fh-bench/root-c"

config-concurrent.toml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[server]
bind = "0.0.0.0:8080"

[[locations]]
prefix = "/"
mode = "concurrent"

[[locations.paths]]
root = "/tmp/fh-bench/root-a"

[[locations.paths]]
root = "/tmp/fh-bench/root-b"

[[locations.paths]]
root = "/tmp/fh-bench/root-c"

config-latest.toml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[server]
bind = "0.0.0.0:8080"

[[locations]]
prefix = "/"
mode = "latest_modified"

[[locations.paths]]
root = "/tmp/fh-bench/root-a"

[[locations.paths]]
root = "/tmp/fh-bench/root-b"

[[locations.paths]]
root = "/tmp/fh-bench/root-c"

执行基准测试

测试脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
#!/bin/bash
# bench.sh — FileHunter 三模式基准测试

DURATION=10        # 每轮测试持续秒数
THREADS=4          # wrk 线程数
CONNECTIONS=100    # 并发连接数
FILE="small.bin"   # 测试文件名
RESULTS="bench-results.md"

echo "# FileHunter Benchmark Results" > "$RESULTS"
echo "" >> "$RESULTS"
echo "- Date: $(date)" >> "$RESULTS"
echo "- Duration: ${DURATION}s per mode" >> "$RESULTS"
echo "- Threads: $THREADS, Connections: $CONNECTIONS" >> "$RESULTS"
echo "" >> "$RESULTS"

for MODE in sequential concurrent latest_modified; do
  CONFIG="config-${MODE//_/-}.toml"

  # 替换 latest_modified 配置文件名的连字符
  if [ "$MODE" = "latest_modified" ]; then
    CONFIG="config-latest.toml"
  fi

  echo "=== Testing $MODE ==="

  # 启动 FileHunter
  ./target/release/filehunter --config "$CONFIG" &
  PID=$!
  sleep 1

  # 验证服务正常
  curl -s http://localhost:8080/health > /dev/null

  # 运行 wrk 基准测试
  echo "## $MODE" >> "$RESULTS"
  echo '```' >> "$RESULTS"
  wrk -t$THREADS -c$CONNECTIONS -d${DURATION}s \
    http://localhost:8080/$FILE >> "$RESULTS" 2>&1
  echo '```' >> "$RESULTS"
  echo "" >> "$RESULTS"

  # 停止服务
  kill $PID
  wait $PID 2>/dev/null
  sleep 1
done

echo "Results saved to $RESULTS"

运行

1
2
chmod +x bench.sh
./bench.sh

不同文件大小的测试

除了对比三种模式，还应测试不同文件大小对吞吐量的影响：

1
2
3
4
5
6
7
8
# 小文件 (10KB) — 测试请求处理开销
wrk -t4 -c100 -d10s http://localhost:8080/small.bin

# 中等文件 (500KB) — 平衡场景
wrk -t4 -c100 -d10s http://localhost:8080/medium.bin

# 大文件 (5MB) — 测试流式传输性能
wrk -t4 -c100 -d10s http://localhost:8080/large.bin

延迟分析

使用 wrk 的 --latency 参数查看延迟分布：

1
wrk -t4 -c100 -d10s --latency http://localhost:8080/small.bin

输出示例：

1
2
3
4
5
Latency Distribution
   50%    1.20ms
   75%    2.10ms
   90%    3.50ms
   99%    8.20ms

关注 P99 延迟——它反映尾部请求的真实体验。

预期性能特征

基于 FileHunter 的架构设计，各模式的预期表现：

指标 sequential concurrent latest_modified
本地磁盘吞吐 最高 略低（spawn 开销） 略低于 sequential
本地磁盘延迟 最低 略高 略高
多目录命中首个 1 次 I/O 1 次 I/O（并行） N 次 I/O（全部检查）
多目录全未命中 N 次 I/O N 次 I/O（并行） N 次 I/O
NFS 场景 延迟叠加 最优（并行 I/O） 延迟叠加

关键结论：

  • 本地磁盘 + 单目录： 三种模式性能几乎无差异
  • 本地磁盘 + 多目录： sequential 开销最小，优先选择
  • 网络存储 + 多目录： concurrent 显著减少尾部延迟
  • 需要最新版本： latest_modified 是唯一选择，代价是始终扫描所有目录

调优建议

  1. 增大 stream_buffer_size： 大文件场景从默认 64KB 提升到 128KB 或 256KB，提高流式传输效率
1
2
[server]
stream_buffer_size = "128KB"

  1. 启用 HTTP/2： 高并发小文件场景下，HTTP/2 多路复用可减少连接开销

  2. 关闭不需要的功能： 压缩、CORS 等中间件有 CPU 开销，不需要时保持关闭

  3. 合理设置 max_file_size： 避免意外服务超大文件消耗带宽

参考

配置文件的各字段含义和高级功能（CORS、速率限制、压缩等），请参考 FileHunter Wiki。