☰

如何诊断特定用户数量的 Nginx 瓶颈

tag-icon • tag-icon nginx amazon-ec2 performance-tuning
如何诊断特定用户数量的 Nginx 瓶颈

首先，我知道这是一个引导性问题，但我希望你们能够为我指明正确的方向……

我们有许多使用 nginx 前端的 Web 站点，这些站点位于 AWS ELB 后面。我对我们的系统进行了多次负载测试，页面响应时间始终在 140 到 180 毫秒之间，直到并发用户数达到约 600 人，此时响应时间会跳升到约 300 毫秒，然后随着并发数的增加而增加。由于用户是匿名的，因此所有响应都将来自 Nginx 缓存，而不会影响应用程序（这已通过检查未显示任何内容的 Web 站点上的应用程序请求日志得到确认）。

我尝试过各种实例类型，但似乎没有什么区别。我还更改了各种 nginx 和内核（通过 sysctl）设置，但似乎也没有太大区别。

运行测试的原因是我们正在尝试为所有 Nginx 头使用 NFS 共享缓存，但上述统计数据对于 NFS 共享和单独的“服务器上”文件缓存都是相同的。

我哪里做错了？

每个 Web Head 包括：

Nginx | 文件缓存 | uWSGI | Django

测试场景是：

持续时间：1 分钟用户：1 - 2000 URL：每个请求 1 个，是 JSON API 响应。

一分钟内，用户数量从 1 个并发增加到 2000 个并发。

所以基本上，我想知道如何以及用什么工具可以确定瓶颈在哪里？我知道有许多不同的点可能存在限制/约束，例如 tcp 缓冲区大小、最大连接数和缓存文件的读/写。

根据要求，nginx配置如下：

nginx.conf

user www-data;
worker_processes 4;
worker_rlimit_nofile 200000;
pid /run/nginx.pid;

events {
    worker_connections 4000;
    multi_accept on;
    use epoll;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 30;
    keepalive_requests 100000;
    reset_timedout_connection on;
    send_timeout 2;
    types_hash_max_size 2048;
    server_tokens off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    file_cache max=200000 inactive=20s; 
    open_file_cache_valid 30s; 
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    ##
    # Logging Settings
    ##

    access_log off;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;


    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

站点配置

uwsgi_cache_path  /var/www/cache levels=1:2 keys_zone=STATIC:8m max_size=1000m inactive=600m;
uwsgi_temp_path /var/www/cache/tmp;

upstream server_ups { 
    server unix:/tmp/uwsgi.sock fail_timeout=0;
}

server {
    listen   80;
    client_max_body_size 4G;

    uwsgi_buffers 8 16k;
    uwsgi_buffer_size 32k;
    uwsgi_read_timeout 300;

    location / {
        uwsgi_pass server_ups;
        include uwsgi_params;
        uwsgi_param   Host             $http_host;
        uwsgi_param   X-Real-IP        $remote_addr;
        uwsgi_param   X-Forwarded-For  $proxy_add_x_forwarded_for;

        set $nocache 0;

        if ($http_cookie ~ _ssa) {
            set $nocache 1;
        }

        error_page 404 /404/;
        error_page 500 502 503 504 /500/;

        uwsgi_no_cache $nocache;
        uwsgi_cache_bypass $nocache;

        uwsgi_ignore_headers Set-Cookie;
        uwsgi_ignore_headers Cache-Control;
        uwsgi_ignore_headers X-Accel-Expires;
        uwsgi_cache STATIC;
        uwsgi_param X-Cache-Status $upstream_cache_status;
        uwsgi_cache_key $http_host$request_uri;
        uwsgi_cache_valid      200  30m;
        uwsgi_cache_use_stale  error timeout invalid_header updating http_500 http_503;
    }
}

答案1

使用性能监控工具。尝试收集指标并绘制图表。没有什么比图表更有效。

在这些情况下，像 Munin 这样的工具非常有用。查看一段时间内的内存、io、进程、cpu、网络、中断、nfs 等。导出 nginx 指标并绘制图表。

http://munin-monitoring.org/

还请记住，当从单个客户端机器进行基准测试时，您可能会遇到客户端的瓶颈或限制。

相关内容