Problèmes liés à la limitation du taux nginx limit_req – clarification de la documentation?

Je n’ai aucun problème à obtenir une limitation des tarifs pour travailler sur Nginx avec passagers / rails.

Une partie de la confusion vient de la distinction entre les aspects de la configuration fonctionnant pour chaque client et les limites globales.

J’ai des problèmes pour comprendre la configuration idéale pour les configs limit_req et limit_req_zone de nginx. Il semble que cela bascule vaguement entre les langages, ce qui laisse entendre que cela est soit spécifique à l’utilisateur, soit à l’échelle mondiale.

Dans les docs, il est assez vague de voir exactement comment fonctionne la ligne limit_req_zone . Cette ‘zone’ est-elle globale ou par utilisateur? Compte tenu de la ligne suivante suis-je dans les conclusions suivantes:

• GitLab postfix configuration mail ne pas envoyer
• Nginx: broken_header avec proxy_protocol et ELB
• Comment vérifier que socket est vivant (connecté) dans socket.io avec plusieurs nœuds et socket.io-redis
• Comment convertir mod_rewrite (option QSA) en équivalent Nginx?
• Différence entre Nginx et Mongrel?

 limit_req_zone $binary_remote_addr zone=update_requests:1m rate=20r/s; 

1. $ binary_remote_addr représente l’adresse IP d’un utilisateur
2. Cette représentation en particulier est préférable car elle prend moins de place que $ remote_addr? Pourquoi est-ce important ou préférable?
3. La ‘zone’ (dans ce cas) est remplie avec des représentations de leur adresse IP …?
4. “taux” est le taux auquel les demandes sont autorisées à quitter la queue?
5. Ce “taux” et cette “zone” sont-ils spécifiques au client ou globaux?

Je ne suis pas sûr non plus de la ligne limit_req, par exemple:

 limit_req zone=main_site burst=10 nodelay; 

6. Pas tout à fait sûr de ce que signifie l’éclatement. Les documents sont vagues ici aussi. Je suppose que c’est un certain nombre de demandes. Pourquoi nombre de requêtes, alors que le rest du système de requêtes utilise ce système de “zone” bizarre?
7. Les demandes «en rafale» sont par …. quel délai?
8. Si j’ai bien compris, «nodelay» est censé servir immédiatement une erreur 503 s’il y a d’autres demandes dans la queue, au lieu d’attendre que la queue se termine. a) attendre combien de temps? b) cela signifie-t-il que le paramètre «rafale» est ignoré dans ce cas?

Merci.

---

Quelques informations de base au cas où quelqu’un s’ennuie vraiment et veut jeter un coup d’œil aux problèmes de configuration et aux problèmes généraux que nous essayons de résoudre:

En ce moment j’ai ceci (extrait):

 limit_req_zone $binary_remote_addr zone=main_site:10m rate=40r/s; limit_req_zone $binary_remote_addr zone=update_requests:1m rate=20r/s; server { listen 80; server_name [removed]; root [removed]; include rtmp_proxy_settings; try_files $uri /system/maintenance.html @passenger; location @passenger { passenger_max_request_queue_size 0; # 256; limit_rate_after 2048k; limit_rate 512k; limit_req zone=main_site burst=10 nodelay; limit_conn addr 5; passenger_enabled on; passenger_min_instances 3; } location ~ ^/update_request { passenger_enabled on; limit_req zone=update_requests burst=5 nodelay; } gzip on; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/xml application/javascript text/javascript text/css; gzip_disable "msie6"; gzip_http_version 1.1; } 

Nous avons deux zones définies:

a) “main_site”, conçu pour tout saisir b) “update_request”, JS interroge le client via AJAX pour le contenu mis à jour lorsqu’un horodatage dans un petit fichier (en cache) change

De par sa nature, cela signifie que nous avons un trafic assez faible pendant 1 ou 2 minutes, puis un pic massif lorsque potentiellement 10 000 clients frappent tous le serveur en même temps pour ce contenu mis à jour (servi de la firebase database , permissions d’access, etc.)

Nous nous sums aperçus que pendant les périodes de forte charge, le site s’arrêtait lorsque les cœurs du processeur étaient au maximum – nous avions quelques bogues dans notre code de mise à jour, ce qui signifiait que lorsque la connexion était interrompue Serveur jusqu’à ce que nous devions arrêter temporairement le site et forcer les utilisateurs à se déconnecter et à actualiser leur navigateur … efficacement nous nous sums infiltrés: PI pense que cela était dû à des problèmes de connectivité du côté de notre société d’hébergement faire la queue dans le navigateur de l’utilisateur.

Tandis que nous corrigions les bogues, nous avons prévenu les clients qu’ils pourraient recevoir le message 503 “lourd” ou que le contenu ne serait pas mis à jour rapidement. L’intention initiale de la limitation de débit était de garantir que les pages quotidiennes du site puissent continuer à être consultées, même en cas de charge importante, tout en limitant le contenu mis à jour.

Cependant, le principal problème que nous constatons actuellement est que, même si nous espérons que les bogues du code de mise à jour auront été corrigés, nous ne pourrons pas trouver un bon équilibre entre les limitations de taux. Tout ce que nous définissons semble générer un nombre malsain de 503 erreurs dans les journaux d’access chaque fois qu’un nouveau contenu est ajouté au site (et tiré par nos utilisateurs en même temps).

Nous examinons diverses solutions ici en termes de mise en cache, mais idéalement, nous aimerions quand même être protégés par une sorte de limitation de débit qui n’affecte pas les utilisateurs pendant les opérations quotidiennes.

• configuration échoue paramètre nginx pour tornadoweb, directive inconnue “utilisateur”
• Routes Laravel non trouvées après nginx isntall
• Envoi d’informations à un ngnix à partir de php sur le même serveur sans http
• Force www. et https dans nginx.conf (SSL)
• nginx – etag manquant lorsque gzip est utilisé