Eu configurei Nginx com uWSGI e Django no CentOS 6 x64 (3,06 GHz i3 540, 4 GB), que deve lidar facilmente com 2.500 rq/s, mas quando executo um teste ab ( ab -n 1000 -c 100 ) o desempenho para em 92 - 100 q/s.
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
Eu fiz sysctl -p
para ativar as alterações.
Informações do servidor inativo:
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
Onde está o gargalo? Ou o que estou fazendo de errado?
Responder1
Claramente, qualquer tarefa que você esteja usando está vinculada à CPU. Você pode considerar criar um perfil de seu aplicativo Django para descobrir onde seu aplicativo está atrasado. Existem várias soluções de criação de perfil para aplicações Python WSGI (embora o Django não seja estritamente compatível com WSGI, especialmente com middleware, então YMMV):
- bandeirinha(plug sem vergonha, esse é o meu projeto!)
- keas.perfil
- repoze.perfil
- escavadeira(mas você precisará usar o alfa 0,2)
Isso permitirá que você identifique gargalos em seu aplicativo – ou seja, em quais funções seu aplicativo passa a maior parte do tempo?
Outra coisa a verificar é quanto tempo leva para o uwsgi/nginx atender uma solicitação? As solicitações estão sendo enfileiradas? Quanto tempo leva uma solicitação média do início ao fim? Além disso, mais importante, qual é a sua linha de base? Tente executar o mesmo teste com 1 usuário simultâneo para descobrir isso. Em seguida, aumente gradativamente o número de usuários até conseguir identificar onde o número de usuários atinge o pico.
Com essas informações, você pode começar a estabelecer um padrão – e essa é a chave para o teste de carga!
Boa sorte!