HTTP服务器之嵌入式负载平衡路由器实战(4)
图十三及图十四是比较三个演算法在后端为四台及两台Web Node状况下的Throughput，图上显示不管是以连线数目还是回应时间作为决定执行要求的Web Node的依据，皆只有在后端Web Node的负载够重的状况下效能才能胜过Round-Robin。这是由于Round-Robin需要很少的CPU计算能力，所以在后端Web Node负担不够重的状况，Round-Robin反而可以由于使用较少PowerNet-AP的CPU资源，完成比较多的要求。但是在后端Web Node负担重的时候，前端PowerNet-AP的CPU便不会成为瓶颈，所以我们提出的演算法将会胜过RR。 最后的实验里，我们想测试出演算法对PowerNet-AP造成的多余负担，所以我们让演算法对于每个要求都输出相同的结果，单纯的比较加上演算法后的路径(code path)和PowerNet-AP的路由机制的效能。 在图十五之一，大致来看可以发现加上演算法的效能都低于单纯路由表的效能，这是理所当然的事。需要解释的是为什么我们的演算法在连线数目小于16个的时候效能为什么可以向上攀升？这是由于在连线数目小于16个时，演算法所造成的负担可以由于每个连线平行的处理而隐藏起来，所以效能会呈现向上的趋势。但是超过16个连线后，由于后端只有一台的Web Node，已经无法负担所有的要求，所以效能一直向下滑。相同的，图十八之二也是由于相同的原因，所以在连线数目为16左右追上了路由表的回应时间，但是之后又由于后端不能负荷，所以效能又往下掉。由这个实验数据我们可以发现实在我们的演算法的负担实在不会太大，尤其在图十八之二，回应时间几乎快要和单纯的路由机制相同了。 我们并没有作第三个演算法的测试，第三个演算法是要根据客户真个网域来做分配，希望让每一台Web Node分到相等的面积(如图十二)。由于以目前的测试环境我们没办法创造出不同IP位址的http要求，并且Specweb99只能产生相同IP位址的要求。除了写程式作模拟外，我们没有想到有效率的方法可以在短期内作出实际的测试。五．结论 在网路的蓬勃发展下，单一伺服器的系统已经不能负担如此快速成长的网路交通。所以多伺服器的系统将会是未来的主流。在多伺服器系统的环境下，目前一般的做法是多Web伺服器搭配Round-Robin DNS来分配流量给后真个伺服器群，但是由于区域性DNS会快取网域名称和IP位址的对应，并且静态Round-Robin的方式将无法应付动态的网路流量变化，所以流量分配不均是可以预期的。再者，以上面的方法，DNS的设定必须被改变，又增加了环境架设的困难。 我们实作了一个嵌入式Web Switch，利用这个Web Switch我们并不需要改变任何现存的网路协定便可以达到负载平衡的目标。在这个计画里，由前真个Web Switch来动态分配http要求给后真个Web Node，我们提出了三种负载平衡的演算法：分别是根据客户端连线数目，要求回应时间及客户端分布来决定执行要求的Web Node。我们实验证实我们提出的演算法都能让后真个伺服器有更好的效能。
页:
[1]