Во-первых, я знаю, что это тяжелый вопрос, но я надеюсь, что вы, ребята, сможете указать мне правильное направление ...
У нас есть несколько веб-руководителей, работающих с nginx, которые находятся за AWS ELB. Я провел несколько нагрузочных тестов в нашей системе, и ответ страницы постоянно составляет от 140 до 180 мс до ~ 600 одновременных пользователей, после чего он перескакивает до ~ 300 мс, а затем увеличивается в соответствии с увеличением количества одновременных пользователей. Поскольку пользователи являются анонимными, все ответы будут поступать из кеша Nginx и не попадать в приложение (это было подтверждено проверкой журналов запросов приложений в веб-заголовках, которые не отображают никакого контента).
Я экспериментировал с разными типами инстансов, и, похоже, это мало что изменило. Я также изменил различные настройки nginx и ядра (через sysctl), и это тоже не имеет большого значения.
Причина запуска тестов заключается в том, что мы пытаемся использовать общий кеш NFS для всех головок Nginx, но приведенная выше статистика одинакова как для общего ресурса NFS, так и для отдельных файловых кешей «на сервере».
Где я ошибаюсь?
Каждая веб-голова состоит из:
Nginx | Файловый кеш | uWSGI | Джанго
Сценарий тестирования:
Продолжительность: 1 минута. Пользователи: 1–2000 URL-адресов: 1 на запрос, который является ответом JSON API.
Количество пользователей увеличивается с 1 до 2000 одновременно в течение минуты.
В общем, я хотел бы знать, как и с помощью каких инструментов я могу определить узкие места? Я знаю, что есть несколько разных точек, где могут быть ограничения / ограничения, например. размеры буфера tcp, максимальное количество подключений и чтение / запись для файлов кеша.
По запросу конфигурация nginx выглядит следующим образом:
nginx.conf
user www-data;
worker_processes 4;
worker_rlimit_nofile 200000;
pid /run/nginx.pid;
events {
worker_connections 4000;
multi_accept on;
use epoll;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 30;
keepalive_requests 100000;
reset_timedout_connection on;
send_timeout 2;
types_hash_max_size 2048;
server_tokens off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
##
# Logging Settings
##
access_log off;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
gzip_proxied any;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Конфигурация сайта
uwsgi_cache_path /var/www/cache levels=1:2 keys_zone=STATIC:8m max_size=1000m inactive=600m;
uwsgi_temp_path /var/www/cache/tmp;
upstream server_ups {
server unix:/tmp/uwsgi.sock fail_timeout=0;
}
server {
listen 80;
client_max_body_size 4G;
uwsgi_buffers 8 16k;
uwsgi_buffer_size 32k;
uwsgi_read_timeout 300;
location / {
uwsgi_pass server_ups;
include uwsgi_params;
uwsgi_param Host $http_host;
uwsgi_param X-Real-IP $remote_addr;
uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
set $nocache 0;
if ($http_cookie ~ _ssa) {
set $nocache 1;
}
error_page 404 /404/;
error_page 500 502 503 504 /500/;
uwsgi_no_cache $nocache;
uwsgi_cache_bypass $nocache;
uwsgi_ignore_headers Set-Cookie;
uwsgi_ignore_headers Cache-Control;
uwsgi_ignore_headers X-Accel-Expires;
uwsgi_cache STATIC;
uwsgi_param X-Cache-Status $upstream_cache_status;
uwsgi_cache_key $http_host$request_uri;
uwsgi_cache_valid 200 30m;
uwsgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
}
}
Используйте инструменты мониторинга производительности. Попробуйте собрать показатели и построить их график. Нет ничего лучше графиков.
В таких ситуациях может оказаться очень полезным такой инструмент, как Munin. Посмотрите на память, io, процессы, ЦП, сеть, прерывания, nfs и т. Д. С течением времени. Также экспортируйте метрики nginx и нанесите их на график.
Также имейте в виду, что при тестировании с одного клиентского компьютера вы можете столкнуться с узкими местами или ограничениями на стороне клиента.