☰

Skalierung und Belastungstests für Django, Nginx und Gunicorn: 502 Serverfehler + Ressource vorübergehend nicht verfügbar gunicorn.sock

tag-icon • tag-icon ubuntu nginx django socket gunicorn
Skalierung und Belastungstests für Django, Nginx und Gunicorn: 502 Serverfehler + Ressource vorübergehend nicht verfügbar gunicorn.sock

Ich führe einen Belastungstest mit Locust durch, um zu sehen, ob mein Server 1500 Benutzer verarbeiten kann.

Was ich verwende: Django, Nginx, Gunicorn, Postgresql. Mein Droplet: 24 vCPUs, 128 GB RAM, 25 GB SSD.

bei etwa 1100 Benutzern erhalte ich in Locust die folgenden Fehler:

GET / HTTPError('502 Server Error: Bad Gateway for url: myurl.here ')
GET /aboutpage/     HTTPError('502 Server Error: Bad Gateway for url: myurl.here ')

In meinem Nginx-Fehlerprotokoll erhalte ich die folgenden Fehler:

2020/01/26 23:14:17 [error] 30465#30465: *167765 connect() to unix:/var/www/file/to/sock/gunicorn failed (11: Resource temporarily unavailable) while connecting to upstream, client: 8x.8x.1xx.3x, server: mysite.here, request: "GET // HTTP/1.1", upstream: "http://unix:/var/www/file/to/sock/gunicorn://", host: "mysite.here"

aus irgendeinem Grund wird mir mitgeteilt, dass meine Ressource vorübergehend nicht verfügbar ist.

Hier ist meine nginx.conf:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 2048;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        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_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        # Virtual Host Configs
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Und hier ist meine Serverblockkonfiguration:


upstream mysite-production {
    server unix:/var/www/path/to/sock/gunicorn;
}
server {
    listen [::]:80;
    listen 80;
    server_name mysite.here;

    # set client body size to 100M #
    client_max_body_size 100M;

    location / {
      include proxy_params;
      proxy_pass http://unix:/var/www/path/to/sock/gunicorn;
      auth_basic "Restricted Content";
      auth_basic_user_file /etc/nginx/.htpasswd;
    }

    location /static/ {
        root /var/www/site/production/;
        expires 30d;
        add_header Vary Accept-Encoding;
        access_log off;
        gzip on;
        gzip_comp_level 6;
        gzip_vary on;
        gzip_types text/plain text/css application/json application/x-javascript application/javascript text/xml application/xml application/rss+xml text/javascript image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype;
    }

    location /media/ {
        root /var/www/site/production/;
        expires 30d;
        add_header Vary Accept-Encoding;
        access_log off;
    }



}

Hier ist meine Gunicorn-Servicedatei:

[Unit]
Description=mysite production daemon
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/path/to/site/src
ExecStart=/var/www/path/to/venv/bin/gunicorn  --workers=49 --bind unix:/var/www/path/to/sock/gunicorn --log-level DEBUG --log-file '/var/www/path/to/log/gunicorn.log' mysite.wsgi:application
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

Was könnte die Ursache für dieses Problem sein? Wir gehen davon aus, dass etwa 1500-2000 Benutzer gleichzeitig auf der Site sind.

Vielen Dank, dass du dir die Zeit nimmst! Ich freue mich auf deine Antworten!

Antwort1

Bei Belastungstests stoßen Sie immer auf Grenzen und Engpässe.

In Ihrem Fall müssen Sie erhöhen inGunicorn-KonfigurationÄndern backlogSie den Standardwert in 2048einen Wert, den Ihr Server verarbeiten kann.

verwandte Informationen