我想学习足够简单 / 实用的排队理论来建模标准 Web 应用程序堆栈的行为:具有多个应用程序服务器后端的负载均衡器
给定从像 NewRelic 这样的工具中提取的简单流量模式,显示应用程序给定部分的流量百分比和应用程序该部分的平均响应时间,我认为我应该能够使用负载平衡器配置,应用程序服务器数量和排队模型。
任何人都可以帮助我指出排队理论入门 / 基础知识,我需要在数学上表示这个系统?
我的目标是建立不同的负载平衡器和应用程序服务器排队模型并测量结果。
例如,似乎很明显,一个 N-mongrel Ruby on Rails 应用程序堆栈将有更差的延迟 / 等待时间,每个 Mongrel 上都有一个队列,而不是每个应用程序工作组都有一个队列的 Unicorn / Passenger 系统。
我不能指出你的理论,但有一些基本的方法在流行的用法:
盲 (线性或加权) 循环-请求通过n服务器循环,可能根据一些权重。每个后端维护一个请求队列。运行缓慢的请求备份该 worker 的请求队列。停止返回结果的 worker 最终会从平衡器池中删除,当前在其上排队的所有请求都会被丢弃。这对于 haproxy / nginx 平衡设置很常见。
全局池化-一个主队列维护一个请求列表,当工人可以自由接受新请求时,他们会报告。主人将队列的前部交给可用的工人。如果工人停机,则仅丢失当前正在处理的请求。在理想情况下(所有工人都迅速启动并返回请求)会导致性能略有下降,因为队列主机和后端之间的通信是实际移交工作的先决条件,并且该算使用“延迟”,从而避免了工作。
哈希平衡-对请求的某些组件进行哈希处理,生成的哈希确定要使用哪个后端。memcached 使用这种策略进行分片设置。缺点是,如果您的集群配置更改,所有以前的哈希都将失效,并且可能映射到与以前不同的后端。特别是对于 memcached,这可能会导致大多数或所有缓存数据失效(reddit 最近遇到了some massive performance problems的问题
一般来说,对于 Web 应用程序,我倾向于更喜欢全局池方法,因为当你有缓慢或死亡的工人时,它会保持最流畅的用户体验。
本站系公益性非盈利分享网址,本文来自用户投稿,不代表码文网立场,如若转载,请注明出处
评论列表(43条)