(nginx + gunicorn) небольшой экземпляр сервера сбрасывает / задерживает соединения при +60 простых запросах API в секунду.Можно ли это улучшить? - PullRequest
Новая
       6

(nginx + gunicorn) небольшой экземпляр сервера сбрасывает / задерживает соединения при +60 простых запросах API в секунду.Можно ли это улучшить?

1 голос
/ 22 апреля 2019

Я устанавливаю первую производственную архитектуру для моего приложения на основе Django.Я использую nginx + gunicorn + удаленную настройку базы данных postgres.

После выполнения простых нагрузочных тестов API с помощью https://loader.io я обнаружил, что при увеличении числа клиентов, отправляющих запросы API, со скоростью более 60 клиентов в секунду в течение 30-секундного теста, инструмент показывает ошибки, которыевремя ожидания соединения.

При использовании двойной настройки сервера с балансировщиком нагрузки я могу удвоить число клиентов / секунду, но я ожидаю, что одна установка оперативной памяти 3vCPU / 1 ГБ сможет обрабатывать более 30 запросов / секунду - я прав?

Я перепробовал множество различных параметров конфигурации gunicorn / nginx, но, похоже, ничего не помогло.

Это содержимое моего /etc/nginx/nginx.conf файла: 

user www-data;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 100000;

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

http {  

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        server_names_hash_bucket_size 512;

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

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

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

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        gzip_vary on;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
        reset_timedout_connection on;
        keepalive_requests 100000;



       ##
        # Virtual Host Configs
        ##

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

Это содержимое моего /etc/nginx/sites-available/MY_DOMAIN файла: 

server {
        listen 80;
        listen [::]:80;
        server_name MY_DOMAIN www.MY_DOMAIN;
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl on;
        client_max_body_size 5M;

        server_name MY_DOMAIN www.MY_DOMAIN;
        location = /favicon.ico { access_log off; log_not_found off; }
        location /static/ {
                root /var/www/backend;
        }
        location /loaderio-b061bddf86a67379411d4ef54f7ee430/ {
                root /var/www/backend;
        }
        location / {
                include         proxy_params;
                proxy_pass      http://unix:/var/www/backend/MY_SOCKET.sock;
        }

        location /ws/ {
                include         proxy_params;
                proxy_pass      http://unix:/var/www/backend/ws.sock;

                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";

                proxy_redirect     off;
                proxy_set_header   Host $host;
                proxy_set_header   X-Real-IP $remote_addr;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Host $server_name;
                proxy_connect_timeout       300;
                proxy_send_timeout          300;
                proxy_read_timeout          300;
                send_timeout                300;
        }
        ssl_certificate /etc/letsencrypt/live/MY_DOMAIN/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/MY_DOMAIN/privkey.pem; # managed by Certbot

Это содержимое моего файла супервизора: 

[program:gunicorn]
directory=/var/www/backend
command=/root/.pyenv/versions/VENV_NAME/bin/gunicorn --workers 5 --keep-alive 15 --worker-class gevent --bind unix:/var/www/backend/SOCK_NAME.sock config.wsgi:application
autostart=true
autorestart=true
log_level=debug
stderr_logfile=/var/log/gunicorn/gunicorn.out.log
stdout_logfile=/var/log/gunicorn/gunicorn.err.log
user=root
group=www-data
environment=LANG=en_US.UTF-8,LC_ALL=en_US.UTF-8

[program:daphne]
directory=/var/www/backend
command=/root/.pyenv/versions/VENV_NAME/bin/daphne -u /var/www/backend/ws.sock config.asgi:application
autostart=true
autorestart=true
stderr_logfile=/var/log/daphne/daphne.out.log
stdout_logfile=/var/log/daphne/daphne.err.log
user=root
group=www-data
environment=LANG=en_US.UTF-8,LC_ALL=en_US.UTF-8

[group:GROUP_NAME]
programs:gunicorn,daphne

При выполнении теста нагрузки значения CPU vCores находятся междуЗагрузка 10-18% и использование ОЗУ около 70%

Возможно ли повысить производительность этого экземпляра отдельного сервера выше 60 req / sec или это просто аппаратное ограничение (я уже пробовал цифровой Ocean 16vCPUРазмер капель оперативной памяти 8 ГБ и результаты практически одинаковы (независимо от того, были ли задействованы 5 или 15 рабочих)?

...