Nginx反向代理和延迟

时间:2019-01-24 12:56:24

标签: nginx amazon-elb nginx-reverse-proxy nginx-config

我有一个应用程序在AWS ELB后面的nginx后面运行。该服务器运行大约30个应用程序实例。

应用程序的一部分正在处理通过HTTP POST在多部分/表单数据类型请求中发送的上载图像文件。

它可以工作,但在峰值负载延迟期间会增加大约120秒(由ELB负载均衡器测量)。上载通常需要2到7秒钟,在正常负载下,最终用户的响应时间也差不多。

运行更多应用程序实例会导致服务器内存不足,因此,解决方案是仅在高峰负载期间运行其他EC2实例。

但是,即使在高峰负载期间,请求的应用程序处理时间也在0.2秒左右。看起来,作为反向代理的Nginx应该能够缓存应用程序请求,并且仅在接收到整个有效负载后才将其转发给应用程序工作器。但似乎nginx每个应用程序工作者一次仅处理或可能一次从ELB接收一个请求。

是否有一种方法可以使最终用户的响应时间更接近如下所示的实际请求时间:

197.229.3.57 - [24/Jan/2019:11:13:51 +0000] "POST /v1/schools/69a787fc-3fde-46b1-a258-f0a1954c9abe/children/cf14ac79-9e33-434c-b5e2-8cf51d856e6f/mediamessages HTTP/1.1" RC=202 Sz=388787/388160/574 "-" Times=0.254/0.254/6.252 "client 1.1.35" zip="-" "127.0.0.1:7087"

197.229.3.68 - [24/Jan/2019:11:14:15 +0000] "POST /v1/schools/69a787fc-3fde-46b1-a258-f0a1954c9abe/children/16ced012-1c7d-41f2-969a-21ad28c80361/mediamessages HTTP/1.1" RC=202 Sz=316182/315555/574 "-" Times=0.235/0.235/3.435 "client 1.1.35" zip="-" "127.0.0.1:5085"

197.229.3.68 - [24/Jan/2019:11:14:26 +0000] "POST /v1/schools/69a787fc-3fde-46b1-a258-f0a1954c9abe/children/df5b4919-b3a9-495a-95b7-40c4b9abf523/mediamessages HTTP/1.1" RC=202 Sz=335840/335213/574 "-" Times=0.241/0.241/2.241 "client 1.1.35" zip="-" "127.0.0.1:7086"

197.229.3.68 - [24/Jan/2019:11:14:41 +0000] "POST /v1/schools/69a787fc-3fde-46b1-a258-f0a1954c9abe/children/16666420-34b3-4582-95dc-001972eb6b43/mediamessages HTTP/1.1" RC=202 Sz=229735/229108/574 "-" Times=0.216/0.216/3.956 "client 1.1.35" zip="-" "127.0.0.1:5086"

在日志中,Times = aaaaa / bbbb / cccc的值 其中:
 -aaaa是上游标题时间
 -bbbb是上游响应时间
 -cccc是request_time

nginx.conf文件的相关部分:

worker_processes 1;
#errors_log logs/error.log notice;

events {
    worker_connections 1024;
}

http {
    server_tokens off;

    log_format echo_log_format '$http_x_forwarded_for - [$time_local] '
                           '"$request" RC=$status Sz=$request_length/$http_content_length/$body_bytes_sent "$http_referer" '
                           'Times=$upstream_header_time/$upstream_response_time/$request_time '
                           '"$http_user_agent" zip="$gzip_ratio" "$upstream_addr"' ;

    sendfile on;

    client_body_temp_path /spool/nginx/client_temp 1 2;
    #client_body_in_file_only on;
    client_body_in_file_only clean;

    real_ip_header X-Forwarded-For;
    set_real_ip_from 0.0.0.0/0;

    keepalive_timeout 10m;
    client_body_timeout 20m;
    client_header_timeout 10m;
    send_timeout 10m;
    proxy_read_timeout 600;

    client_max_body_size 300M;

    gzip              on;
    gzip_http_version 1.0;
    gzip_proxied      any;
    gzip_min_length   500;
    gzip_disable      "MSIE [1-6]\.";
    gzip_types        text/plain text/xml text/css
                      text/comma-separated-values
                      text/javascript
                      application/x-javascript
                      application/atom+xml;

    # Expires map
    map $sent_http_content_type $expires {
        default                    max;
        text/html                  epoch;
        text/css                   max;
        application/javascript     max;
        ~image/                    max;
    }

    map $status $invalid {
        ~^400  1;
        default 0;
    }

    map $request $logpostdata {
        ~devices 1;
        default 0;
    }

    map $request $multimedia {
        ~multimedia 1;
        default 0;
    }

    # ELB HEALTH CHECK
    server {
        # Running port
        listen 80;
        location /ping {
            access_log off;
            return 200 "pong";
            add_header Content-Type text/plain;
        }
    }

    upstream prod_api_workers {
        server 127.0.0.1:5081;
        server 127.0.0.1:5082;
        server 127.0.0.1:5083;
        server 127.0.0.1:5084;
        server 127.0.0.1:5085;
        server 127.0.0.1:5086;
        server 127.0.0.1:5087;
        server 127.0.0.1:5088;
        server 127.0.0.1:5089;

        # NOTE port 6081 is in use by nginx
        server 127.0.0.1:6082;
        server 127.0.0.1:6083;
        server 127.0.0.1:6084;
        server 127.0.0.1:6085;
        server 127.0.0.1:6086;
        server 127.0.0.1:6087;
        server 127.0.0.1:6088;
        server 127.0.0.1:6089;

        server 127.0.0.1:7081;
        server 127.0.0.1:7082;
        server 127.0.0.1:7083;
        server 127.0.0.1:7084;
        server 127.0.0.1:7085;
        server 127.0.0.1:7086;
        server 127.0.0.1:7087;
        server 127.0.0.1:7088;
        server 127.0.0.1:7089;
    }



    # RESERVE PROXY FOR PROD (test)
    server {
        access_log /var/log/nginx/testapi_access.log echo_log_format;
        error_log /var/log/nginx/testapi_error.log;
        listen 6081;
        server_name _;

        client_max_body_size 0;
        location / {
            #proxy_redirect     off;
            proxy_set_header   X-Real-IP $remote_addr;
            proxy_set_header   X-Forwarded-For $http_x_forwarded_for;
            proxy_set_header   Host      $http_host;
            proxy_pass http://prod_api_workers;
        }
    }


}

1 个答案:

答案 0 :(得分:0)

您使用反向代理服务器是否有原因?据我所知,缩短cccc和bbbb之间的时间的唯一方法是尽可能多地踢掉代理。当然,这取决于您如何提供文件。 现在,nginx仅使用缓存直接提供文件,效果很好。 我会检查您是否可以在AWS的VLAN内进行代理。但是,如果您不能直接从AWS提供服务,则可以改为使用haproxy。