☰

微调 Django Apache mod_wsgi

tag-icon • tag-icon django apache-2.2 mod-wsgi
微调 Django Apache mod_wsgi

首先，我需要一些帮助来设置我的 Django 和 Apache 设置，以便针对我的网站进行微调，实现最佳的性能成本效益。

服务器信息：Django 1.3 Webfacion 服务器，目前分配了 80mb 内存。我还没有真正接触过 Webfaction 已经提供的 http.conf。我的网站尚未发布，但它正在生产中运行，主进程占用约 17mb，总体占用约 30mb。我今天做了一些负载测试，主进程从未超过 20mb。

站点信息：单个 Django 应用程序，性能很棒，加载速度很快（现在流量非常低）。我只使用几个模板文件，它们由我的 nginx 提供服务。我只有几个模型，所有处理程序都使用分页提取数据，并且它们都不会一次在 QuerySet 中加载超过 25 条记录。模板非常简单，只需在 html 中放入一些媒体和几个 json 变量，客户端 ui 全部由 js 驱动。我目前没有使用 django 缓存系统。我计划升级并获得 80mb 以上的内存，我最不想发生的事情就是网站变得流行并崩溃。

有没有一些工具可以模拟流量？80MB 以上的 RAM 真的能有什么帮助？有没有地方可以让我得到真正了解这方面的人的专业建议？（我愿意付钱给他们）。

任何答案都非常好。提前致谢。

更新：一切运行良好，我只是想对其进行微调。这是 httpd.conf 文件：

ServerRoot "/home/pllee/webapps/django/apache2"

LoadModule dir_module        modules/mod_dir.so
LoadModule env_module        modules/mod_env.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module       modules/mod_mime.so
LoadModule rewrite_module    modules/mod_rewrite.so
LoadModule setenvif_module   modules/mod_setenvif.so
LoadModule wsgi_module       modules/mod_wsgi.so

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog /home/pllee/logs/user/access_django.log combined
ErrorLog /home/pllee/logs/user/error_django.log
KeepAlive Off
Listen 22504
MaxSpareThreads 3
MinSpareThreads 1
ServerLimit 1
SetEnvIf X-Forwarded-SSL on HTTPS=1
ThreadsPerChild 5
WSGIDaemonProcess django processes=5 python-path=/home/pllee/webapps/django:/home/pllee/webapps/django/lib/python2.7 threads=1
WSGIPythonPath /home/pllee/webapps/django:/home/pllee/webapps/django/lib/python2.7
WSGIScriptAlias / /home/pllee/webapps/django/SiteName.wsgi

答案1

您可以注释掉以下行：

WSGIDaemonProcess django processes=5 \
  python-path=/home/pllee/webapps/django:/home/pllee/webapps/django/lib/python2.7 \
  threads=1

首先。这一行除了启动五个进程外什么都不做，而这些进程随后就闲置在那里，什么也不做。

这是 WebFaction 一段时间以来一直犯的错误。他们指定了一个守护进程组，但实际上并没有定义 WSGIProcessGroup 指令来让 mod_wsgi 在其中运行您的 WSGI 应用程序。

由于您只运行一个 WSGI 应用程序，因此接下来可以做的是添加：

WSGIApplicationGroup %{GLOBAL}

这将导致 WSGI 应用程序在进程的主解释器中运行，并避免创建第二个子解释器。使用主解释器将避免第三方 C 扩展模块无法在子解释器中正常运行的各种问题。

尽管这些只是恢复一些记忆而已，但这些都是你可以做到的简单的事情。

总体而言，实际上瓶颈不会出现在底层的网络托管机制中。因此，您可能需要查看可以使用哪些监控工具来监控事物并识别瓶颈。对于开发环境，您有 Django 调试工具栏，但它会非常有限，并且仅对调试已知问题有用，而不能真正识别问题的根源。对于后者，您确实需要生产监控工具，在这种情况下，您可能需要看看 New Relic，它目前针对 Python 处于测试阶段。是的，我在 New Relic 工作，这就是我正在做的事情，但即使它是一项具有完整功能的付费服务，它也有一个免费的精简版。在测试期间，它的完整功能是免费的，因此值得一看，因为它可以帮助您更好地运行应用程序，这样您就不必担心以后流量增加。

相关内容