★ FEATURED ARTICLE “大文件下载测试”这个说法很多人第一次听到的反应是“不就是下个文件看看速度吗”我第一次带新人做实操的时候也是这么想的结果拿千兆环境一跑只有 30MB/s然后花了两天时间去翻交换机的配置最后发现是测试文件放在一块老机械盘上读都读不满。大文件下载测试这件事的门槛不在操作而在于你知不知道自己测出来的那个数字到底代表什么。它能一次性暴露出链路协商、磁盘读写、协议栈参数、无线干扰、杀毒软件拦路等一串问题也能在你没意识到的情况下用缓存和单位换算骗你两次。这篇内容写给刚接触网络与存储性能验证的朋友——家庭组网刚布完线的、给小型办公环境做文件服务器验收的、刚上 NAS 想看看能不能跑满的、以及天天被问“为什么传文件这么慢”的。不需要什么前置基础只要会开命令行跟着做一遍就能拿到一组可信的数据。1. 动手之前先想清楚下载测试到底在测什么1.1 三层指标带宽上限、实际吞吐、长时间稳定性同样是“下载速度”在工程语境里其实是三个完全不同的东西混在一起谈就会得出错误结论。第一层是链路带宽上限它由物理介质和协商结果决定比如千兆以太网的理论上限是 1000Mbps换算成字节是 125MB/s这一层是死的改不了。第二层是端到端有效吞吐也就是你真的把数据从 A 搬到 B 的速度它永远低于第一层中间要扣掉协议头开销、ACK 回程、TCP 慢启动、软件处理延迟正常情况下能到理论上限的 85% 到 94% 就算健康。第三层是长时间稳定性这一层最容易被忽略很多人测个十秒看到峰值漂亮就收工结果实际拷贝一部电影到一半速度掉到个位数才发现是无线信号在某面墙后面崩了或者网卡在高温下开始降速。大文件下载测试的价值就在于它同时覆盖了这三层。文件足够大的时候慢启动阶段会被摊薄缓存造成的假象会自己露馅长时间传输中的抖动也能被观察到。但反过来说它也把磁盘 IO、文件系统、服务端软件性能全都拉进来搅在一起了所以你测出来的那个数字是整条链路里最慢那一环的成绩而不是网络本身的成绩。想清楚这一点后面的所有设计才有意义。1.2 哪些场景真的需要动手测一遍不是所有场景都值得折腾。我整理了一下自己实际遇到过的、值得花半小时做一轮测试的情况。第一种是新布线或新设备验收家里刚拉完网线、公司刚换完交换机你需要一个客观数据来确认施工方说的“千兆到位”是不是真的到位这时候下载测试是最低成本的手段。第二种是存储设备上线前后的对比NAS 买回来装好想知道它到底能不能吃满你的网络或者换了万兆网卡之后到底提升了多少都需要一个基准值。第三种是故障排查的量化依据“网速慢”这种描述对排查毫无帮助但“从服务器下载 2GB 文件稳定段只有 11MB/s而同环境 iperf3 能跑到 940Mbps”就是一条能直接指向磁盘问题的线索。第四种场景比较特殊是回归验证。你调整了某个参数比如把无线信道从拥挤的换到空闲的、给交换机端口换了根线、改了一个 TCP 窗口相关的设置改完之后你必须用同一套方法和同一组文件复测否则改动有没有效果全靠感觉。我见过太多人改完参数之后凭“好像快了点”就结案的过两周问题复现又得从头查。所以做这类测试之前先想清楚你是属于哪一种验收类追求可复现排查类追求对比两类对测试文件大小和测试次数的要求是不一样的。1.3 一个常见误区把“最快那一下”当成结果浏览器下载的时候进度条旁边会跳一个瞬时速度很多人就盯着那个最大值看。那个数字通常是缓存命中、TCP 窗口刚撑开、或者刚好没有其他流量干扰的那一瞬间它代表的是“这条链路在最理想的一刹那能做到多少”不是“这条链路能持续做到多少”。真正有参考价值的是稳定段的平均速度也就是排除掉开头三到五秒之后中后段的那个平台值。做测试记录的时候我都会要求把平均速度和稳定段速度分开写前者用来和理论值对比算效率后者用来判断链路质量。这两个数如果差距很大说明链路上有周期性的干扰源比如无线的邻居信道占用、或者某个后台任务在定时抢带宽。2. 测试环境与工具选型别一上来就点浏览器2.1 服务端方案的三种选择按规模挑服务端就是那个“提供文件让人下载”的一端选型的核心考量是它的性能不能成为瓶颈否则你测的是服务端软件不是网络。第一种是零依赖方案直接用系统自带的 HTTP 服务模块一行命令起一个静态文件服务优点是五分钟能跑起来不需要装任何东西在临时排查和小规模验证里非常够用缺点是实现比较朴素单连接的吞吐天花板不算高千兆和 2.5G 环境没问题万兆就明显吃力了。第二种是成熟的反向代理或 Web 服务器软件它支持零拷贝发送文件数据可以直接从内核缓冲区推上网卡不经过用户态内存拷贝性能损耗极小配置也就是十来行适合需要反复测、或者要跑到万兆的场景。第三种是文件共享协议比如局域网共享目录优势是它最贴近日常使用场景你测出来的数字和同事拷文件时的体感最接近劣势是这类协议本身有一堆版本协商、签名、元数据操作的额外开销数字会比纯 HTTP 低一截容易让人误判。我的建议是验证网络能力用前两种验证实际使用体验用第三种两者都做一遍才算完整。有些人只做了 HTTP 测试发现能跑满千兆就断定“文件服务器没问题”结果实际共享拷贝只有 60MB/s原因是共享协议版本没协商到最新、或者启用了报文签名。这两组数据放在一起看才能定位到问题出在网络还是出在协议配置上。2.2 客户端工具能输出数字的才叫工具浏览器是最不适合做这件事的客户端原因有三个它不给你精确的耗时和平均速度它的进度显示有延迟和取整它还会把文件真的落到磁盘上从而引入写入瓶颈。命令行工具的好处是能把耗时、字节数、平均速率直接打印出来方便你复制到表格里做对比。常用的几类里通用下载工具最灵活可以指定输出到空设备从而完全绕开磁盘写入这样测出来的就是纯网络加服务端的成绩系统自带的下载命令简单直接进度输出里带速度适合肉眼看趋势专门的带宽测试工具走的是内存到内存完全不碰磁盘用来做交叉验证最合适它能告诉你“这条链路本身最多能跑多少”然后你再去和下载测试的成绩比差距就是磁盘或软件造成的损耗。这里要强调一个细节客户端一定要把数据写到空设备不要写到真实文件。写到真实文件的话你测出来的是 min(网络速度, 磁盘写入速度)机械硬盘的顺序写大概在 100 到 180MB/s 之间波动如果你的网络是 2.5G理论上限 312MB/s那测出来的数字基本就是硬盘的成绩跟网络一点关系都没有。写空设备还有个附带好处就是每次测试都不会留下垃圾文件跑二十次也不心疼。2.3 测试文件怎么造大小、内容、数量都有讲究文件大小不是随便定的。定得太小TCP 慢启动还没结束传输就完事了测出来必然偏低定得太大每次测试要等好几分钟做五轮就是半小时效率太低。我用的经验公式是文件大小 ≥ 目标速率 × 期望稳定时长。举个例子目标环境是千兆理论 125MB/s我希望至少有 15 秒的稳态观察窗口再加上 5 秒的慢启动和缓存填充时间那就是 125 × 20 2500MB取个整数 2GB 到 3GB 比较合适。如果目标是 2.5G 环境速率按 300MB/s 算同样的窗口就需要 6GB 左右这时候可以用 4GB 文件加多轮测试来折中。文件内容也有坑。用全零填充是最快的生成方式但某些存储系统会对全零块做压缩或去重传输过程中实际搬的字节数变少了你测出来的速度虚高。用真随机数据最保险但生成 2GB 随机数据本身就要花不少时间。我的折中做法是先用快速分配命令把文件长度撑起来再往文件头和尾各写入若干兆的随机数据中间保持为零。这样既保证了文件长度正确、元数据完整又避免了整块全零被特殊处理。这个做法不是教科书标准答案是我自己踩过一次“测出来 400MB/s 但实际拷贝只有 110MB/s”之后总结出来的你可以根据自己的存储环境决定要不要这么讲究。文件数量也要区分。单个大文件测的是带宽和顺序读写能力一堆小文件测的是协议开销和随机 IO 能力这两件事完全不同。日常使用中两种都有所以完整的一轮测试应该包含一组单文件下载和一组小文件批量下载单文件看上限小文件看效率。只做单文件测试的人往往会在实际部署后惊讶于“大文件飞快但打开一个满是素材的目录要转圈十秒”。3. 参数计算单位换算和预期值估算3.1 MB/s 和 Mbps 差八倍这是翻车率最高的地方网络设备的规格书、运营商的套餐、网卡的状态显示用的都是比特每秒写作 Mbps 或 Gbps而下载工具、文件管理器显示的是字节每秒写作 MB/s 或 GB/s。两者差 8 倍。千兆网卡显示 1.0Gbps实际下载最多 125MB/s五百兆宽带套餐理论下载峰值 62.5MB/s。我见过不止一个人把 62.5MB/s 当成“五百兆没跑满”然后去投诉其实人家已经给足了。为了省去每次心算我直接把常用档位做成一张表贴在工位上测试的时候对着看比临时换算靠谱得多。链路规格理论峰值Mbps理论峰值MB/s健康实测范围MB/s说明百兆以太网10012.511.0 - 11.8老设备或劣质网线协商结果千兆以太网1000125110 - 118最常见的家用与办公档位2.5G 以太网2500312.5275 - 295需要网线、网卡、交换机全线支持万兆以太网1000012501050 - 1180对磁盘和服务端软件要求很高无线 5 代866Mbps 协商86610840 - 70受距离、遮挡、干扰影响极大无线 6 代1200Mbps 协商120015080 - 110近距离无遮挡的理想值表格里“健康实测范围”这一列是我从多次实际测试里归纳的不是厂商承诺值。如果你测出来的数字落在这个区间里链路基本没问题可以放心往下走如果明显偏低那就进入排查环节。特别提醒无线的两行很多人看到网卡状态显示 1200Mbps 就以为能跑 150MB/s实际在隔一堵墙的情况下能到 50MB/s 就已经不错了无线的协商速率和实际吞吐之间的折损比有线大得多这点心理预期要先建立起来。3.2 为什么实际速度永远达不到理论值有人会问千兆为什么不能正好 125MB/s。这里面有三层损耗。第一层是协议封装开销以太网单个数据帧的载荷上限是 1500 字节其中 TCP 和 IP 的头部要占掉 40 字节剩下 1460 字节才是有效数据光这一项就损失了约 2.7%。第二层是确认与握手开销可靠传输需要接收方回确认回程的确认包虽然小但也占用了链路的传输机会双向流量还会互相竞争。第三层是软件处理延迟数据从网卡到内核协议栈再到应用程序中间要经过中断处理、内存拷贝、上下文切换这些在高吞吐场景下会累积成可观的延迟。三层加起来千兆环境跑到 940Mbps 左右约 112MB/s就是很健康的状态了。如果你的目标是“跑满 125MB/s”那是在追求一个物理上达不到的数越努力越挫败。反过来如果有人告诉你他家用环境跑出了 130MB/s那大概率是单位算错了或者他把链路聚合的两条链路加起来了。3.3 估算理论耗时用来判断测试结果是否合理拿到文件大小和预期速率先算一遍理论耗时测试跑完之后立刻就能判断结果有没有离谱。以 2GB 文件、千兆环境、预期 112MB/s 为例理论耗时约 18.3 秒。如果实测 20 秒左右非常正常如果实测 60 秒实际速率只有 34MB/s那就说明整条链路上有个环节只有千兆的三成水平需要排查如果实测 8 秒速率 256MB/s超过了千兆的物理上限那一定是缓存或者压缩在骗你。我再给一组对照方便你直接套。2.5G 环境、4GB 文件、预期 285MB/s理论耗时约 14.4 秒。万兆环境、8GB 文件、预期 1100MB/s理论耗时约 7.5 秒。注意万兆这组的时间很短慢启动占比会很大所以万兆测试建议把文件加大到 16GB 以上或者改用纯内存的带宽测试工具做交叉验证别指望一次十几秒的下载能反映真实能力。4. 手把手实操从零搭一套干净的下载测试环境4.1 第一步准备服务端和测试文件先在一台固定不动的机器上建目录这台机器最好是用网线直连的避免服务端自己走无线成为瓶颈。目录建好之后生成测试文件下面给出两种方式按你的环境挑。用快速分配的方式创建几秒钟就能得到 2GB 的文件适用于不担心存储层做去重的场景mkdir -p /srv/dltest cd /srv/dltest fallocate -l 2G test_2g.bin # 往文件头尾各写入 8MB 随机数据打散全零模式 dd if/dev/urandom oftest_2g.bin bs1M count8 convnotrunc statusnone dd if/dev/urandom oftest_2g.bin bs1M count8 seek2040 convnotrunc statusnone ls -lh test_2g.bin如果用的是不支持快速分配的文件系统或者你希望内容完全随机就用慢速方式生成 2GB 大概要几十秒到几分钟取决于设备性能dd if/dev/urandom oftest_2g.bin bs1M count2048 statusprogressWindows 环境下的对应操作先用系统工具快速创建指定长度的文件New-Item -ItemType Directory -Force -Path D:\dltest | Out-Null fsutil file createnew D:\dltest\test_2g.bin 2147483648然后是启动服务端。最省事的方式是用系统自带的模块起一个静态文件服务指定端口和目录即可python3 -m http.server 8000 --bind 0.0.0.0 --directory /srv/dltest如果你需要更高的吞吐或者要反复测试就用配置更正式的 Web 服务器关键在于关掉压缩因为压缩会让传输的字节数变少测出来的速度虚高server { listen 8000; server_name _; root /srv/dltest; location / { sendfile on; tcp_nopush on; tcp_nodelay on; gzip off; gzip_static off; } }配置里sendfile on的作用是零拷贝数据直接从内核页缓存推到网卡不经过用户态这是它比简单实现快的主要原因。gzip off是必须的尤其当你测的是文本类或者可压缩的测试文件时开着压缩等于让服务端先花 CPU 把数据压小再发出去你测出来的是压缩后的传输速度完全失真。注意测试文件所在的目录不要放在网络挂载点上也不要用系统盘。放在独立的本地磁盘上最好是固态盘这样服务端读取不会成为瓶颈。如果条件允许用内存盘做测试目录是最干净的做法能彻底排除磁盘因素。4.2 第二步客户端下载并采集数据在另一台机器上执行下载把数据写到空设备。Linux 和类 Unix 环境的空设备是/dev/nullWindows 下是NUL这个区别不注意就会报错。curl -o /dev/null -s -w 耗时%{time_total}s\n平均速度%{speed_download} B/s\n \ http://192.168.1.10:8000/test_2g.bin这个输出里的速度单位是字节每秒看着不直观加一段处理直接换算成常用的两种单位curl -o /dev/null -s -w %{speed_download}\n \ http://192.168.1.10:8000/test_2g.bin \ | awk {printf 平均速度: %.2f MB/s (%.1f Mbps)\n, $1/1048576, $1*8/1000000}Windows 环境下的等价命令注意要用带扩展名的完整调用方式避免和系统内置的别名冲突curl.exe -o NUL -s -w 耗时%{time_total}s 平均速度%{speed_download}B/sn http://192.168.1.10:8000/test_2g.bin如果只想要一个总耗时用系统自带的计时工具配合下载命令也能得到但要记得同样是写到空设备Measure-Command { curl.exe -o NUL -s http://192.168.1.10:8000/test_2g.bin } | Select-Object TotalSeconds想看速度随时间的变化曲线而不是只有一个平均值那就用带进度输出的下载命令把每次刷新的速度抓出来wget -O /dev/null http://192.168.1.10:8000/test_2g.bin 21 \ | grep --line-buffered -oE [0-9.][[:space:]]?[KMG]B/s这条命令会连续打印出一串速度值把它们贴到表格里你就能看到前几秒爬坡、中间平稳、末尾收尾的完整过程。这个曲线比平均值有价值得多如果它是一条平滑的爬坡然后走平说明链路健康如果它在中后段反复掉到很低再弹回来那是典型的无线干扰或者有别的任务在抢带宽。我通常的做法是同一个配置连跑五轮。第一轮的结果直接丢弃因为这时候服务端的页缓存还没热起来TCP 也刚从冷状态开始数据不具代表性。取后面四轮的中位数作为这一组配置的成绩同时记录最大值和最小值两者差距超过 15% 就说明环境不稳定得先解决稳定性问题再谈性能。4.3 第三步清理缓存避免被自己骗这一步很多人会跳过但它非常关键。服务端读取一次文件之后文件内容会留在操作系统的页缓存里第二次读的时候直接从内存拿速度能翻好几倍。如果不清理缓存你测出来的第二轮、第三轮全是内存速度跟磁盘和网络都没关系。在服务端执行清缓存操作需要管理员权限sync echo 3 | sudo tee /proc/sys/vm/drop_caches第一条命令把还没落盘的脏数据刷到存储第二条命令清掉页缓存、目录项缓存和 inode 缓存。执行完之后再跑下一次下载数据才是真的从磁盘读的。Windows 环境没有直接对应的命令比较省事的办法是重启服务进程或者用系统自带的缓存清理工具再者就是加大测试文件让它远超可用内存的缓存能力这样就算有缓存也装不下全部内容测出来的数字依然可信。这也是我在 3.1 节里建议文件至少 2GB 的原因之一很多机器的内存只有 16GB2GB 到 4GB 的文件偶尔会被整体缓存但如果是 16GB 的文件就绝对装不下。注意清缓存这条命令会影响整机所有进程的读取性能如果这台机器还在跑别的服务别在业务高峰期执行。测试用的机器最好是专门的或者至少挑个空闲时段。4.4 第四步用纯内存工具做交叉验证下载测试跑完之后你手上有了一个数字但它混了磁盘和服务端软件的影响。为了把网络能力单独剥离出来需要用不碰磁盘的工具再测一遍两者一对比问题就定位了。在一端启动服务另一端发起测试。默认是客户端发送、服务端接收加上反向参数就变成服务端发送、客户端接收后者更贴近“下载”的语义# 服务端启动 iperf3 -s # 客户端4 条并发流跑 30 秒反向服务端发、客户端收 iperf3 -c 192.168.1.10 -t 30 -P 4 -R-P 4是并发四条流单条流在长距离或者有丢包的环境里往往跑不满多流能更充分地利用链路。-t 30是持续时间三十秒足够让 TCP 进入稳态。-R是反向一定要加因为正向测的是上传能力反向才是下载能力两者在非对称链路比如某些无线环境上差别可能很大。拿到结果之后做对比。如果纯内存测试能跑到 940Mbps而下载测试只有 400Mbps那问题百分百在磁盘或者服务端软件上网络是无辜的。如果两者都只有 400Mbps那问题在链路本身往网线、网卡协商、交换机端口、无线干扰这几个方向查。这个二分法能帮你省掉大量瞎猜的时间我每次排查都是先做这一步。5. 常见问题与排查速查表5.1 现象、原因、验证方法三列对照实际测试里遇到的现象翻来覆去就那么几种我把它们整理成一张表按现象查原因比漫无目的地试要快得多。现象最可能的原因快速验证方法处理方向速度恰好是理论上限的一半单位换算错误把 MB/s 和 Mbps 混了用 3.1 节的表格对一遍重新计算别急着改配置速度稳定卡在 11MB/s 附近链路协商到了百兆网线或端口有问题查看两端网卡的协商速率换网线检查交换机端口规格速度稳定卡在 110MB/s 附近但环境是 2.5G某一环节只支持千兆逐段确认网卡、网线、交换机规格替换不支持的那一环前五秒很快之后断崖式下跌服务端页缓存被耗尽回到真实磁盘速度加大测试文件后重测换更快的存储或接受这个真实值多轮测试结果波动超过 30%无线干扰、后台任务抢带宽、温度降频换有线连接对比观察是否有周期性换信道关掉无关任务单流慢多流加起来很快单条 TCP 连接的窗口受限用并发下载或多流测试对比属于正常现象看总吞吐即可速度极低且伴随大量重传网线质量差、接头氧化、双工不匹配换一根已知良好的网线直连更换线材检查端口下载到一半连接中断服务端连接数限制、防火墙会话超时查看服务端日志和连接状态调整超时和连接数配置速度比预期低三成左右安全软件在实时扫描下载内容临时关闭扫描后重测对比把测试目录加入排除列表表格里有一行我要特别展开说就是“前五秒很快之后断崖式下跌”。这个现象极其常见几乎每个第一次做测试的人都会遇到然后误以为网络出了问题。真实原因是服务端第一次读文件时把内容装进了页缓存第二次读的前几秒还在从缓存拿等缓存里的部分读完了就回落到磁盘速度。解决办法要么是每轮之间清缓存见 4.3 节要么是把文件做得足够大让缓存装不下。这两种做法我都用过前者更严谨后者更省事排查阶段用后者出正式报告用前者。5.2 几条用血换来的避坑经验第一条永远不要在测试机上同时跑其他网络任务。系统更新、云盘同步、监控上报这些后台流量看起来不起眼但它们会不定时地抢走一部分带宽让你的测试曲线出现莫名其妙的凹陷。我做正式测试之前会先把这些全部暂停测完再恢复。第二条无线环境下的测试结果只能作为参考不能作为结论。无线受物理环境影响太大同一天早上和晚上测出来的数字可能差一倍因为邻居家的设备也在用。如果一定要测无线至少要在同一位置、同一时间段、重复五轮以上并且记录下当时的信号强度和信道占用情况否则这组数据没有复现价值。第三条注意服务端和客户端不要用同一块物理磁盘。有些人图省事在一台机器上既当服务端又当客户端用本地回环地址测这时候读写都落在同一块盘上磁头来回寻道测出来的数字惨不忍睹。回环测试只能验证软件配置对不对验证不了硬件能力。第四条测试时长不要太短。十秒以内的测试基本没有参考价值因为慢启动、缓存填充、系统调度抖动全都挤在这十秒里。我的底线是稳态观察窗口不少于十五秒低于这个时长就加大文件重新测。第五条把环境信息一起记下来。只记一个速度数字是没有意义的你必须同时记录链路规格、文件大小、是否清过缓存、测试时间、两端设备的负载情况。我见过太多人拿着一周前的一个数字来问“为什么现在变慢了”但当时的环境信息一个字都没留只能重测。6. 结果解读与经验心得6.1 拿到数据之后怎么判断别只看一个平均值一组完整的测试数据至少包含四个值总耗时、平均速度、稳定段速度、波动幅度。判断顺序是这样的。先看平均速度是否落在 3.1 节表格的健康区间里落在区间内就说明整体没问题往细看明显偏低就进入排查流程。然后看稳定段速度和平均速度的差距如果稳定段比平均值高出 20% 以上说明测试过程中有相当一段时间被拖慢了通常是缓存耗尽或者有干扰这时候要做的是延长测试观察后半段如果稳定段和平均值接近说明整条链路表现一致数据可信。再看波动幅度。我的判定标准是同一配置多轮测试之间最高值和最低值的差距在 10% 以内算稳定10% 到 20% 算可接受但要注意超过 20% 就说明环境有问题这组数据不能用来做结论。最后做交叉对比把下载测试的成绩和纯内存测试的成绩放在一起两者差距在 10% 以内说明磁盘和服务端软件都没有拖后腿差距超过 30% 就说明瓶颈不在网络上。举个例子千兆环境下载测试稳定在 108MB/s纯内存测试 940Mbps约 112MB/s差距 3.6%结论是链路健康、存储跟得上、服务端软件没问题可以收工。另一组下载测试 62MB/s纯内存测试 940Mbps差距 45%结论是网络很好但存储或服务端拖了后腿接下来该去查磁盘的读写性能和文件系统的挂载参数了。同一份数据解读方式不同得到的方向完全相反这也是我一直强调要做交叉验证的原因。6.2 我自己踩过的几个坑写出来供你少走弯路第一次做这类测试我把测试文件放在了一块用了四五年的机械盘上测出来的数字只有 30MB/s 出头然后我花了整整两天去查交换机配置、换网线、重装网卡驱动最后是一位同事随口问了一句“你文件放哪了”才点醒我。那块盘的顺序读取能力本来就只有 40MB/s 左右网络再好也没用。这件事之后我形成了一个习惯做任何性能测试之前先把每一环的理论上限列出来找出最低的那个它就是你要先解决的问题。第二次是单位问题。我拿到一个 2.5G 环境测出来 290MB/s 的结果兴冲冲地跟人说“跑满了”对方问了一句“290 是 MB 还是 Mb”我才意识到自己把网卡显示的 2500Mbps 和 290MB/s 直接当成了同一个量级去比。虽然这次碰巧算对了290MB/s 约等于 2320Mbps确实接近上限但过程是错的换个数字就会闹笑话。从那以后我养成了习惯所有记录表格里两个单位都写写完自己回头看一遍。第三次是最有教育意义的我在一个刚布好线的办公区做验收有线测出来一切正常然后测无线结果只有 15MB/s远低于预期。一开始怀疑是信号覆盖问题加了一个接入点之后依然如故。最后发现是那个区域的无线设备用了默认的自动信道和隔壁区域的重叠了手动错开之后速度直接翻了两倍多。这件事让我明白无线环境下的“位置”和“信道”是两个独立的变量测试的时候必须分开控制否则你永远不知道是哪一个在起作用。最近一次是缓存问题。同一个配置连测五轮第一轮 62MB/s第二轮 380MB/s第三轮 385MB/s看着像是“第一轮冷启动后面热起来了”我当时差点就这么写进报告。幸好我多问了一句“这机器内存多大”答案是 32GB而测试文件只有 2GB第二轮开始整个文件都在页缓存里了。加上清缓存步骤之后五轮结果都在 60MB/s 附近真相是那块盘的速度就是 60MB/s前面那个 380 是内存的成绩。如果当时没多问这一句整份报告就是错的。这些经历让我总结出一条不太像技术结论的结论做这类测试七成的功夫在测试之前想清楚两成在测试过程中观察只有一成在最后看数字。环境没理干净、缓存没处理、单位没换算清楚跑得再多次也没用。我现在带新人做这件事都会先让他们把整条链路上每一环的理论上限写在一张纸上标出最低的那个然后再动手效率比我当年高得多。另外一个小技巧如果你经常要做同样的测试把命令封装成一个脚本参数包括文件地址、轮次、是否清缓存跑完之后自动输出中位数和波动范围。我自己的脚本大概三十行用的是最普通的 shell跑完直接生成一张表省掉了每次手工记录和计算的麻烦也避免了手动抄数抄错。这类小工具投入产出比很高值得花半小时写一个。
阅读完成 · 觉得有帮助？
