Route53加权政策无法正常工作
我有两个独立的豆虫环境B1和B2）。我目前正在尝试通过53号公路建立加权交通路线，以便B1获得70％的流量，而B2收到了30％的流量。设置路由并路由流量。
但是，查看每个Beanstalk环境的请求度量的总和，与B1相比，B2似乎收到了更多的请求。我们收到大约2000个请求/分钟，我的理解是1400将被路由到B1，其余的将其送至B2。
但是，事实并非如此。看起来B1收到了大约1200个请求，而B2收到约1800个请求。我无法理解为什么会发生这种情况的逻辑？
鉴于我的服务在豆stal上运行，还有其他我需要更新/更改的配置吗？我使用两个豆stall提供的公共网址。不使用外部LB。
我将非常感谢对此的任何见解。
I have two separate Beanstalk environments B1 and B2). I am currently trying to set up a weighted traffic route-policy through Route 53 such that B1 receives 70% of the traffic and B2 receives 30% of the traffic. The routing is set up and the traffic gets routed.
However, looking at the SUm of Requests metric for each Beanstalk environment, it seems like B2 is receiving more requests compared to B1. We get around 2000 requests/minutes and my understanding was that 1400 would be routed to B1 and the rest to B2.
However, that is not the case. It looks like the B1 receives around 1200 requests and B2 receives around 1800 requests. I am unable to understand the logic here as to why this is happening?
Given that my service is running on Beanstalk, is there any other configuration that I need to update/change? I use the public URL provided by both the Beanstalks. No external LB is used.
I would greatly appreciate any insight into this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您正在验证哪种类型的流量？普通的公共互联网流量还是某种工具？ 53 DNS配置的路线是什么？资源记录的TTL多长时间？
如果您有少数客户提出很多请求，则圆形旋转将无济于事。客户将在一段时间内缓存IP地址，并继续使用该IP地址。在这种情况下，如果您不需要粘性会话，则配置负载平衡器，这会带来相同的问题。
圆形旋转的效果最好，大量客户提出了少量请求。
关于TTL。较短的TTL比长TTL更好。但是，这可能会降低应用程序性能并增加您的53号公路账单，因为客户需要更频繁地解决域名。
What type of traffic are you validating? Normal public Internet traffic or some tool? What is the Route 53 DNS configuration and how long is the TTL for the resource records?
If you have a small number of clients making lots of requests, round-robin will not help. The clients will cache the IP address for a period of time and continue to use that IP address. In that case, configure a load balancer if you do not require sticky sessions, which would present the same problem.
Round-robin works best with large numbers of clients making a small number of requests.
Regarding TTL. A shorter TTL is better for round-robin than long TTL. However, that will possibly decrease application performance and possibly increase your Route 53 bill because clients will need to resolve domain names more often.