部署 TDengine TSDB 时，CPU、内存等基础性能受关注，而易被忽略的网络延时对写入性能影响显著。本文通过 7 组实验验证：网络延时与写入速度强负相关，最优时（0.034ms）写入速度达 19.9 万 rows/s，最差仅为其 18.6%。
测试基于虚拟机（服务端 16 核 16GB、压测端 16 核 32GB，均 1000Mb/s 网络），以 tc 命令调延时，16 线程 + stmt2 模式压测；配套 ping 测试验证延时、性能监控保障数据可信。
实践建议：对于大数据量、高并发的生产环境，建议网络延时控制在 0.1ms 以下（ping -f）。
一、先搞懂：什么是网络延时？
网络延时就是一个数据从发出到对方收到并回复的总时间，单位是毫秒（ms），从专业角度看，总网络延时由四部分组成：
总网络延时 = 传输延时 + 传播延时 + 处理延时 + 排队延时
实际用网络时，常关注三种延时，它们对应不同场景：
- 单向延时（One-Way Latency）
- 定义：数据从发出到对方收到的 “单程” 时间。
- 适用场景：对时间特别敏感的情况，如实时通信、卫星通信。
- 测量难点：需要让发数据和收数据的设备时间完全一致，不平时很少用这种方式测。
- 往返延时（Round-Trip Time, RTT）
- 定义：数据从发出到对方收到并回复的 “来回” 总时间，。
- 适用场景：大部分网络使用场景，这是平时测性能最常用的延时指标。
- 测量方式：使用
ping192.168.3.67（实验中服务器的地址），结果中time=0.034ms就是往返延时。
- 应用层延时（Application Latency）
- 定义：从发起操作到看到结果的总时间，除了网络延时，还包括设备处理数据的时间。
- 典型示例：打开网页的延时 = DNS 寻址时间 + 建立网络连接的时间 + 数据传输的往返延时 + 服务器处理数据的时间 + 显示网页的时间。
本次实验主要测试 往返延时（RTT），验证其对 TDengine TSDB 数据写入的影响。
二、实验揭秘：如何验证网络延时对写入性能的影响？
文中做了 7 组实验，只改变 “网络延时” 这一个变量，以验证网络延时对写入性能的影响。
2.1 测试环境
实验用的是虚拟机。具体配置如下：
| 配置项 | 服务端（TDengine 节点） | 压测端（客户端） |
|---|---|---|
| CPU 核心数 | 16 核 | 16 核 |
| 内存（MEM） | 16GB | 32GB |
| IP 地址 | 192.168.3.67 | 192.168.3.68 |
| 网络带宽 | 1000Mb/s | 1000Mb/s |
| TDengine TSDB 版本 | 3.3.6.14 | – |
注意：虚拟机有时候会出现宿主机资源竞争的情况，造成性能不稳定，影响实验结果。
2.2 用 tc 命令调整网络延时
为了模拟不同的网络情况，可以用 Linux 系统里的tc命令在压测端调整网络延时。核心命令是：
tc qdisc add dev ens160 root netem delay 10ms参数解析：
| 字段 | 作用说明 |
|---|---|
tc qdisc add | 操作类型：“add” 表示给网络加一条规则 |
dev ens160 | 目标网络接口：指定对 “ens160” 这块网卡生效 |
root | 规则挂载点：把这条规则设为最顶层的，所有数据都要按这个规则走 |
netem | 队列规则类型：相当于 “网络模拟器”，能模拟网络延迟、丢包等情况 |
delay 10ms | 核心参数：把所有从压测端发出的数据都延迟 10ms 再传， |
通过把delay后面的数字改成 0.2ms、0.3ms 等不同数值，就模拟出了 7 组不同的网络延时场景，为后面的对比实验做准备。
2.3 关键操作 2：用 ping -f 验证延时真实性
调完网络延时后，得确认延时与升级相符，可以用 “洪水 ping”（ping -f）模式，命令是：
ping -f -c 10000 192.168.3.67-f参数特别重要，它能更真实地模拟大数据量场景：
- 发包间隔差异：普通 ping 每秒发 1 个数据包，就像货车每隔 1 秒才出发一辆，系统要频繁安排货车，浪费时间；
-f参数让数据包连续发，货车一辆接一辆出发，不用频繁安排。 - 系统资源分配：用
-f参数时，系统会优先处理这些 ping 请求，就像给货车队开绿灯，让它们更快通过。 - 网络传输连续性：连续发数据包能让网络一直处于忙碌状态，避免网络空闲后再启动时浪费时间，就像马路一直有车跑，不会出现车少了再发车时的等待。
用ping -f -c 10000（发 10000 个数据包），可测量当前网络的往返延时，确保实验中 “延时” 这个条件准确。
2.4 压测脚本配置
使用用 TDengine 官方的压测工具 taosBenchmark，保证每次数据测试的条件都一样，，脚本如下：
{
"filetype":"insert",
"cfgdir":"/etc/taos",
"host":"c3-67",
"port":6030,
"user":"root",
"password":"taosdata",
"thread_count":16,
"thread_count_create_tbl":100,
"num_of_records_per_req":10,
"result_file":"insert.log",
"confirm_parameter_prompt":"no",
"databases":[{
"dbinfo":{
"name":"test",
"cachemodel":"'none'",
"cachesize":100,
"vgroups":8,
"drop":"yes"
},
"super_tables":[{
"name":"sbnt",
"child_table_exists":"no",
"childtable_count":80000,
"childtable_prefix":"tbtf_",
"auto_create_table":"no",
"batch_create_tbl_num":2000,
"data_source":"rand",
"insert_mode":"stmt2",
"insert_interval":0,
"insert_rows":10000,
"interlace_rows":10,
"max_sql_len":1048576,
"disorder_ratio":0,
"disorder_range":1000,
"timestamp_step":10000,
"start_timestamp":"2020-10-01 00:00:10",
"sample_format":"csv",
"sample_file":"",
"tags_file":"",
"columns": [{"type":"varchar","len":10,"count":1},{"type":"float","count":10}],
"tags":[{"type":"varchar","len":10,"count":1}]
}]
}]
}执行脚本：
taosBenchmark -f i.json三、实验结论：延时与写入速度呈 “强负相关”
通过 7 组实验对比，可以清楚地看到 “网络延时” 和 “TDengine TSDB数据写入速度” 的关系 ——网络延时越高，数据写入速度越慢；延时越低，数据写入速度越快。
下面是实验的核心数据和结论：
3.1 核心实验数据对比
| 测试组 | 往返延时（RTT） | 写入速度（rows/s，stmt2 模式） | 相对最优速度占比 |
|---|---|---|---|
| Test1 | 0.034ms | 199141.88（每秒存近 20 万条数据） | 100%（最快） |
| Test2 | 1.088ms | 67626.02（每秒存约 6.8 万条数据） | 33.96% |
| Test3 | 2.101ms | 37096.76（每秒存约 3.7 万条数据） | 18.6%（最慢） |
| Test4 | 0.254ms | 155809.98（每秒存约 15.6 万条数据） | 78.24% |
| Test5 | 0.466ms | 122463.81（每秒存约 12.2 万条数据） | 61.5% |
| Test6 | 0.878ms | 81191.54（每秒存约 8.1 万条数据） | 40.77% |
| Test7 | 1.286ms | 58693.38（每秒存约 5.9 万条数据） | 29.48% |
3.2 关键结论解读
从数据里能看出三个重要规律：
- 最优性能边界：当网络延时最低时（Test1，0.034ms），数据写入速度最快，每秒能存近 20 万条数据，这是当前硬件条件下的最好成绩。
- 性能衰减极限：当网络延时最高时（Test3，2.101ms），数据写入速度最慢，每秒只存约 3.7 万条数据，只有最快速度的 18.6%。这意味着延时变成原来的 62 倍，数据写入速度就只剩原来的不到五分之一。
- 线性衰减规律：其他测试组，比如从 Test4 到 Test7，延时从 0.254ms 慢慢增加到 1.286ms，数据写入速度也从每秒约 15.6 万条慢慢降到约 5.9 万条，完全符合 “延时降、速度升” 的规律，进一步证明了两者的关系。
四、生产环境建议：网络延时控制在 0.1ms 以下
根据实验结论，在大数据、高并发的场景，给出以下优化建议：
核心建议：网络延时（RTT）控制在 0.1ms 以下
用ping -f命令测客户端和 TDengine TSDB服务器之间的网络延时，要保证平均延时不超过 0.1ms。
为什么选这个数值呢？有两个原因：
- 性能保障：看 Test1（0.034ms）和 Test4（0.254ms）的数据，延时在 0.1ms 以下时，数据写入速度能保持在每秒 15 万条以上，接近最快速度的 80%，能满足大量数据写入的需求。
- 实际可行性：0.1ms 的延时是普通局域网的正常水平，通过网络优化就能达到这个目标。
ping -f “洪水 ping” 模式，通过减少系统开销和发包间隔，降低了单次 ping 的延时，能够更好的模拟高并发场景。
- 发包间隔差异：普通 ping 默认每秒发送 1 个数据包，系统需频繁切换进程状态，增加额外耗时；-f 参数无发包间隔，连续快速发送，减少进程切换开销。
- 系统资源分配：洪水 ping 优先级更高，系统会更集中地分配资源处理 ping 请求，减少等待耗时。
- 网络传输连续性：连续发包使网络传输更连贯，避免了普通 ping 中间隔导致的链路空闲后的重新初始化耗时。
辅助优化措施
- 硬件层面：让服务器和客户端尽量在同一个地方，比如都放在一个机房里，尽量避免跨交换机。
- 网络层面：定期用
tc命令测网络延时，发现延时高、数据丢包等问题及时解决；给服务器的 IP 设固定路由。
总结
实验显示，网络延时从 0.034ms 增加到 2.1ms，数据写入速度衰减 80% 以上。因此，在大数据量、高并发的场景中，低网络延时是 TDengine TSDB 高效写入的前提。
