性能测试

附件大小
Image icon test_environment.jpg21.66 KB

在美国VA Linux公司的高级工程师告诉我,他们在实验室中用一个IPVS调度器(VS/DR方式)和58台WEB服务器组成一个WEB集群,想测试在真实网络服务负载下IPVS调度器的性能,但是他们没有测试IPVS调度器的性能,当58台WEB服务器都已经满负荷运行时,IPVS调度器还处于很低的利用率(小于0.2)。他们认为系统的瓶颈可能在网卡的速度和报文的转发速度,估计要到几百台服务器时,IPVS调度器会成为整个系统的瓶颈。

我们没有足够的物理设备来测试在真实网络服务负载下IPVS调度器的性能,况且在更高的硬件配置下(如两块1Gbps网卡和SMP机器),调度器肯定会有更高的性能。为了更好地估计在VS/DR和VS/TUN方式下IPVS调度器的性能,我们专门写一个测试程序testlvs,程序不断地生成SYN的报文发送给调度器上的虚拟服务,调度器会生成一个连接并将SYN报文转发给后端服务器,我们设置后端服务器在路由时将这些SYN报文丢掉,在后端服务器的网卡上我们可以获得进来的报文速率,从而估计出调度器的报文处理速率。

我们的测试环境如图5.3所示:有四台客户机、三台服务器和一个Pentium III 500MHz、128M内存和2块100M网卡的调度器,四台客户机和调度器通过一个100M交换机相连,三台服务器和调度器也通过一个100M交换机相连。它们都运行Linux操作系统。



图5.3:IPVS调度器的性能测试环境

在VS/NAT的性能测试中,我们分别在三台服务器启动三个Netpipe服务进程,在调度器上开启三个虚拟服务通过网络地址转换到三台服务器,用三台客户机运行Netpipe分别向三个虚拟服务进行测试,调度器已经满负荷运行,获得三个Netpipe的累计吞吐率为89Mbps。在正常网络服务下,我们假设每个连接的平均数据量为10Kbytes,VS/NAT每秒处理的连接数为1112.5 Connections/Second。

在VS/DR和VS/TUN的性能测试中,我们设置后端服务器在路由时将这些SYN报文丢掉,后端服务器就像一个黑洞将报文吸掉,它的处理开销很小,所以我们在后端服务器只用两台。我们在后端服务器上运行程序来测试进来报文的速率,在调度器上将一虚拟服务负载均衡到两台后端服务器,然后在四台客户机上运行testlvs不断地向虚拟服务发SYN报文,报文的源地址是随机生成的,每个报文的大小为40个字节。测试得VS/DR的处理速率为150,100 packets/second,VS/TUN的处理速率为141,000packets/second,可见将IP隧道的开销要比修改MAC地址要大一些。在实际实验中,我们测得平均文件长度为10K的HTTP连接,从客户到服务器方向的报文为6个。这样,我们可以推出VS/DR或VS/TUN调度器的最大吞吐率为25,000 Connections/Second。

Comments

上面描述中提到的测试结果是没有参考意义的。
不谈硬件光谈性能是没价值的。

在一个实际的生产环境中(web 2.0服务),我们观察到一台运行linux 2.6.x内核的dell 2850双至强3.0G机器作为LVS调度器承载了整个网站的访问调度,从粗略的统计看整个站点每秒有超过1000个请求,此时用ipvsadm -lnc 能看到有7万个状态条目,lvs运行于NAT模式,典型的top结果为 Cpu(s): 0.7%us, 1.7%sy, 0.0%ni, 91.5%id, 0.0%wa, 0.7%hi, 5.4%si, 0.0%st
可见系统是相当的空闲。

LVS的魅力应该是 强大的请求处理和转发功能吧! 你看测试结果 ,NAT和DR/TUN 相差一个数量级。

我测试的结果就没有上过 1w request per second 的

randomness