☰

nginx hängt einige POST-Anfragen für eine Weile auf

tag-icon • tag-icon nginx docker wordpress docker-compose
nginx hängt einige POST-Anfragen für eine Weile auf

Ich habe den folgenden Stack unter Ubuntu 18.08 laufen und ihn als Docker-Compose definiert:

  1. Beispiel fürmariadb:10.3.20
  2. benutzerdefinierte WordPress-Instanz basierend auf mit darauf wordpress:5.3.0-php7.2installiertemioncube
  3. benutzerdefinierte nginx-Instanz basierend auf mit darauf nginx:1.13installiertnginx-amplify-agent

nginx-Konfiguration:

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  10000;
}

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

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';

    log_format  main_ext  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for" '
                          '"$host" sn="$server_name" '
                          'rt=$request_time '
                          'ua="$upstream_addr" us="$upstream_status" '
                          'ut="$upstream_response_time" ul="$upstream_response_length" '
                          'cs=$upstream_cache_status' ;

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

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

Site wird folgendermaßen definiert:

server {
        listen 80;
        listen [::]:80;

        server_name some.org www.some.org;

        location / {
                rewrite ^ https://$host$request_uri? permanent;
        }
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name some.org www.some.org;

        index index.php index.html index.htm;

        root /var/www/html;

        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/some.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/some.org/privkey.pem;

        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header Referrer-Policy "no-referrer-when-downgrade" always;
        add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
        # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        # enable strict transport security only if you understand the implications

        location / {
                proxy_connect_timeout 600;
                proxy_send_timeout    600;
                proxy_read_timeout    600;
                proxy_redirect        off;
                proxy_pass http://wordpress;

                proxy_set_header      X-Real-IP $remote_addr;
                proxy_set_header      X-Forwarded-Proto https;
                proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header      Host $host;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }

        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }

        location ~* \.(css|js|gif|ico|jpeg|jpg|png)$ {
                expires max;
                log_not_found off;
        }
}

Der gesamte Stack funktioniert wie erwartet, es sei denn, 10-15 Benutzer besuchen die Website und versuchen, Aktionen auszuführen. In diesem Fall beginnen einige Anfragen zu hängen (normalerweise handelt es sich um dieselbe POST-Anfrage an eine Komponente) und nach 3-4 Minuten wird sie ohne Fehler freigegeben, und der Benutzer kann das Ergebnis tatsächlich sehen. Während des Hängens wird die Site vom selben Browser nicht mehr verantwortlich (aber von anderen ist alles in Ordnung!). Sobald die Anfrage freigegeben wird, ist die Site wieder verantwortlich.

Die Protokolle sind auch ziemlich seltsam:

  • Sobald eine hängende/ausstehende Anfrage beim Server eingeht, wird sie in den Nginx-Zugriffsprotokollen angezeigt, jedoch nicht in den WordPress-Protokollen.
  • Sobald die Anfrage endgültig freigegeben (d. h. bearbeitet) ist, wird sie zum zweiten Mal in den Nginx-Zugriffsprotokollen und in den WordPress-Protokollen angezeigt, die Zeiten sind jedoch unterschiedlich.

Nginx-Zugriffsprotokolle:

62.96.39.243 - - [17/Jan/2020:10:56:41 +0000] "GET /something

78.43.40.52 - - [17/Jan/2020:10:56:41 +0000] "POST /ajax-bidsform.html?meth=post&yid=d7f9f1a1a0bf HTTP/2.0" 200 208 "https://some.org/xchange_XRP_to_SBERRUB/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36" "-"

78.43.40.52 - - [17/Jan/2020:10:56:41 +0000] "GET /something

Wordpress:

134.19.130.91 - - [17/Jan/2020:10:56:40 +0000] "GET /something

78.43.40.52 - - [17/Jan/2020:10:50:07 +0000] "POST /ajax-bidsform.html?meth=post&yid=d7f9f1a1a0bf HTTP/1.0" 200 559 "https://some.org/xchange_XRP_to_SBERRUB/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36"

62.96.39.243 - - [17/Jan/2020:10:56:41 +0000] "GET /something

Wie Sie sehen, POST /ajax-bidsform.html...dauerte das Hängen in den Nginx-Protokollen 10:56, in WordPress jedoch 10:50 – und das ist genau die Zeit, zu der diese Anfrage vom Client gestellt wurde. Soweit ich das verstehe, bedeutet dies, dass die Anfrage fast 6 Minuten lang irgendwo auf Nginx-Ebene hängen blieb, bis sie tatsächlich an WordPress weitergeleitet wurde. Wie Sie sehen, habe ich keine DDoS-Schutzanweisungen von Nginx.

Auch einige Anmerkungen von meiner Seite: Während der hängenden Anfragen gibt es keine längeren CPU- oder RAM-Spitzen, also hat es wahrscheinlich nichts mit Hardwareproblemen zu tun. Ich dachte auch, dass es irgendwie mit hängenden Skripten zusammenhängt (z. B. ajax-bidsform.html), aber es begann erst, als wir vom virtuellen Hosting zur Cloud-Instanz von Digital-Ocean migrierten (wo es vorher nie passierte), also vermute ich, dass es ein Konfigurationsproblem ist. Die Zeitleiste der Anfragen in den Protokollen ist auch ein gewisser Beweis dafür.

Bisher habe ich Folgendes versucht:

  1. Erhöhung worker_connectionsauf 10.000
  2. Erhöhen Sie die Anzahl der Nginx-Instanzen (nicht die des Hosts) net.core.somaxconnauf 1024

Aber das Problem besteht immer noch.. Alle Ideen oder Gedanken sind sehr willkommen!

Antwort1

10:56 in Nginx-Protokollen, aber 10:50 in WordPress

Ich würde das so interpretieren, dass WordPress die Anfrage um 10:50 Uhr empfängt und das Ergebnis um 10:56 Uhr an nginx zurücksendet. Um sicherzugehen, können Sie upstream_response_timeto log_formatin nginx hinzufügen. SieheVerwenden der NGINX-Protokollierung zur Überwachung der Anwendungsleistung.

verwandte Informationen