Проблема: кажется, что каждый отдельный запрос к нашему приложению попадает в очередь всплесков ELB.
Пример диаграммы очереди на выбросы:
У нас есть классический ELB на AWS с несколькими блоками EC2 за ним. Настройка слушателей ELB следующим образом
LB Protocol LB Port Instance Protocol Instance Port Cipher SSL Certificate
TCP 80 TCP 80 N/A N/A
На экземпляре EC2 у нас есть сервер nginx со следующим nginx.conf:
user nginx;
worker_processes 3;
pid /var/run/nginx.pid;
worker_rlimit_nofile 8192;
worker_rlimit_sigpending 32768;
events {
worker_connections 2048;
multi_accept on;
use epoll;
accept_mutex off;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
map_hash_bucket_size 128;
server_tokens off;
client_max_body_size 0;
server_names_hash_bucket_size 256;
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" $request_time';
access_log /app/log/nginx/access.log main;
error_log /app/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_comp_level 4;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
client_body_temp_path /app/tmp/nginx;:q
include /etc/nginx/sites-enabled/*;
upstream tomcat {
server localhost:8080;
}
upstream httpd {
server localhost:9000;
}
upstream play {
server localhost:9000;
}
и vhost sites.conf
log_format proxylog '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$proxy_protocol_addr" $request_time';
server {
server_name www.my-site.com;
rewrite ^(.*) http://my-site.com$1 permanent;
}
server {
listen 80 proxy_protocol;
listen 443 ssl proxy_protocol;
ssl_certificate /etc/nginx/my-certificate.crt;
ssl_certificate_key /etc/nginx/my-key.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "SECRET";
ssl_prefer_server_ciphers on;
set_real_ip_from 10.0.0.0/8;
root /app/websites/my-site.com/httpdocs;
index index.html index.htm;
real_ip_header proxy_protocol;
server_name my-site.com;
access_log /app/log/nginx/my-site.com.access.log proxylog buffer=16k flush=2s;
error_log /app/log/nginx/my-site.com.error.log;
charset utf-8;
location /foo {
proxy_pass http://play;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /bar {
add_header Access-Control-Allow-Origin "*" always;
add_header Access-Control-Allow-Methods "GET,POST,OPTIONS,DELETE,PUT" always;
add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, User-Agent, Authorization, Referer, Timestamp' always;
add_header Access-Control-Allow-Credentials true always;
proxy_pass http://play;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location / {
add_header Access-Control-Allow-Origin "*" always;
add_header Access-Control-Allow-Methods "GET,POST,OPTIONS,DELETE,PUT" always;
add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, User-Agent, Authorization, Referer, Timestamp' always;
add_header Access-Control-Allow-Credentials true always;
real_ip_header proxy_protocol;
set_real_ip_from 10.0.0.0/8;
proxy_read_timeout 90s;
proxy_set_header X-Real-IP $proxy_protocol_addr;
proxy_set_header X-Forwarded-For $proxy_protocol_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_pass http://play;
proxy_set_header Host $http_host;
}
location ~ ^/(images|css|js|html) {
root /app/websites/my-site.com/httpdocs;
}
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
Я ограничиваю возможных подозреваемых в проблеме ELB и nginx, а не самую очевидную - фактические запросы обработки веб-сервера, потому что в одном из моих тестов я полностью удалил java-приложение и заменил его фиктивным сервером node.js, который был отвечая «привет, мир» на каждый запрос, и все эти запросы все еще регистрировались в очереди всплесков.
Я также пробовал отрегулировать worker_processes
и keepalive_timeout
чтобы увидеть, влияет ли это на что-нибудь, а это не так.
Что меня беспокоит, так это то, что эта пиковая очередь из 1 не влияет на производительность службы, так как кажется, что запросы, как правило, остаются там доли секунды, но я не понимаю, почему даже один запрос в конечном итоге проходит очередь всплесков.
У вас установлен ELB на TCP?
Если это так, ваш ELB будет регистрировать каждое соединение, сделанное в очереди всплесков. Боюсь, что никуда не денешься. Вы должны использовать http или https, чтобы очередь всплесков работала правильно.
-
Обновление с OP
Я создал крошечный экземпляр EC2 с простым TCP-сервером, который просто отвечает «картошка» на каждый запрос. Я поставил его за классический ELB с TCP-прослушивателем, сделал один запрос к моему свежему ELB и проверил диаграмму очереди всплесков.
Просмотр документации AWS Слушатели для вашего классического балансировщика нагрузки
Когда вы используете TCP (уровень 4) как для интерфейсных, так и для внутренних соединений, ваш балансировщик нагрузки перенаправляет запрос внутренним экземплярам без изменения заголовков. После того, как ваш балансировщик нагрузки получает запрос, он пытается открыть TCP-соединение с внутренним экземпляром на порту, указанном в конфигурации прослушивателя.
и это:
Для каждого зарегистрированного и исправного экземпляра за балансировщиком нагрузки HTTP / HTTPS открывается и поддерживается одно или несколько TCP-подключений. Эти соединения гарантируют, что всегда существует установленное соединение, готовое для получения запросов HTTP / HTTPS.
Что, насколько я понимаю, означает, что каждый раз, когда мы вызываем ELB, настроенный для TCP, он откладывает наш запрос, чтобы иметь возможность открыть соединение с нашим EC2, и только затем передает запрос машине.