我想学习足够的简单/实用排队理论，以对标准Web应用程序堆栈的行为进行建模：具有多个应用程序服务器后端的负载均衡器。
考虑到从类似NewRelic这样的工具中提取的简单流量模式，该流量模式显示了到应用程序给定部分的流量百分比，以及该部分应用程序的平均响应时间，我认为我应该能够使用负载均衡器配置，应用服务器和排队模型。
谁能帮助我指出我需要用数学表示该系统的理论入门/基础知识？我很尴尬地说我作为本科生知道如何做，但是此后却忘记了所有基本原理。
我的目标是为不同的负载均衡器和应用程序服务器排队模型建模并衡量结果。
例如，似乎很明显，与每个应用程序工作组只有一个队列的Unicorn / Passenger系统相比，每个Mongrel上带有队列的N-mongrel Ruby on Rails应用程序堆栈的延迟/等待时间都更糟。
最佳答案
我无法向您说明理论，但是在流行用法中有一些基本方法：
盲（线性或加权）循环轮询-可能根据某些加权，请求通过n个服务器循环。每个后端维护一个请求队列。运行缓慢的请求将备份该工作程序的请求队列。最终停止返回结果的工作程序最终会从平衡器池中删除，当前排队在其上的所有请求都将被删除。这对于haproxy / nginx平衡设置很常见。
全局池-主队列维护一个请求列表，工作人员在有空接受新请求时进行报告。主服务器将队列的最前面移交给可用的工作程序。如果某个工人失败了，那么只会丢失当前正在处理的请求。在理想情况下（所有工作人员都快速启动并返回请求），结果会导致性能略有下降，因为队列主服务器和后端之间的通信是实际交出工作的前提，但这样做的好处是自然避免了工作缓慢，死亡或停滞的工作人员。乘客默认使用此平衡算法，而haproxy使用其“最小二乘”平衡算法对其使用变体。
散列平衡-对请求的某些组成部分进行散列，然后产生的散列确定要使用的后端。 memcached使用这种策略进行分片设置。不利的一面是，如果您的集群配置发生更改，则所有以前的散列都将变为无效，并且可能会映射到与以前不同的后端。特别是对于memcached，这可能导致大多数或所有缓存数据无效（reddit由于此类问题最近遭受some massive performance problems攻击）。
一般来说，对于Web应用程序，我倾向于使用全局池化方法，因为在工作缓慢或死机时，它可以保持最流畅的用户体验。
关于ruby-on-rails - 实用排队论，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3851017/