首页 存档 技术 查看内容

HTTP负载测试

2018-3-30 13:00 |来自: 互联网 270 0

摘要: (点击上方公众号,可快速关注我们) 英文:ON HTTP LOAD TESTING 中文:oschina 链接:http://www.oschina.net/translate/http_benchmark_rules 有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的 ...

(点击上方公众号,可快速关注我们)


英文:ON HTTP LOAD TESTING

中文:oschina

链接:http://www.oschina.net/translate/http_benchmark_rules

有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的服务器选择。

这很好,但是我看到有人很多基本相同的问题,使得测试结果的推论值得怀疑。在日常工作中花费了很多时间在高性能代理缓存和源站性能测试方面之后,这里有我认为比较重要的一些方面来分享。

希望能抛砖引玉。

一致性

最最重要的是,每次都测试同一个时间点。因为系统发生的每个改变,无论是OS升级还是运行了其它消耗带宽和CPU的应用,都会影响测试的结果,所以一定要把测试环境固定下来。

也许,有人会说那就把测试放虚拟机里做吧,听起来不错。但是,这种方式加多了一个抽象层(而且宿主机上也跑了更多的进程),如果说这样就能得到更加一致的结果,我是无论如何也不会相信的。我觉得,最好的办法是为测试准备一套专用硬件。如果做不到这个,那么一定要把所有测试放在同一个会话里,不要去比较不同会话里的测试结果。

1. 每台机器,各司其职

人们常常会犯另一个错误,他们把负载生成器和被测试的服务器放在同一台机器上。这样做将导致产生不可靠的测试结果,因为,负载生成器实际上是「窃取」了一部分资源,而且这部分资源的量还会随着服务器处理负载情况的变化而变化。

最好的做法是,为测试主体和负载生成器分配不同的硬件,而且将它们放在封闭的网络上。这样做的代价并不是太高,我们并不需要非常高精尖的配置,只需要确保一致性就好。

所以,如果有人跟你说,他们的测试是在localhost上做的,或者拒绝透露测试用了几台机器,那么你尽可以忽略他们的结果。因为,这样的结果,往好了说,只有最基本的定性作用,往坏了说,甚至可能会误人子弟。

2. 检查网络

在测试前,一定要知道你的网络有多大容量,这样,你才会知道,什么时候是你测试的服务器制约了测试,什么时候是网络制约了测试。

一种方法是通过iperf:

qa1:~

声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除

路过

雷人

握手

鲜花

鸡蛋

相关分类

返回顶部