在 Amazon EC2 微型实例上从 Apache 切换后 uWSGI/nginx/Django 性能不佳

Posted 2023-02-23

技术标签:

【中文标题】在 Amazon EC2 微型实例上从 Apache 切换后 uWSGI/nginx/Django 性能不佳【英文标题】：uWSGI/nginx/Django poor performances after switching from Apache on Amazon EC2 Micro instances 【发布时间】：2014-01-17 19:20:59 【问题描述】：

我刚刚将我的服务器从 Apache/mod_wsgi 切换到 nginx/uwsgi 堆栈。然而，与 Apache 相比，我看到性能非常差，即使 在圣诞节期间服务器负载相同/甚至更少。 关于为什么我对 uWSGI/Nginx 堆栈非常陌生的任何想法？这是我的配置：

[uwsgi]

chdir = /srv/www/poka/app/poka 模块 = nginx.wsgi

home = /srv/www/poka/app/env/main

env = DJANGO_SETTINGS_MODULE=settings.prod

//master = true

进程 = 10

socket = /srv/www/poka/app/poka/nginx/poka.sock

chmod-socket = 666

真空 = 真

pidfile = /tmp/project-master.pid

原切 = 60

最大请求数 = 5000

守护进程 = /var/log/uwsgi/poka.log

【问题讨论】：

【参考方案1】：

首先，您必须确定问题出在哪里。假设你不做任何花哨的事情，比如带有巨大负载的请求，我会做一些事情：

nginx： 使用$upstream_response_time 记录上游请求的持续时间。将其与$request_time 的总响应时间进行比较。这会告诉你，时间丢失在哪里，即 nginx 是否有问题，或者上游组件（uwsgi、django、数据库……）如果 uwsgi 是问题……

uwsgi: 启用stats server，然后使用uwsgitop 快速了解统计信息如果 uwsgi 没问题，看看 Python/Django 正在做什么……

uwsgi+python: 启用pytracebacker-sockets 以查看工作人员正在做什么。如果您看到工人卡住了，请启用（如果在您的场景中这是合理的）harakiri-mode，以便 uwsgi 可以回收卡住的工人。使用 harakiri 时不要忘记启用 pytracebacker，因为它会在工作人员被杀死时为您提供 Python 堆栈跟踪。

Django：启用debug-toolbar 以查看应用程序在哪里以及花费了多少时间。

确定组件后，您就离解决方案更近了，可以提出更具体的问题。

（如果您正在执行大请求，那么 uwsgi/nginx 的压缩设置和 max-payload 相关设置可能是值得研究的好选择。它们让我们有些头疼。）

【讨论】：

【参考方案2】：

你真的需要 10 个进程吗？为什么不尝试少量？ uWSGI + Nginx 只需要 2/4 进程就可以处理大量并发请求，或许瓶颈就在那里。

【讨论】：

我把它改成了 2。我们看看效果如何！【参考方案3】：

你可以

监控 cpu/mem 以进行详细比较

安装uwsgitop（通过pip install uwsgitop）来监控你的uwsgi进程

【讨论】：