我想学习足够简单/实用的排队理论来模拟标准Web应用程序堆栈的行为：具有多个应用程序服务器后端的负载均衡器。实用排队理论
鉴于从NewRelic这样的工具中提取的简单流量模式显示了应用程序给定部分的流量百分比以及该应用程序部分的平均响应时间，我认为我应该能够使用loadbalancer建模不同的排队行为配置，应用程序服务器数量和排队模型。
任何人都可以帮助我点排队理论introduction /基础我需要用数学来表示这个系统？我很尴尬地说，我知道如何做到作为一个本科生，但已经忘记了所有的基础知识。
我的目标是对不同的负载均衡器和应用服务器排队模型建模并测量结果。
例如，对于每组应用程序工作人员来说，N-mongrel Ruby on Rails应用程序堆栈在每个Mongrel上的队列将具有较差的等待时间，而不是具有单个队列的Unicorn/Passenger系统。
我不能在理论上点你，但也有流行使用一些基本的方法：
盲（线性或加权）圆robining - 请求通过ň服务器循环，也许根据一些权重。每个后端都维护一个请求队列。运行缓慢的请求会备份该工作人员的请求队列。停止返回结果的工作人员最终会从平衡器池中退出，并且当前在其上排队的所有请求都会被丢弃。 haproxy/nginx平衡设置很常见。
全局池 - 主队列维护请求列表，并且工作人员可以自由接受新请求时报告。主人将队列的前面切换到可用的工作人员。如果工作人员宕机，只有当前正在处理的请求丢失。在理想情况下（所有工作人员快速返回请求并返回请求）导致性能略有下降，因为队列主管与后端之间的通信是实际切换工作的先决条件，但却有助于自然避免工作缓慢，死亡或停滞。 Passenger默认使用这种平衡算法，haproxy使用它的“leastconn”平衡算法使用它。
散列平衡 - 请求的某个组成部分被散列，结果散列决定使用哪个后端。 memcached将这种策略用于分片设置。缺点是如果你的集群配置改变了，所有以前的哈希变得无效，并且可能会映射到比以前不同的后端。特别是在memcached的情况下，这可能会导致大部分或全部缓存数据无效（最近由于这种问题，reddit遭受了some massive performance problems）。
一般而言，对于Web应用程序，我倾向于选择全球统筹方法，因为它保持，当你有缓慢或死亡的工人流畅的用户体验。