我们已经在 Amazon EC2 中与HAProxy斗争了几天;到目前为止,体验非常好,但我们一直坚持从软件负载平衡器中挤出更多性能。我们并不完全是 Linux 网络专家(我们通常是一家 .NET 商店),但到目前为止,我们一直坚持自己的想法,尝试设置适当的 ulimit,检查内核消息和 tcpdump 是否存在任何违规行为。到目前为止,我们已经达到了大约 1,700 个请求/秒的稳定期,此时客户端超时比比皆是(我们一直在使用和调整httperf以此目的)。我和一位同事正在收听最新的 Stack Overflow 播客,其中 Reddit 的创始人注意到他们的整个网站都运行在一个 HAProxy 节点上,并且到目前为止还没有成为瓶颈。确认!要么不知何故看不到那么多并发请求,要么我们做错了什么,要么 EC2 的共享特性限制了 Ec2 实例的网络堆栈(我们使用的是大型实例类型)。考虑到 Joel 和 Reddit 的创始人都同意网络可能是限制因素这一事实,这可能是我们看到的限制吗?
任何想法都非常感谢!
编辑看起来实际问题实际上不是负载均衡器节点!在这种情况下,罪魁祸首实际上是运行 httperf 的节点。当 httperf 为每个请求构建和拆除一个套接字时,它会在内核中花费大量的 CPU 时间。当我们提高请求率时,TCP FIN TTL(默认为 60 秒)使套接字保持的时间过长,而 ip_local_port_range 的默认值对于这种使用场景来说太低了。基本上,在客户端(httperf)节点不断创建和销毁新套接字的几分钟后,未使用的端口数用完,随后的“请求”在此阶段出错,产生低请求/秒数和大量的错误。
我们也看过 nginx,但我们一直在使用 RighScale,他们有 HAProxy 的插入式脚本。哦,除非证明绝对必要,否则我们 [当然] 的最后期限太紧了,无法更换组件。幸运的是,在 AWS 上允许我们并行使用 nginx 测试另一个设置(如果有必要的话),并在稍后一夜之间进行切换。
本页很好地描述了每个 sysctl 变量(在这种情况下,调整了 ip_local_port_range 和 tcp_fin_timeout)。