HTTP服务器之嵌入式负载平衡路由器实战(4)

　　最后的实验里，我们想测试出演算法对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。我们实验证明我们提出的演算法都能让后端的伺服器有更好的效能。