所有請求都進入 ELB 浪湧隊列

一個問題：似乎對我們應用程序的每個請求都以 ELB 激增隊列結束

激增隊列圖範例：

我們在 AWS 上有一個經典的 ELB，後面有多個 EC2 盒子。ELB 偵聽器以另一種方式設置

LB Protocol  LB Port  Instance Protocol  Instance Port  Cipher SSL  Certificate 
TCP          80       TCP                80              N/A        N/A

在 EC2 實例上，我們有一個帶有下一個 nginx.conf 的 nginx 伺服器：

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;
 }

和虛擬主機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 上，而不是最明顯的——實際的 Web 伺服器處理請求，因為在我的一個測試中，我完全刪除了 java 應用程序，並將其替換為一個虛擬的 node.js 伺服器，它是對每個請求都回复“hello world”，而我仍然將所有這些請求記錄在浪湧隊列中。

我還嘗試調整worker_processes併keepalive_timeout查看它是否會影響任何東西，但它不會。

困擾我的是，這個 1 的浪湧隊列不會影響服務的性能，因為請求似乎往往會停留在幾秒鐘內，但我不明白為什麼即使是單個請求也會通過浪湧隊列。

您是否將 ELB 設置為 TCP？

如果是這樣，您的 ELB 會將每個連接註冊到浪湧隊列中。恐怕沒有辦法繞過。您必須使用 http 或 https 才能使浪湧隊列正常工作。

–

從 OP 更新

我創建了一個小型 EC2 實例，它帶有一個簡單的 TCP 伺服器，它只對每個請求回复“土豆”。我把它放在一個帶有 TCP 監聽器的經典 ELB 後面，並向我的新 ELB 發出一個請求，並檢查了浪湧隊列圖。

查看 AWS 文件Listeners for Your Classic Load Balancer

當您將 TCP（第 4 層）用於前端和後端連接時，您的負載均衡器會將請求轉發到後端實例而不修改標頭。在您的負載均衡器收到請求後，它會嘗試在偵聽器配置中指定的埠上打開與後端實例的 TCP 連接。

還有這個：

對於 HTTP/HTTPS 負載均衡器後面的每個已註冊且執行良好的實例，Elastic Load Balancing 都會打開並維護一個或多個 TCP 連接。這些連接確保始終有一個已建立的連接準備好接收 HTTP/HTTPS 請求。

根據我的理解，這意味著每次我們呼叫 TCP 配置的 ELB 時，它都會將我們的請求放在一邊，以便能夠打開與我們的 EC2 的連接，然後才將請求傳遞給機器。

引用自：https://serverfault.com/questions/871286