Назад | Перейти на главную страницу

Как диагностировать узкие места Nginx у определенного количества пользователей

Во-первых, я знаю, что это тяжелый вопрос, но я надеюсь, что вы, ребята, сможете указать мне правильное направление ...

У нас есть несколько веб-руководителей, работающих с nginx, которые находятся за AWS ELB. Я провел несколько нагрузочных тестов в нашей системе, и ответ страницы постоянно составляет от 140 до 180 мс до ~ 600 одновременных пользователей, после чего он перескакивает до ~ 300 мс, а затем увеличивается в соответствии с увеличением количества одновременных пользователей. Поскольку пользователи являются анонимными, все ответы будут поступать из кеша Nginx и не попадать в приложение (это было подтверждено проверкой журналов запросов приложений в веб-заголовках, которые не отображают никакого контента).

Я экспериментировал с разными типами инстансов, и, похоже, это мало что изменило. Я также изменил различные настройки nginx и ядра (через sysctl), и это тоже не имеет большого значения.

Причина запуска тестов заключается в том, что мы пытаемся использовать общий кеш NFS для всех головок Nginx, но приведенная выше статистика одинакова как для общего ресурса NFS, так и для отдельных файловых кешей «на сервере».

Где я ошибаюсь?

Каждая веб-голова состоит из:

Nginx | Файловый кеш | uWSGI | Джанго

Сценарий тестирования:

Продолжительность: 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;
    }
}

Используйте инструменты мониторинга производительности. Попробуйте собрать показатели и построить их график. Нет ничего лучше графиков.

В таких ситуациях может оказаться очень полезным такой инструмент, как Munin. Посмотрите на память, io, процессы, ЦП, сеть, прерывания, nfs и т. Д. С течением времени. Также экспортируйте метрики nginx и нанесите их на график.

http://munin-monitoring.org/

Также имейте в виду, что при тестировании с одного клиентского компьютера вы можете столкнуться с узкими местами или ограничениями на стороне клиента.