我想学习足够简单/实用的排队理论来模拟标准 Web 应用程序堆栈的行为：具有多个应用程序服务器后端的负载平衡器。
鉴于从 NewRelic 等工具中提取的简单流量模式显示了应用程序给定部分的流量百分比和应用程序该部分的平均响应时间，我认为我应该能够使用负载均衡器配置对不同的排队行为进行建模、应用服务器的数量和排队模型。
谁能帮我指出我需要用数学方式表示这个系统的排队论介绍/基础知识？我很尴尬地说我作为一名本科生知道如何做到这一点，但后来忘记了所有的基础知识。
我的目标是对不同的负载平衡器和应用服务器队列模型进行建模并测量结果。
例如，很明显，N-mongrel Ruby on Rails 应用程序堆栈在每个 Mongrel 上都有一个队列，其延迟/等待时间比在每组应用程序工作人员中使用一个队列的 Unicorn/Passenger 系统更短。
【问题讨论】：
标签： ruby-on-rails performance optimization
我不能为你指出理论，但有一些流行使用的基本方法：
盲（线性或加权）循环 - 请求通过 n 个服务器循环，可能根据某些加权。每个后端维护一个请求队列。运行缓慢的请求会备份该工作人员的请求队列。停止返回结果的工作人员最终会从平衡器池中删除，当前排队的所有请求都将被删除。这对于 haproxy/nginx 平衡设置很常见。
全局池 - 一个主队列维护一个请求列表，并且工作人员在他们有空接受新请求时报告。 master 将队列的前端交给可用的 worker。如果一个工作人员宕机，只有当前正在处理的请求会丢失。在理想情况下会导致性能略有下降（所有工作人员都启动并快速返回请求），因为队列主机和后端之间的通信是实际移交工作的先决条件，但有利于自然避免缓慢、死亡或停滞的工作人员。乘客默认使用这种平衡算法，而 haproxy 使用其“leastconn”平衡算法的变体。
散列平衡 - 请求的某些组件被散列，得到的散列决定使用哪个后端。 memcached 使用这种策略进行分片设置。不利的一面是，如果您的集群配置发生更改，之前的所有哈希都将失效，并且可能映射到与以前不同的后端。特别是在 memcached 的情况下，这可能会导致您的大部分或全部缓存数据失效（reddit 最近因此类问题遭受了some massive performance problems）。
一般来说，对于网络应用程序，我更喜欢全局池化方法，因为当你有缓慢或死亡的工作人员时，它可以保持最流畅的用户体验。
【讨论】：