我们最近遇到了无法解释的延迟问题，这反射(reflect)在我们的 AWS 设置的 ELB 延迟指标上。
我们的设置包括 ELB 后面的 3 台 EC2 c1.medium 机器(每台都运行 NGINX，与机器上的 uWSGI 处理程序通信)。
现在，我们的流量在早上和晚上出现高峰，但这并不能解释我们所看到的情况，即在流量高峰期间出现 10 秒的延迟峰值。
我们的 NGINX 日志和 uWSGI 统计数据显示，我们没有对任何请求进行排队，并且响应时间稳定在 500 毫秒以下。
一些配置详细信息:
ELB监听8443端口并传输到8080
NGINX 在每个 EC2 上都有以下配置:
worker_processes 2;
pid /var/run/nginx.pid;
events {
worker_connections 4000;
multi_accept on;
use epoll;
}
http {
server {
reset_timedout_connection on;
access_log off;
listen 8080;
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:3031;
}
}
}
我想知道是否有人经历过类似的事情或者可以提供解释。
谢谢你..
最佳答案
我不确定它是否在某个地方有记录，但我们已经使用 ELB 有一段时间了。本质上，ELB 是您要进行负载平衡的实例之前的 EC2 实例，我们的理解是，当您的 ELB 开始经历更多流量时，Amazon 会执行一些魔法，将该 ELB 实例从 c1.medium 转变为 m1.xlarge。
因此，当您开始看到峰值时，亚马逊可能会在较小的 ELB 实例与较大的 ELB 实例之间进行一些转换，并且您会看到这些延迟。
同样，客户不知道亚马逊内部发生了什么，因此据您所知，在您达到峰值的同时，他们可能会遇到巨大的流量，并且他们的负载平衡器会变得疯狂。
您可能可以通过过度配置来避免这些延迟，但谁愿意花更多的钱。
如果您有时间和资源，我会推荐以下几件事:
在您的环境(一些大型实例)前面设置一个 haproxy 实例并以这种方式监控您的流量。 Haproxy 有一个命令行(或 Web)实用程序，可让您查看统计信息。当然，您还需要监控实例的 CPU 和内存等信息。
您可能无法在生产环境中执行此操作，在这种情况下，您必须通过它运行
测试流量。我建议使用类似 loader.io 的东西。另一种选择是尝试将部分流量发送到 haproxy 实例，也许使用 GSLB(如果您的 DNS 提供商支持)
关于amazon-web-services - AWS ELB 出现无法解释的延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20495541/