我有一个基于Windows的桌面应用程序，通过TCP与应用程序服务器进行通信。 （Windows 2003）。 客户端调用之间没有粘性会话。 我们有2台服务器负载均衡，我们正在考虑使用F5硬件NLB。
该应用程序是一个重负载types，在服务中没有太多的业务逻辑，但在大多数时间检索相当数量的数据。 可能在任何时候平均5000到10000条logging。 主要用于存储和退回数据，不需要在服务器端运行数据或计算的特殊处理。
考虑到我的服务需要一段时间才能返回数据，因此我倾向于使用“预测”，因此跟踪反馈会产生一些更好的路由，就像预测一样。
我不知道是否给定的数据足以提出一些想法，但考虑到这些，有什么build议\事情要考虑\最好的预测和最less连接？
谢谢。
正如我记得的那样，在F5环境中的预测是对服务响应时间的持续监视。 当通过BiP的networking请求预计将有类似的响应时间时，它效果最好。 如果加载后端服务器，则TTR将增加，并且BiP将回退它发送的连接数，直到TTR正常化为止。
如果您的服务的请求具有高度可变的TTR，则预测提供的值将不太重要。 请记住，BiP认为响应是响应的前沿; 只要第一个回复数据包可靠地进入，这个数据stream是15个数据包还是50,000个都没关系。 如果您的服务等待，直到它有所有的数据stream之前，你会得到较less的预测价值。