性能测试中带宽的影响
在进行性能测试时,如果发现服务器的各项指标都比较低的时候,就应该考虑测试带宽的限制问题了。 以下是某性能测试遇到的问题
性能优化点:
1、动态页面静态化
2、网络io 与 磁盘io 比较
3、
这两天在为进行过调优后的服务器做性能测试,在对其中一个详情页面进行压力测试的时候,测试结果为110TPS,对于这一结果我们是非常不满意,随后又在多个不同的模块下进行测试,结果都非常的相近,然而在压力测试过程当中,服务器的资源消耗非常低,由此我们可以看出,服务器远远未达到压力的极限,而应用程序应该不会有问题,如果是程序问题,服务器资源绝对不会有那么多空闲。
问题到底出在哪里呢?我们web服务器的架构为nginx+lighttpd,于是我们一层层进行单独测试,发现结果仍然是一样,4核的服务器CPU资源损耗仅处于20%左右,我们又对单一的静态页面做压力测试,发现结果仍然是差不多,并没有太大的提升。无论动态还是静态页面,结果都一样,这就更加肯定了我们的结论。排除了应用程序的问题,那问题就应该出在IO那块,再通过磁盘监控,发现磁盘IO的损耗也非常的低,但是我们却有一个意外的发现,多次测试的结果中,网络IO的流量都是处于12M左右。
看到这里,我们心里就豁然开朗了,问题原来是在这里,我们一直都把重心关于于服务器本身的性能调优上,却偏偏忘记了网络带宽的因素,虽然我们测试服务器的网卡是100/1000M网卡,然而我们却是将服务器部署于百兆局域网内,而100M带宽的实际传输速度刚好是介于12M左右,由于我们终于发现瓶颈是在于网络带宽,而非是服务器本身的性能上。于是二话不说,我们立刻将所有的测试服务器以及客户机都连接在同一千兆网内,尽可能降低网络带宽的限制。
成功搭建好环境之后,再进行测试,结果果然如我们所料,静态页面的测试中,最快的模块测试达到了600TPS上线,而此时的网卡流量已经达到了50M左右,而由于多个模块的页面大小并不相同,TPS的结果也各不相同,但是网卡的流量却都处于50M上下,然而1000M网的理论速度是可以达到120M左右,50M的实际速度远远未到此数,也许达不到理论速度,但是相差应该也不会太多,于是我们尝试从两台服务器之间互相copy大文件测试一下实际速度有多少,而最终的结果也是和我们测试web服务器的结果一样,也是在50M上下,因此又一次证明了IO是一个瓶颈,只是还无法确定是磁盘IO还是网络IO,由于时间比较紧,我们就并未在此问题上多做纠缠,因为这只是对静态页面的测试,实际运行过程当中,真正的瓶颈应该是在应用上,因此我们再次将重心转移到动态页面的请求上。
再一次对动态页面进行压力测试,这次我们对各个模块测出的平均结果处于200TPS上下,而网络流量仅仅处于30M左右,此时服务器的资源占用率已经处于 80-90%之间,基本已经是处于满负荷状态,纯动态页面200TPS,不算高,程序本身还有很大优化的空间,不过五一过后就要正式上线,此时再进行优化已经来不及,不过对于纯动态请求200TPS的结果,其实我已经相对满意了,因为考虑到实际应用场景,在最有可能出现峰值的情况下,实际大部分用户只会访问比较少数相同的页面,而我们对于同一页面的请求都进行了静态化的处理,实际上除了第一次请求外,其他的请求都是直接访问静态页面,因此实际能承受的压力远远不止于此。