AWS ELB无法解释的延迟
我们最近遇到了无法解释的延迟问题，因为我们使用AWS设置从ELB延迟度量标准反思。
我们的设置包括3个EC2 c1.medium机器（每个运行一个NGINX，与机器上的uWSGI处理器对话），在ELB后面。
现在，我们的流量在早上和晚上都达到峰值，但这并不能解释我们所看到的情况，即在延迟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开始经历更多流量时，亚马逊会将ELB实例从c1.medium转换为m1.xlarge。
因此，当你开始看到高峰时，亚马逊可能会在较小的ELB实例和较大的ELB实例之间进行一些转换，并且你会看到这些延迟。
再次，客户不知道亚马逊内部发生了什么，因此，尽管您知道他们可能会遇到大量流量，但同时您还有高峰期和负载平衡器正在疯狂。
你可以通过过度配置来避免这些延迟，但是谁愿意花更多的钱。
如果您有时间和资源，我会推荐几件事情：
在你的环境之前设置一个haproxy实例（一些大的实例）并以这种方式监控你的流量。 Haproxy有一个命令行（或网络）实用程序，允许您查看统计信息。 当然，你也需要监视你的实例CPU和内存。
在这种情况下，您可能无法完成生产，您将不得不通过它运行test traffic 。 我推荐使用loader.io之类的东西。 另一种选择是尝试将部分流量部分发送到haproxy实例，可能使用GSLB（如果您的DNS提供商支持它）