502 mauvaises erreurs de passerelle après 68 users simultanés sur le site Web

Je suis confronté à des problèmes tout en effectuant des tests de stress dans jMeter. Essentiellement, nous atteignons une limite difficile de 68 users simultanés. Dès que le test augmente jusqu'à ce nombre d'users, nous recevons 502 mauvaises erreurs de passerelle.

Ce qui est intéressant, c'est que nous avons le même comportement de défaillances chez 68 users sur une machine virtuelle avec le double de la CPU et de la RAM. Cela m'amène à croire qu'il s'agit d'un problème de configuration. Après tout, les configurations sont identiques entre nos conteneurs docker sur chaque server.

J'ai essayé d'augmenter le paramètre worker_connections dans nginx.conf mais cela n'a aucun effet. J'ai même redémarré la machine pour m'assurer que le nouveau réglage était appliqué.

Y a-t-il d'autres idées sur ce qu'il faut examiner ou essayer?

Je ne sais pas si cela aide, mais voici notre configuration sur le server nginx qui échoue …

upstream unicorn_server { server unix:/app/tmp/unicorn.sock fail_timeout=0; keepalive 512; } server { listn 4043 ssl; ssl_certificatee /etc/nginx/certs/hive.crt; ssl_certificatee_key /etc/nginx/certs/hive.key; gzip on; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types application/json; root /app/public; try_files $uri @unicorn_server; keepalive_timeout 10; location @unicorn_server { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto https; # if use ssl proxy_redirect off; proxy_pass http://unicorn_server; proxy_http_version 1.1; } location ~ ^/(assets|images|javascripts|stylesheets|swfs|system)/ { gzip_static on; expires max; add_header Cache-Control public; add_header Last-Modified ""; add_header ETag ""; open_file_cache max=1000 inactive=500s; open_file_cache_valid 600s; open_file_cache_errors on; break; } } 

One Solution collect form web for “502 mauvaises erreurs de passerelle après 68 users simultanés sur le site Web”

Cela peut ne pas être un problème de site. Cela peut arriver à des problèmes vifs entre votre générateur de charge et la cible. Pouvez-vous nous en dire plus sur votre infrastructure de test? Où se trouvent les générateurs de charge par rapport à l'application / server testé? Avez-vous besoin de traverser des proxies pour votre communication? Comment peut-on traverser le houblon, ce qui peut limiter votre request?

  • Où le vernis va-t-il généralement dans une stack Web Rails?
  • Redmine servi via Apache / Unicorn
  • Ecriture d'un file de configuration upstart pour Unicorn
  • Les travailleurs de licorne disparaissent
  • Nginx et Unicorn sur des machines séparées
  • Demande de timeout d'attente avec nginx, licorne et rails
  • Nginx Returning 504 Error
  • Forward IP réelle via Haproxy => Nginx => Unicorn
  • Applications multiples Nginx + Unicorn avec location - routing
  • L'opération n'est pas autorisée lors du démarrage de la Licorne
  • Gitlab redirect loop lorsque vous requestz archive.zip
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.