Django，gunicorn 4 个 worker 的每秒请求量较低

Question

我试图了解为什么我的 django 网站(gunicorn 4 worker )在重负载下速度很慢，我做了一些分析http://djangosnippets.org/snippets/186/没有任何明确的答案，所以我使用 ab -n 1000 -c 100 http://localhost:8888/

从头开始​​一些负载测试

一个简单的 Httpreponse("hello world") 无中间件 ==> 3600req/s

带有中间件(缓存 session 、缓存身份验证)的简单 Httpreponse("hello world") ==> 2300req/s

一个简单的render_to_response，仅打印表单(缓存模板)==> 1200req/s(响应时间除以2)

带有 50 个内存缓存查询的简单 render_to_response ==> 157req/s

Memcache 查询应该比这快得多(我正在使用 PyLibMCCache)？ 模板渲染是否像这个结果一样慢？

我尝试了不同的分析技术，但没有成功。

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 46936
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 400000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 46936
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

$ sysctl -p

fs.file-max = 700000
net.core.somaxconn = 5000
net.ipv4.tcp_keepalive_intvl = 30

我使用的是 ubuntu 12.04(6Go 内存，核心 i5)

请问有什么帮助吗？

Answer 1

这实际上取决于执行 memcached 请求和打开新连接所需的时间(django 在请求完成时关闭连接)，您的工作线程和 memcached 都能够处理更多的压力，但当然如果它执行一次 memcached 调用需要 5/10 毫秒，那么其中 50 个将成为瓶颈，因为网络延迟乘以调用计数。

现在您只是对 django、gunicorn、您的机器和网络进行基准测试。

除非你在这个级别上遇到了极其错误的事情，否则这个测试不会给你带来非常有趣的发现。

应用程序运行速度变慢的原因很可能与您使用数据库和内存缓存的方式有关(也可能与模板渲染时的方式有关)。

因此，我强烈建议您使用 django 调试工具栏并查看真实页面中发生的情况。

如果发现打开与 memcached 的连接是瓶颈，您可以尝试使用连接池并保持连接打开。