6.1. 微性能测试列表
回归测试通常用来检测系统中的特定部分是否如期工作，并且要确定旧的错误没有重新出现。
FreeBSD 的回归测试工具能够在 FreeBSD 的源代码树 src/tools/regression 中找到。
6.1. 微性能测试列表
这一章包含了一些在 FreeBSD 上或者 FreeBSD 自身做适合的微性能测试的建议。
要在每一次单独的测试的时候使用所有我们给出的建议是不可能的。 但是你用得越多，你测试小差别的能力就会越好。
关闭 APM 和任何其他干扰时钟的东西 (ACPI ?)。
进入单用户模式。例如，cron(8) 和其他的守护进程只会增加测试的不准确性。sshd(8) 这个守护进程也会造成问题。如果在测试的时候需要 ssh 连接， 那么你或者关闭 SSHv1 的密匙再生功能，或者在测试的时候杀死 sshd 父进程。
不要运行 ntpd(8)。
如果有 syslog(3) 事件发生，使用一个空白的 /etc/syslogd.conf 运行 syslogd(8)， 或者，不要运行它。
最小化磁盘 I/O，可能的话，要完全避免。
不要挂载不必要的文件系统。
可能的话，把 /， /usr， 和其他任何文件挂载为只读。 这样的话可以从 I/O 方面去掉到磁盘的异步更新(等等)。
使用 newfs(8) 来生成要测试读写的文件系统。 在每次测试运行前使用 tar(1) 或者 dump(8) 给测试文件系统灌输文件。测试开始前先卸载文件系统， 然后再挂载。这样做的话能得到一个连续的文件系统格局。 对于经典测试，我们要测试的目录是 /usr/obj(用 newfs 重新初始化，然后再挂载)。 要获得 100% 的再现，请使用 dd(1) 产生的文件来灌输文件系统。(也就是： dd if=myimage of=/dev/ad0s1h bs=1m)
使用基于 malloc 的或者预先装载的 md(4) 分区。
测试的每次单独迭代之间重启系统。 这可以给你一个更连续的状态。
从内核中去掉所有不重要的设备驱动。例如，如果测试不需要 USB， 那么就不要把 USB 放到内核中。驱动加载经常会产生延时。
不要配置不使用的硬件。如果测试不使用硬盘，使用 atacontrol(8) 和 camcontrol(8) 去掉硬盘。
除非必要，否则不要配置网络， 或者等到测试完要把测试结果传输到另一台机器的时候再启动网络。
如果系统必须连接到公共网络，一定要注意广播数据。 即使这些数据很难被注意到，也会占用 CPU 的时钟周期。 组播也有类似的情况。
把每一个文件系统放到它自己的硬盘上。 这可以最小化磁盘的磁头搜索优化的抖动。
尽量减少把结果输出到串口或 VGA 控制台。 将结果导入文件可以减少震动干扰。 (串口终端很容易变成一个瓶颈。) 在测试的时候不要触碰键盘，甚至space 或 back-space 键也会以数字形式显示出来。
确认你的测试足够长， 但不是太长。 如果测试太短， 就无法忽略时间戳的误差影响， 而如果太长， 温度的变化会影响计算机内的石英晶体的频率。 经验值： 多于一分钟， 少于一个小时。
尽量保证机器所在环境的温度恒定。 这会同时影响石英晶体和磁盘驱动器的算法。 要得到稳定的时钟，可以考虑使用 稳定时钟注入(stabilized clock injection)。例如，使用 OCXO + PLL， 把测试结果注入时钟电路而不是主板上的xtal。 要了解更多，请联系 Poul-Henning Kamp
<phk@FreeBSD.org>。测试至少要运行三次。但是对于 “测试前” 和 “测试后” 的代码，最好分别都运行二十次以上。 尽可能交错执行测试，这样可以侦测测试环境对测试的影响。 不要 1：1 的交错，要 3：3 的交错， 这样就可以检测人机交互对测试的影响。
好的类型，比如：bababa{bbbaaa}*， 可以在 1+1 的运行后给出一些提示（在测试出错时可以停止测试）， 以及在首次 3+3 运行后的标准差（如果测试时间较长可以给出一些）， 和测试运行的趋势与稍后一些交互数字。
使用 ministat(1) 来查看数字是否具有统计学上的意义。 你可以买一本 “Cartoon guide to statistics” ISBN: 0062731025，高度推荐， 如果你已经忘记或者根本不知道标准差和 Student's T 测试。
不要使用后台 fsck(8) 除非你是在对后台 fsck进行 benchmark。同时，在 /etc/rc.conf 中关闭
background_fsck，除非在系统起动后， 你的 benchmark 在 fsck 运行 60+ 秒后仍然没开始。 因为一旦开启了后台 fsck，rc(8) 会把 fsck 唤醒并检查是否要在文件系统上运行之。 类似的，除非你的测试对象包括 snapshots， 就要确定系统中没有任何 snapshots。如果你的 benchmark 有预期之外的性能低下问题， 就要检测有没有来自未知系统资源的高频率中断。 有一些版本的 ACPI 就有 “运行混乱” 的问题，并且会产生过多的中断。 要诊断奇怪的测试结果，可以抓一些 vmstat -i 的片段然后查看是否有不正常的现象。
要谨慎对待内核和用户空间的优化参数，对于调试也是这样。 因为很容易就会忽略一些东西， 然后才会意识到测试不能用来比较同样的事情。
除非你的测试对内核参数 WITNESS 和 INVARIANTS 有兴趣，否则不要在开启了这些内核参数后进行你的 benchmark。 WITNESS 会导致 400%+ 的性能损失。 类似的，用户态的 malloc(3) 参数在 -CURRENT 版本和生产版本中默认值都是不同的。