ruby-on-rails – 实用排队论

我想学习足够简单/实用的排队理论来模拟标准Web应用程序堆栈的行为:带有多个应用程序服务器后端的负载均衡器.

鉴于从NewRelic等工具中提取的简单流量模式显示应用程序的给定部分的流量百分比以及应用程序的该部分的平均响应时间,我认为我应该能够使用loadbalancer配置建模不同的排队行为,数量为应用服务器和排队模型.

任何人都可以帮我指出排队理论介绍/基础知识我需要用数学方法来表示这个系统吗?我很尴尬地说我知道如何以大学生的身份做到这一点,但后来忘记了所有的基础知识.

我的目标是为不同的负载均衡器和应用服务器排队模型建模并测量结果.

例如,似乎很清楚,N-mongrel Ruby on Rails应用程序堆栈的每个Mongrel上的队列的延迟/等待时间会比使用每组app worker的单个队列的Unicorn / Passenger系统更差.

最佳答案 我不能在理论上指出你,但在流行的用法中有一些基本方法:

>盲(线性或加权)循环 – 请求通过n个服务器循环,可能根据一些加权.每个后端都维护一个请求队列.缓慢运行的请求会备份该工作者的请求队列.停止返回结果的工作程序最终会从平衡器池中删除,当前排队的所有请求都将被删除.这对于haproxy / nginx平衡设置很常见.
>全局池 – 主队列维护请求列表,工作人员在可以接受新请求时进行报告.主人将队列的前面交给可用的工作人员.如果工作人员发生故障,则只会丢失当前正在处理的请求.在理想情况下(所有工作人员快速返回并快速返回请求),性能略有下降,因为队列主管和后端之间的通信是实际切换工作的先决条件,但有利于自然避免缓慢,死亡或停滞的工作人员. Passenger默认使用这种平衡算法,而haproxy使用它的“minimalconn”平衡算法使用变量.
>散列平衡 – 请求的某些组件被散列,结果散列确定要使用的后端. memcached使用这种策略进行分片设置.缺点是,如果您的群集配置发生更改,则所有以前的哈希值都将变为无效,并且可能会映射到与以前不同的后端.特别是对于memcached,这会导致大部分或全部缓存数据失效(reddit最近因为这类问题而遭遇some massive performance problems).

一般来说,对于Web应用程序,我倾向于使用全局池方法,因为当您有慢速或死亡的工作时,它可以保持最流畅的用户体验.

点赞