6、30秒的测试不算测试

　　由于处于应用、OS与网络栈各层的缓冲区需要一定的稳定时间，所以30秒的测试很可能不准确。如果你的测试数据是要正式发布的，请至少测试3分钟，或者更长一些，比如5到10分钟。

　　7、不要仅仅测试Hello World

　　如果要测试服务器的响应是否迅速，用4字节的响应消息过于局限，意义不大，4k甚至100k才更有现实意义。

　　另外一个需要测试的是服务器在面对大量空闲连接时的表现，比如10，000个连接。这对现代的成熟服务器来说本来不算什么，但往往会导致一些你想象不到的问题。

　　当然，以上仅仅只是两个例子而已。

　　8、仅仅平均值是不够的

　　如果有人告诉你，服务器可以每秒产生1000个响应，平均时延为5ms，听起来是不是很棒？但是，如果这1000个响应里，有些需要100ms呢？或者，如果说在整个测试的10%时间里，由于垃圾收集的关系，只能达到500个响应/秒的速度，你怎么看？

　　平均值是个快速指标，但是，仅此而已。有许多重要的信息，包含在时间线和直方图（histogram）中，但平均值并没有提供。如果你的测试工具不提供时间线和直方图，那么还是换一个吧（开源的话，还可以选择提交一个patch）。

　　httperf可以显示：

　　可以看到，它不仅显示了响应速度的平均值，还显示了最小值、最大值和标准差（deviation）。连接时间也是这样。

　　9、把相关信息全部发布出来

　　如果只是给出一个结果，而不给出重现它的必要信息，那么往好了说，这个结果只是一个全凭大家靠信仰来相信的没有用的结论，往坏了说，它甚至有故意误人子弟之嫌（译者注：各种数据库的宣传式的benchmark表示纷纷中枪）。所以，如果要发布测试结果，记得要把测试的相关上下文也一起发布，不光是测试所用的硬件，还应包括OS版本与配置、网络设置、服务器与负载产生器的版本与配置、所用的负载，甚至必要时还要加上源代码。

　　理想情况下，我们可以采用代码库（比如github）的形式，使任何人都能以最小的代价（用自己的硬件）重现你的结果。

　　10、尝试不同工具

　　看到这里，你也许会以为我只认httperf和autobench这两个工具。我很喜欢全能型选手，可惜httperf不是。对于现代的一些服务器来说，httperf太慢了，也许是由于它缺乏事件循环的缘故。httperf只能以每秒50到500个请求的速度测试一些PHP应用，但无论如何也做不到以每秒上万个请求的速度去测试那些现代的web服务器。

　　而且，如果只认准一个工具的话，可能会由于客户端与服务器之间一些奇怪的交互，导致对某个实现特别不利的情况发生。例如，有些工具建立持久连接的方式对一些服务器不够友好，导致它们的测试结果不佳。

　　而我之所以喜欢httperf，上文中也已经提过，由于它有很详细的统计信息和错误报告，而且可以自定义负载速率，让我们可以更清晰地了解我们的服务器。我希望其它工具也能输出同样详细的信息。

　　我最近还用了siege，虽然在信息方面还比不上httperf那么详细，不过也很好用，尤其速度真叫一个快。

　　原文链接：http://www.oschina.net/translate/http_benchmark_rules