Ich habe Nginx mit uWSGI und Django auf CentOS 6 x64 (3,06 GHz i3 540, 4 GB) konfiguriert, was problemlos 2500 rq/s bewältigen sollte, aber wenn ich einen Ab-Test ausführe (ab -n 1000 -c 100), bleibt die Leistung bei 92 - 100 rq/s stehen.
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
Ich habe es sysctl -pgetan, um Änderungen zu ermöglichen.
Informationen zum inaktiven Server:
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
Wo ist der Flaschenhals? Oder was mache ich falsch?
Antwort1
Es ist klar, dass die von Ihnen verwendete Aufgabe CPU-gebunden ist. Sie sollten Ihre Django-App profilieren, um herauszufinden, wo Ihre Anwendung verzögert ist. Es gibt mehrere Profilierungslösungen für Python-WSGI-Anwendungen (obwohl Django nicht streng WSGI-kompatibel ist, insbesondere bei Middleware, also Ihre Ergebnisse können abweichen):
- Linienrichter(unverhohlene Werbung, das ist mein Projekt!)
- keas.profile
- repoze.profile
- Planierraupe(aber Sie müssen 0,2 Alpha verwenden)
Auf diese Weise können Sie Engpässe in Ihrer Anwendung identifizieren, d. h. mit welchen Funktionen verbringt Ihre Anwendung die meiste Zeit?
Überprüfen Sie außerdem, wie lange es dauert, bis uwsgi/nginx eine Anfrage entgegennimmt. Werden Anfragen in die Warteschlange gestellt? Wie lange dauert eine durchschnittliche Anfrage von Anfang bis Ende? Und was noch wichtiger ist: Was ist Ihr Ausgangswert? Um dies herauszufinden, führen Sie den gleichen Test mit einem gleichzeitigen Benutzer durch. Erhöhen Sie dann schrittweise die Anzahl der Benutzer, bis Sie feststellen können, wo die Anzahl der Benutzer ihren Höhepunkt erreicht.
Mit diesen Informationen können Sie beginnen, ein Muster zu ermitteln – und das ist der Schlüssel zum Belastungstest!
Viel Glück!