关于应用的负载均衡测试（急候。）

关于应用的负载均衡测试（急！！！在线等候。。。）
场景描述；

硬件设备环境，如下图：


针对负载均衡设备做测试：

目前我们的业务系统是在这样的环境下进行测试，通过loadRunner测试工具进行测试。

经监控发现只有其中一台web服务器的tomcat有压力，我们想要测试整体负载的性能，

请各位老鸟指点。。。
------解决思路----------------------
检查负载均衡的策略，很多是按照IP来进行hash分发的，所以第一个请求到哪里，后面全都到那里。

可以为了测试调整负载均衡策略（比如轮询或其他），也可以让LoadRunner模拟多个IP来发送请求。


另外负载均衡还有个能力是 会话粘着，也就是保证有会话的后续请求都发送到原来的目标服务器，这个也要检查下的。
------解决思路----------------------
Session不能复制，说明Tomcat配置本身存在问题，也就是集群之间的会话并没有实现复制。

当然，如果你本来就不打算实现会话复制（毕竟这个有代价问题）那是另一回事了。



所以如果你要测试的话，还是尽量考虑模拟多IP来进行请求发送更合适。
------解决思路----------------------

引用:

Session不能复制，说明Tomcat配置本身存在问题，也就是集群之间的会话并没有实现复制。

当然，如果你本来就不打算实现会话复制（毕竟这个有代价问题）那是另一回事了。



所以如果你要测试的话，还是尽量考虑模拟多IP来进行请求发送更合适。

其实他压根儿就不知道ip_hash会复制session 否则换用轮训策略之后session不复制他竟然不知。。。你干脆连同session同步也告诉他得了
------解决思路----------------------
load runner 要开ip spoofing，负载均衡的策略按源地址 进行保持。

或者，你的负载均衡分发策略要按Cookie值来分发。
------解决思路----------------------

引用:

Session不能复制，说明Tomcat配置本身存在问题，也就是集群之间的会话并没有实现复制。

当然，如果你本来就不打算实现会话复制（毕竟这个有代价问题）那是另一回事了。



所以如果你要测试的话，还是尽量考虑模拟多IP来进行请求发送更合适。

session复制开销太大，提高的性能有限。

硬负载均衡一般都支持按cookie进行分发的，所以也没有必要做这个。
------解决思路----------------------
Session复制主要是规避单点故障问题，使用中也确实往往是关闭掉的。

但如果系统想实现无停机发布或最低影响之类的目标，就会面临这个问题，也有不少是采用Redis等来自行管理集群会话信息。


但因为楼主并没有表达清楚这方面的需求，所以我两个方向都进行了解释。