首先，我正在寻找一些帮助，设置我的Django和Apache设置，以便为我的网站进行微调，以获得最佳的性能成本效益。
服务器信息：Django 1.3 Webfacion服务器，当前分配80mb ram。 我没有真正触及Webfaction已经提供的http.conf。 我的网站还没有发布，但它正在运行在生产中，占用了大约17mb的主stream程和大约30mb的整体。 我今天做了一些负载testing，从来没有超过20mb的主stream程。
网站信息：单Django应用程序，性能很好，一切加载速度快（现在非常低的stream量）。 我只使用了几个模板文件，它们正在服务于我的nginx。 我只有几个模型，并且所有的处理程序都使用分页来提取数据，而且它们都没有一次在QuerySet中加载超过25条logging。 模板非常简单，只需在html和一些jsonvariables中放置一些媒体，客户端的ui全部由js驱动。 我目前没有使用djangocaching系统。 我正在计划升级并获得80MB以上的内存，我想做的最后一件事是网站变得stream行和崩溃。
有一些工具可以模拟stream量吗？ 什么更多的内存80MB真的帮助？ 有一个地方，我可以得到真正了解这个东西的人的专业意见？ （我愿意付钱）。
任何答案都会很好。 提前致谢。
更新：一切运行良好我只是想调整它。 这里是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 你可以注释掉这行：
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应用程序在进程的主要解释器中运行，并避免创build第二个子解释器。 使用主解释器将避免第三方C扩展模块的各种问题，这些模块在子解释器中不能正常运行。
这些只是简单的事情，尽pipe他们只是抓回了一些内存。
总的来说，实际上瓶颈不会在基础的networking托pipe机制。 因此，您可能希望查看可以使用哪些监视工具来监视事件并确定瓶颈。 对于开发环境，您可以使用Django的debugging工具栏，但是这个工具是非常有限的，只能用于debugging一个已知的问题，而不能真正的确定问题的根源。 对于后者，您确实需要生产监控工具，在这种情况下，您可能需要查看目前处于BETA中的New Relic。 是的，我在New Relic工作，这是我要做的，但即使这是一个付费服务的完整function，它有免费的精简版版本。 在BETA期间，虽然免费提供全部function，但值得一看，因为它可以帮助您更好地运行应用程序，所以您不必担心以后会增加stream量。