3594 字
18 分钟

DataForest Cloud 测评 - 不出意外之后会是我新的长期选择

2026-06-01
服务器测评
VPS
/
DataForest
/
EPYC
/
BenchMark
/
Frankfurt

商家介绍#

image-20260501105943818

DataForest(cloud.dataforest.net)是德国本土的云厂商,机房在法兰克福。它家卖的 KVM 实例叫 Seed,底层存储是 NVMe SSD + Ceph 三副本,按小时计费。他们很多人都见过吧,Avoro,PHP-Friends,包括机房服务 DataForest 都是他们的产品。云可以说是他们的第三代产品?

后台是自研的云面板,开机速度,响应速度都挺不错的。支持API进行管理。

工单响应速度upup,相比其他半天甚至几天找不到人的商家,这个处理工单速度不赖。

价格全部含 19% 德国增值税。

本人AFF: 下单地址 走此AFF注册可以获得25欧元代金券

Entry — 入门档,按可用性分配 CPU,至少给到 Intel Xeon Gold,DDR4,平衡型 IOPS。

官方话术里把这档定位成开发/测试机,便宜是它最大的卖点。(当然也不便宜

机型vCPU内存流量月费
S1C2G20G10 TB3,65 €
M2C4G40G10 TB7,29 €
L4C8G80G10 TB14,59 €
XL8C16G160G10 TB23,91 €

Standard — 通用档,AMD EPYC Turin,2.6 GHz 起、最高 4.5 GHz,DDR5,IOPS 比 Entry 高一档。

目标客户是网站、数据库、CI/CD。提供CPU的性能保证。

机型vCPU内存流量月费
S2C8G80G20 TB9,01 €
M4C16G160G20 TB18,02 €
DS2C8G320G20 TB25,19 €
L8C24G240G20 TB33,19 €
XL10C32G360G20 TB43,63 €
XXL16C64G500G20 TB67,09 €
DXXL16C64G5120G20 TB373,58 €

Performance — CPU 优化档,AMD EPYC Turin (High Frequency),3.3 GHz 起、最高 5 GHz,DDR5,“最大 IOPS”。

目标是 WordPress、IO、对单核敏感的应用。

机型vCPU内存流量月费
S2C8G80G20 TB12,26 €
M4C16G160G20 TB24,51 €
L8C32G240G20 TB46,16 €
XL10C48G360G20 TB59,85 €
XXL16C64G500G20 TB93,03 €
MXXL16C192G500G20 TB160,71 €

加购项目前有三样:备份(每天异地,按小时计费)、快照(一份,按小时计费)、IPv4(按小时计费,按需开关)。价格都不友好,这里除了IPv4是固定价格其他都是根据机器来的,机器越贵,备份快照的价格越高。

需要注意的是。

他们流量采用很少见的流量池小时叠加的方案,按时间累计流量额度。和 Hetzner 之类开机就可以刷满20T 流量的有本质的区别 。

每台 Seed 按小时向共享池“贡献”流量额度,同时所有机器共同消耗这个池,直到月末达到最大流量。

此举我觉得是继承了 Avoro 站点之前大规模滥用流量的事情,很多人恶意按小时刷光流量,因此后来取消了无限流量改成了20T。

image-20260501110314746

image-20260501110829105

image-20260524230506762

测试机器选型#

受测机器套餐vCPU内存流量月费
EntryXL8C16G160G NVMe-Ceph10 TB23,91 €
StandardM4C16G160G NVMe-Ceph20 TB18,02 €
PerformanceM4C16G160G NVMe-Ceph20 TB24,51 €

测试项目#

CPU 微基准

  • sysbench cpu — 经典素数计算,单线程衡量主频差距,多线程衡量到 4 vCPU 的扩展性
  • 7-zip benchmark — LZMA 压缩 / 解压,对内存子系统敏感,能反映”频率涨了但内存跟不上”的场景
  • openssl speed — AES-GCM / SHA-256 / ChaCha20-Poly1305,看硬件加密指令集(AES-NI 等)的差距,HTTPS 终结大流量直接对应
  • stress-ng matrix — 合成 FP 矩阵运算,主要用来确认重负载下不会因为热限频/超售出现衰减

内存

  • sysbench memory — 顺序/随机 × 读/写四组,看带宽和延迟的基本面
  • STREAM Triad — 业界跑了二十年的标准,判定 ClickHouse / 大缓存这种带宽敏感型负载的金标准
  • mbw MEMCPY — sysbench memory 在 KVM 上有已知噪声,mbw 用来对照修正

磁盘 IO

  • fio 4K 随机 — 数据库小事务的标准 proxy,Ceph 三副本最容易拉开差距的地方
  • fio 64K / 1M 顺序 — 大文件读写、流式备份场景
  • fio fsync 4K — 这一项最关键,决定 PostgreSQL/MySQL WAL 写入瓶颈,Ceph 类盘 IOPS 数字虚高,只有 fsync 不会骗人
  • ioping — 微秒级单次延迟,索引扫描 / KV 直接受影响

网络

  • ping 多锚点 — 8.8.8.8 / 1.1.1.1 / Cloudflare / GitHub /
  • Ookla speedtest 多服务器 ID — 法兰克福本地 + 欧洲 + 美东 + 亚太五个方向。
  • iperf3 → 公共 LG — 真实长流的 sustained 带宽
  • curl 大文件 HTTP — 模拟 apt/docker pull 这种实际发生的下载

真实服务负载

  • PostgreSQL 17 — sysbench oltp 四种 workload + pgbench TPC-B,覆盖混合读写、点查、纯读、TPC-B
  • Redis 7 — pipeline + 多种命令,单核敏感型工作负载的代表
  • Nginx + wrk — 静态文件服务,1k 小文件考验 syscall/中断,100k 大文件考验吞吐
  • Node.js — JSON 接口 + PBKDF2 计算密集型,看 V8 JIT 的表现
  • Go build / Rust build — 现代后端语言的编译开销
  • Docker pull / run / build — 容器日常工作流的延迟
  • OpenSSL 编译 (make -j4) — 经典的 C 工程并行编译,CI 场景代表
  • git clone / jq 处理大 JSON — 开发机日常工具的真实耗时

稳定性采样

  • 整套测试期间持续跑 vmstat / mpstat,记录 steal% / iowait% / loadavg。

CPU#

先看最直观的 sysbench prime(数到 30000 的素数),数值为 events/s:

线程EntryStandardPerformance
1 thread (events/s)227.741206.201321.71
4 threads (events/s)1762.674794.275289.90

单线程 Performance 是 Entry 的将近 6 倍。Standard 和 Performance 的单线程差距 9.6%,刚好对得上 4.5 → 5.0 GHz 的频率比。但是到 4 线程 Performance 只比 Standard 快 10%——4 个 vCPU 已经撞到内存子系统的瓶颈了。

7-zip 测试:

ST MIPSMT MIPS
Entry4,46235,988
Standard7,91639,743
Performance8,12539,478

MT 总分 Standard 居然比 Performance 高一点点。原因和上面一样,4vCPU已经是瓶颈了。

OpenSSL 全核加密走的是硬件指令集,差距更夸张:

16 KB 块EntryStandardPerformance
AES-256-GCM~24 GB/s~74 GB/s88.6 GB/s
SHA-2563.20 GB/s8.48 GB/s9.66 GB/s
ChaCha20-Poly130516.7 GB/s21.95 GB/s24.20 GB/s

Zen 5 的 AES-NI 比 Skylake-SP 快了快 4 倍,HTTPS 、TLS 大流量场景是更适合的场景。

stress-ng 的 matrix 测试(合成 FP 矩阵运算)。 bogo ops/s 是 stress-ng 自定义的”完成多少轮基准操作每秒”:

并发 hogs总 bogo ops/s单核 bogo ops/s
Entry822,2062,781
Standard437,3779,362
Performance442,37810,621

Entry 是 8 核硬怼 4 核,总分还是只有 EPYC 两档的一半多一点;单核换算下来 Entry 只有 Performance 的 26%、Standard 的 30%。Standard 与 Performance 的单核差距 13.5%,与单线程 sysbench prime(9.6%)、7-zip ST(2.6%)方向一致——三个测试越偏纯算就越接近频率比。


内存#

测试EntryStandardPerformance
sysbench 顺序读 1M (MiB/s)154,300353,962368,113
sysbench 顺序写 1M (MiB/s)21,1515,7898,001
sysbench 随机读 4K (MiB/s)15,86821,70122,117
sysbench 随机写 4K (MiB/s)477289368
STREAM Triad (MB/s)60,446146,633114,423
mbw MEMCPY (MiB/s)4,20619,83218,762

读带宽 DDR5 双倍碾压 DDR4 这点是必然的。但有两个问题:

第一,STREAM Triad Standard(146 GB/s)居然反超 Performance(114 GB/s)。这不是测试错误,多次复测一致。原因是底层硬件——Standard 跑的是 EPYC 9655(96 核芯片),内存通道宽,分给单个 vCPU 的带宽配额自然多;Performance 跑的是 9575F(64 核高频),频率高但内存通道相对挤。所以如果你跑 ClickHouse 聚合、超大 in-memory 缓存这种带宽敏感的活,Standard 反而更好。

第二,sysbench memory write 那一栏 Entry 看起来比 Standard/Performance 高 3–4 倍,这个数字是bug。sysbench memory 的 write 模式在 KVM 上一直有 store buffer 折算的噪声,已经是众所周知的”垃圾”指标。


磁盘#

4K 随机用 fio,QD=64、4 jobs、direct=1:

EntryStandardPerformance
4K randread IOPS153k227k236k
4K randwrite IOPS144k213k247k
4K 70/30 读 IOPS99.7k160k161k
4K 70/30 写 IOPS42.8k68.7k69.0k

Performance 在写入侧是有优势,但读侧 Standard 已经追到只差 4%。

大块顺序更夸张:

EntryStandardPerformance
1M 顺序读 (GiB/s)33.986.0103
1M 顺序写 (MiB/s)74551890021100

86 ~ 103 GiB/s 这个数字物理上不可能是单盘速度。即便 fio 已经开了 direct=1,宿主上的 RBD 客户端缓存和 host page cache 还是把读绕回去了。这是云厂商 Ceph 类盘的常态,写入数据更能反映真实性能。

然后是数据库里的 fsync 4K 同步写:

EntryStandardPerformance
sync randwrite IOPS689775700

三档差距 ±15% 以内。这就是 Ceph 三副本最大的问题:对一个 4K 块要 fsync,就要等三个副本网络确认。所以官方那句”Performance: maximum disk performance”在 fsync 这个最重要的 DB 指标上其实没体现。

ioping 微延迟可以稍微挽回一点 Performance 的颜面:

EntryStandardPerformance
顺序 min/avg (μs)154 / 22642 / 89144 / 172
随机 min/avg (μs)17.7 / 28.910.2 / 15.96.07 / 13.1
随机 IOPS34.0k62.3k75.4k

Performance 的随机 4K 延迟下到 6 μs 量级,比 Entry 低三倍,对延迟敏感的 KV / 索引扫描有意义。


网络#

只在 Performance 这台跑了完整网络测试,因为是同上游,不做过多测试了。:

锚点 ping 都是单毫秒级的:8.8.8.8 0.65 ms、1.1.1.1 1.34 ms、cloudflare.com 1.10 ms、github.com 1.01 ms、baidu.com 179 ms.

Ookla speedtest 多服务器:

测速点延迟 (ms)下行 (Mbps)上行 (Mbps)
Auto/Frankfurt0.4991178787
Berlin7.2591976764
New York79.6260621128
Singapore0.95*1748314753
Sydney283.632538326

* 新加坡延迟 < 1 ms 是 Cloudflare/Anycast PoP 在德国本地命中,并非真的 1 ms 到新加坡。这反过来说明 DataForest 上游到 Cloudflare 一跳之内。

iperf3 打 online.net 巴黎 LG,4 stream 5 秒收 8.17 Gbps;OVH 100 MB 文件单线程 223 MB/s(约 1.78 Gbps)。


业务负载#

PostgreSQL 17#

数据集 16 表 × 200k 行 ≈ 3 GB,sysbench oltp 跑 120 秒。

测试EntryStandardPerformance
OLTP 读写 (8 线程) tps1,7782,3952,434
OLTP 读写 p95 延迟 (ms)6.094.825.00
Point-Select (16 线程) qps127,984237,932247,826
pgbench TPC-B (s=50, c=16) tps6,6437,7168,013

混合读写下 Standard 和 Performance 差距只有 1.6%,这意味着你跑 PG 跑 MySQL 跑常见 OLTP,Standard 完全够用。Point-Select 这种纯索引查找差距大一点(Performance +4%),高频对单条短查询更友好,但提升不大。

Redis 7(pipeline=16, c=50)#

这应该是 Performance 的主力项目了:

命令Entry RPSStandard RPSPerformance RPS
SET1,136,3631,742,1603,164,556
GET1,366,1201,886,7923,649,635
INCR1,222,4931,851,8513,496,503
LPUSH1,033,0571,672,2402,994,012
LPOP968,9921,552,7952,688,172

Performance 几乎翻倍打 Standard。Redis 是单线程模型,这里 5 GHz 优势全部兑现成 QPS。如果你跑高 QPS 缓存层,Performance 是这次评测里 ROI 最高的选择,没有之一。

Nginx + wrk(4 线程、c=200、30s)#

路径EntryStandardPerformance
/1k.bin Req/s282,069244,144261,843
/100k.bin Req/s95,23489,69193,230

打开看可能要怀疑人生——Entry 反超了。原因是 wrk + nginx 走 loopback,瓶颈在 syscall 路径和中断分布,4 vCPU 都跑满之后频率优势就没了,反倒 Entry 那张 Cascade Lake 的 HT 排布在这种高 IRQ 场景下更稳。100k 大文件三家拉平,差距 5% 以内。纯静态站,三档随便选。(但讲道理,静态限制都能放cloudflare了吧)

Node.js HTTP#

路径EntryStandardPerformance
GET / (返回 JSON) Req/s30,00086,22896,496
GET /hash (PBKDF2 2000 轮) Req/s3,59914,51215,440

Node 的 V8 JIT 同时吃频率和 IPC,Performance 比 Standard 多 12%、比 Entry 多 3 倍多。如果你的业务是 Node API、SSR、BFF 这一类,Performance 的差价就开始有意义了。

编译类(make / cargo / go build / docker build)#

任务EntryStandardPerformance
Go build (cold / warm)8.88 / 0.08 s5.83 / 0.05 s5.99 / 0.04 s
Rust build cold (serde+serde_json)8.83 s4.05 s4.24 s
Docker pull node<22-alpine>5.20 s4.53 s4.56 s
Docker run hello-world × 5020.37 s14.70 s14.35 s
Docker build node 应用 cold4.47 s3.04 s2.75 s
OpenSSL 3.3 build_libs (make -j4)40.51 s34.99 s34.78 s
git clone —depth=1 cli/cli1.67 s1.31 s1.24 s

Rust cold build测试中:Standard 比 Performance 还快 0.2 秒。其它编译任务两家差距都在 3% 以内。结论很清楚——CI runner 选 Standard,这 6 €/月的差价在编译里完全感受不到。

看来官方的定位还是相当准确的

jq 处理 30 万对象的 JSON#

EntryStandardPerformance
filter1.06 s0.44 s0.43 s
sum1.21 s0.41 s0.38 s

数据处理类小工具,Standard / Performance 完全打平。

下面是一些赛博甜品测试

Yabs#

Basic System Information:
---------------------------------
Uptime : 1 days, 4 hours, 8 minutes
Processor : AMD EPYC 9575F 64-Core Processor
CPU cores : 4 @ 3299.998 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 15.6 GiB
Swap : 1024.0 MiB
Disk : 157.4 GiB
Distro : Debian GNU/Linux 13 (trixie)
Kernel : 6.12.74+deb13+1-amd64
VM Type : KVM
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
---------------------------------
ISP : dataforest GmbH
ASN : AS58212 dataforest GmbH
Host : dataforest GmbH
Location : Frankfurt am Main, Hesse (HE)
Country : Germany
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda2):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 536.33 MB/s (134.0k) | 6.66 GB/s (104.0k)
Write | 537.75 MB/s (134.4k) | 6.69 GB/s (104.6k)
Total | 1.07 GB/s (268.5k) | 13.35 GB/s (208.7k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 40.05 GB/s (78.2k) | 45.10 GB/s (44.0k)
Write | 42.18 GB/s (82.3k) | 48.10 GB/s (46.9k)
Total | 82.24 GB/s (160.6k) | 93.20 GB/s (91.0k)
iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 9.00 Gbits/sec | 4.95 Gbits/sec | 14.6 ms
Eranium | Amsterdam, NL (100G) | 16.7 Gbits/sec | 3.69 Gbits/sec | 6.40 ms
Uztelecom | Tashkent, UZ (10G) | 1.93 Gbits/sec | 1.00 Gbits/sec | 77.2 ms
Leaseweb | Singapore, SG (10G) | 1.03 Gbits/sec | 736 Mbits/sec | 158 ms
Clouvider | Los Angeles, CA, US (10G) | 917 Mbits/sec | 1.46 Gbits/sec | 139 ms
Leaseweb | NYC, NY, US (10G) | 1.99 Gbits/sec | 2.27 Gbits/sec | --
Edgoo | Sao Paulo, BR (1G) | 979 Mbits/sec | busy | 240 ms
iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | busy | 2.94 Gbits/sec | 14.6 ms
Eranium | Amsterdam, NL (100G) | 16.2 Gbits/sec | 15.4 Gbits/sec | 6.40 ms
Uztelecom | Tashkent, UZ (10G) | 2.07 Gbits/sec | busy | 78.1 ms
Leaseweb | Singapore, SG (10G) | 1.02 Gbits/sec | 1.17 Gbits/sec | --
Clouvider | Los Angeles, CA, US (10G) | busy | busy | 139 ms
Leaseweb | NYC, NY, US (10G) | 2.20 Gbits/sec | 2.70 Gbits/sec | 83.1 ms
Edgoo | Sao Paulo, BR (1G) | 569 Mbits/sec | 852 Mbits/sec | 241 ms
Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
|
Single Core | 2290
Multi Core | 7921
Full Test | https://browser.geekbench.com/v5/cpu/24273345
Geekbench 6 Benchmark Test:
---------------------------------
Test | Value
|
Single Core | 2994
Multi Core | 9062
Full Test | https://browser.geekbench.com/v6/cpu/17830318
Basic System Information:
---------------------------------
Uptime : 0 days, 0 hours, 19 minutes
Processor : Intel(R) Xeon(R) Gold 6230R CPU @ 2.10GHz
CPU cores : 2 @ 2095.078 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 3.8 GiB
Swap : 1024.0 MiB
Disk : 39.3 GiB
Distro : Debian GNU/Linux 13 (trixie)
Kernel : 6.12.63+deb13-amd64
VM Type : KVM
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
---------------------------------
ISP : dataforest GmbH
ASN : AS58212 dataforest GmbH
Host : dataforest GmbH
Location : Frankfurt am Main, Hesse (HE)
Country : Germany
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda2):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 340.60 MB/s (85.1k) | 4.60 GB/s (71.9k)
Write | 341.50 MB/s (85.3k) | 4.63 GB/s (72.3k)
Total | 682.11 MB/s (170.5k) | 9.23 GB/s (144.3k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 14.38 GB/s (28.0k) | 12.37 GB/s (12.0k)
Write | 15.15 GB/s (29.5k) | 13.19 GB/s (12.8k)
Total | 29.53 GB/s (57.6k) | 25.57 GB/s (24.9k)
Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
|
Single Core | 859
Multi Core | 1683
Full Test | https://browser.geekbench.com/v5/cpu/24264696

image-20260501111139851

image-20260501111146501


结论#

关于 Performance 这档值不值。 它官方宣传是”CPU 优化、IOPS-optimised”。CPU 的实际收益体现在 Redis(翻倍)、Node(+12%)、单核数据库点查(+4%),其他场景跟 Standard 没差。所谓 IOPS 最大化只在 ioping 微延迟和 4K 写 IOPS 上看得到,落到 fsync 这种数据库真实写场景上,三档几乎一样。

Standard 它是这家三档里的甜点位。便宜 Performance 27%,DB / 编译 / Nginx 全打平,内存带宽(STREAM)反而更高。除非你明确知道自己吃单核,默认就该选 Standard。

Entry 建议不买,外面有更好的。。。。

网络 法兰克福本地 9 Gbps 双向、欧洲互访 6–9 Gbps、Cloudflare 一跳,这是这家最强的部分。但没有亚太回程优化,国内访问 180 ms 起跳

稳定性 70 多项测试,三台 steal 全程为 0,watchdog 没触发过一次,整套跑下来 2 小时 50 分。

总结:Redis / 高 QPS API → Performance;几乎其它一切 → Standard;纯开发测试机 → Entry L。(但我总觉得 Entry 没有买的必要,其他家有更好的)

DataForest Cloud 测评 - 不出意外之后会是我新的长期选择
https://catcat.blog/2026/06/dataforest-cloud-seed-review.html
作者
猫猫博客
发布于
2026-06-01
许可协议
CC BY-NC-SA 4.0