☰

Производительность Nginx + uWSGI + Django застряла на 100rq/s

tag-icon • tag-icon nginx python django centos6 uwsgi
Производительность Nginx + uWSGI + Django застряла на 100rq/s

Я настроил Nginx с uWSGI и Django на CentOS 6 x64 (3,06 ГГц i3 540, 4 ГБ), который должен легко обрабатывать 2500 запросов/с, но когда я запускаю ab-тест ( ab -n 1000 -c 100 ), производительность останавливается на уровне 92–100 запросов/с.

Nginx:
    user nginx;
    worker_processes 2;
    events {
        worker_connections 2048;
        use epoll;
    }

uWSGI:

    Emperor
    /usr/sbin/uwsgi --master --no-orphans --pythonpath /var/python --emperor /var/python/*/uwsgi.ini


[uwsgi]
socket = 127.0.0.2:3031
master = true
processes = 5

env = DJANGO_SETTINGS_MODULE=x.settings
env = HTTPS=on
module = django.core.handlers.wsgi:WSGIHandler()

disable-logging = true
catch-exceptions = false

post-buffering = 8192
harakiri = 30
harakiri-verbose = true

vacuum = true
listen = 500
optimize = 2

sysclt changes:
# Increase TCP max buffer size setable using setsockopt()
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608

net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_syn_backlog = 5000
net.ipv4.tcp_window_scaling = 1
net.core.somaxconn = 2048

# Avoid a smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Optimization for port usefor LBs
# Increase system file descriptor limit
fs.file-max = 65535

Я сделал это sysctl -p, чтобы включить изменения.

Информация о неактивном сервере:

top - 13:34:58 up 102 days, 18:35,  1 user,  load average: 0.00, 0.00, 0.00

Tasks: 118 total,   1 running, 117 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   3983068k total,  2125088k used,  1857980k free,   262528k buffers

Swap:  2104504k total,        0k used,  2104504k free,   606996k cached



free -m

 total       used       free     shared    buffers     cached

Mem:          3889       2075       1814          0        256        592

-/+ buffers/cache:       1226       2663

Swap:         2055          0       2055




**During the test:**

top - 13:45:21 up 102 days, 18:46,  1 user,  load average: 3.73, 1.51, 0.58

Tasks: 122 total,   8 running, 114 sleeping,   0 stopped,   0 zombie

Cpu(s): 93.5%us,  5.2%sy,  0.0%ni,  0.2%id,  0.0%wa,  0.1%hi,  1.1%si,  0.0%st

Mem:   3983068k total,  2127564k used,  1855504k free,   262580k buffers

Swap:  2104504k total,        0k used,  2104504k free,   608760k cached


free -m

total       used       free     shared    buffers     cached

Mem:          3889       2125       1763          0        256        595

-/+ buffers/cache:       1274       2615

Swap:         2055          0       2055


iotop

30141 be/4 nginx       0.00 B/s    7.78 K/s  0.00 %  0.00 % nginx: wo~er process

Где узкое место? Или что я делаю не так?

решение1

Очевидно, что любая задача, которую вы используете, ограничена процессором. Вы можете рассмотреть возможность профилирования вашего приложения Django, чтобы узнать, где оно отстает. Существует несколько решений для профилирования приложений Python WSGI (хотя Django не является строго совместимым с WSGI, особенно с промежуточным ПО, поэтому YMMV):

  1. судья на линии(бесстыдная реклама, это мой проект!)
  2. keas.профиль
  3. repoze.profile
  4. бульдозер(но вам нужно будет использовать альфу 0.2)

Это позволит вам выявить узкие места в вашем приложении, т. е. на какие функции ваше приложение тратит большую часть времени?

Еще один момент, который следует проверить, — сколько времени требуется uwsgi/nginx для обработки запроса? Ставятся ли запросы в очередь? Сколько времени в среднем занимает запрос от начала до конца? И, что еще важнее, каков ваш базовый уровень? Попробуйте запустить тот же тест с 1 одновременным пользователем, чтобы выяснить это. Затем постепенно увеличивайте количество пользователей, пока не сможете определить, где количество пользователей достигает пика.

Имея эту информацию, вы можете начать устанавливать закономерность — а это ключ к нагрузочному тестированию!

Удачи!

Связанный контент