The Django Book

Basic Configuration

基本�置

To configure Django with mod_python, first make sure you have Apache installed with the mod_python module activated. This usually means having a LoadModule directive in your Apache configuration file. It will look something like this:

为了�置基于 mod_python 的 Django，首先�安装有�用的 mod_python 模�的 Apache。这通常�味�应该有一个 LoadModule 指令在 Apache �置文件中。它看起�就�是这样：

LoadModule python_module /usr/lib/apache2/modules/mod_python.so

Then, edit your Apache configuration file and add the following:

然�，编辑你的Apache的�置文件，添加如下内容：

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>

Make sure to replace mysite.settings with the appropriate DJANGO_SETTINGS_MODULE for your site.

�确�把 DJANGO_SETTINGS_MODULE 中的 mysite.settings 项目��与你的站点相应的内容。

This tells Apache, Use mod_python for any URL at or under /, using the Django mod_python handler. It passes the value of DJANGO_SETTINGS_MODULE so mod_python knows which settings to use.

它告诉 Apache，任何在 / 这个路径之�的 URL 都使用 Django 的 mod_python �处�。它 将 DJANGO_SETTINGS_MODULE 的值传递过去，使得 mod_python 知�这时应该使用哪个�置。

Note that were using the <Location> directive, not the <Directory> directive. The latter is used for pointing at places on your filesystem, whereas <Location> points at places in the URL structure of a Web site. <Directory> would be meaningless here.

注�这里使用 <Location> 指令而�是 <Directory> 。�者用于指�你的文件系统中的一个�置，然而 <Location> 指�一个 Web 站点的 URL �置。

Apache likely runs as a different user than your normal login and may have a different path and sys.path. You may need to tell mod_python how to find your project and Django itself.

Apache �能�但会�行在你正常登录的环境中，也会�行在其它��的用户环境中；也�能会有��的文件路径或 sys.path。你需�告诉 mod_python 如何去寻找你的项目� Django 的�置。

PythonPath "['/path/to/project', '/path/to/django'] + sys.path"

You can also add directives such as PythonAutoReload Off for performance. See the mod_python documentation for a full list of options.

你也�以加入一些其它指令，比如 PythonAutoReload Off 以��性能。查看 mod_python 文档获得详细的指令列表。

Note that you should set PythonDebug Off on a production server. If you leave PythonDebug On , your users will see ugly (and revealing) Python tracebacks if something goes wrong within mod_python.

注�，你应该在���务器上设置 PythonDebug Off 。如果你使用 PythonDebug On 的�，在程�产生错误时，你的用户会看到难看的（并且是暴露的） Python 回溯信�。

Restart Apache, and any request to your site (or virtual host if youve put this directive inside a <VirtualHost> block) will be served by Django.

�� Apache 之�所有对你的站点的请求（或者是当你用了 <VirtualHost> 指令�则是虚拟主机）都会由 Django �处�。

Note

注�

If you deploy Django at a subdirectory that is, somewhere deeper than / Django wont trim the URL prefix off of your URLpatterns. So if your Apache config looks like this:

如果你在一个比 / �置更深的�目录中部署 Django，它 �会 对你的 URL 进行修整。所以如果你的 Apache �置是�这样的：

<Location "/mysite/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>

then all your URL patterns will need to start with "/mysite/" . For this reason we usually recommend deploying Django at the root of your domain or virtual host. Alternatively, you can simply shift your URL configuration down one level by using a shim URLconf:

则你的 所有 URL都�以 "/mysite/" 起始。基于这�原因我们通常建议将 Django，部署 在主机或虚拟主机的根目录。�外还有一个选择就是，你�以简�的将你的 URL �置转���下�这样：

urlpatterns = patterns('',
    (r'^mysite/', include('normal.root.urls')),
)

Running Multiple Django Installations on the Same Apache Instance

在�一个 Apache 的实例中�行多个 Django 程�

Its entirely possible to run multiple Django installations on the same Apache instance. You might want to do this if youre an independent Web developer with multiple clients but only a single server.

在�一个 Apache 实例中�行多个 Django 程�是完全�能的。当你是一个独立的 Web 开�人员并有多个��的客户时，你�能会想这么�。

To accomplish this, just use VirtualHost like so:

���下�这样使用 VirtualHost 你�以实现：

NameVirtualHost *

<VirtualHost *>
    ServerName www.example.com
    # ...
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</VirtualHost>

<VirtualHost *>
    ServerName www2.example.com
    # ...
    SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
</VirtualHost>

If you need to put two Django installations within the same VirtualHost , youll need to take a special precaution to ensure mod_pythons code cache doesnt mess things up. Use the PythonInterpreter directive to give different <Location> directives separate interpreters:

如果你需�在�一个 VirtualHost 中�行两个 Django 程�，你需�特别留�一下以 确� mod_python 的代�缓存�被弄得乱七八糟。使用 PythonInterpreter 指令�将� �的 <Location> 指令分别解释：

<VirtualHost *>
    ServerName www.example.com
    # ...
    <Location "/something">
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonInterpreter mysite
    </Location>

    <Location "/otherthing">
        SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
        PythonInterpreter mysite_other
    </Location>
</VirtualHost>

The values of PythonInterpreter dont really matter, as long as theyre different between the two Location blocks.

这个 PythonInterpreter 中的值���，��它们在两个 Location �中��。

Running a Development Server with mod_python

用 mod_python �行一个开��务器

Because mod_python caches loaded Python code, when deploying Django sites on mod_python youll need to restart Apache each time you make changes to your code. This can be a hassle, so heres a quick trick to avoid it: just add MaxRequestsPerChild 1 to your config file to force Apache to reload everything for each request. But dont do that on a production server, or well revoke your Django privileges.

因为 mod_python 缓存预载入了 Python 的代�，当在 mod_python 上�布 Django 站点时，你� 改动了一次代�都需��� Apache 一次。这还真是件麻烦事，所以这有个办法���它：�� 加入 MaxRequestsPerChild 1 到�置文件中强制 Apache 在�个请求时都�新载入所有的 代�。但是��在产��务器上使用这个指令，这会撤销 Django 的特�。

If youre the type of programmer who debugs using scattered print statements (we are), note that print statements have no effect in mod_python; they dont appear in the Apache log, as you might expect. If you have the need to print debugging information in a mod_python setup, youll probably want to use Pythons standard logging package. More information is available at http://docs.python.org/lib/module-logging.html. Alternatively, you can or add the debugging information to the template of your page.

如果你是一个用分散的 print 语�（我们就是这样）�调试的程�员，注�这 print 语 �在 mod_python 中是无效的；它�会�你希望的那样产生一个 Apache 日志。如果你需�在 mod_python 中打�调试信�，�能需�用到 Python 标准日志包（Pythons standard logging package）。 更多的信�请�� http://docs.python.org/lib/module-logging.html 。�一个选择是在模�页�中加入调试信�。

Serving Django and Media Files from the Same Apache Instance

使用相�的Apache实例��务Django和Media文件

Django should not be used to serve media files itself; leave that job to whichever Web server you choose. We recommend using a separate Web server (i.e., one thats not also running Django) for serving media. For more information, see the Scaling section.

Django本身�用��务media文件；应该把这项工作留给你选择的网络�务器。我们推�使用一个�独的网络�务器（�没有�行Django的一个）��务media。想了解更多信�，看下�的章节。

If, however, you have no option but to serve media files on the same Apache VirtualHost as Django, heres how you can turn off mod_python for a particular part of the site:

�过，如果你没有其他选择，所以�能在�Django一样的Apache VirtualHost 上�务media文件，这里你�以针对这个站点的特定部分关闭mod_python：

<Location "/media/">
    SetHandler None
</Location>

Change Location to the root URL of your media files.

将 Location 改�你的media文件所处的根目录。

You can also use <LocationMatch> to match a regular expression. For example, this sets up Django at the site root but explicitly disables Django for the media subdirectory and any URL that ends with .jpg , .gif , or .png :

你也�以使用 <LocationMatch> �匹�正则表达�。比如，下�的写法将Django定义到网站的根目录，并且显�地将 media �目录以�任何以 .jpg ， .gif ， 或者 .png 结尾的URL�蔽掉:

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</Location>

<Location "/media/">
    SetHandler None
</Location>

<LocationMatch "\.(jpg|gif|png)$">
    SetHandler None
</LocationMatch>

In all of these cases, youll need to set the DocumentRoot directive so Apache knows where to find your static files.

在所有这些例�中，你必须设置 DocumentRoot ，这样apache�能知�你存放��文件的�置。

Error Handling

错误处�

When you use Apache/mod_python, errors will be caught by Django in other words, they wont propagate to the Apache level and wont appear in the Apache error_log .

当你使用 Apache/mod_python 时，错误会被 Django ��，它们�会传播到 Apache 那里，也�会出现在 Apache 的 错误日志 中。

The exception to this is if something is really messed up in your Django setup. In that case, youll see an Internal Server Error page in your browser and the full Python traceback in your Apache error_log file. The error_log traceback is spread over multiple lines. (Yes, this is ugly and rather hard to read, but its how mod_python does things.)

有一个例外就是当确实你的 Django 设置混乱了时。在这�情况下，你会在�览器上看到一个 内部�务器错误的页�，并在 Apache 的 错误日志 中看到 Python 的完整回溯信�。 错误日志 的回溯信�有多行。当然，这些信�是难看且难以阅读的。

Handling a Segmentation Fault

处�段错误

Sometimes, Apache segfaults when you install Django. When this happens, its almost always one of two causes mostly unrelated to Django itself:

有时候，Apache会在你安装Django的时候�生段错误。这时，基本上 总是 有以下两个与Django本身无关的原因其中之一所造�：

• It may be that your Python code is importing the pyexpat module (used for XML parsing), which may conflict with the version embedded in Apache. For full information, see Expat Causing Apache Crash at http://www.djangoproject.com/r/articles/expat-apache-crash/.

• 有å�¯èƒ½æ˜¯å› ä¸ºï¼Œä½ ä½¿ç”¨äº† pyexpat 模å�—（进行XML解æž�）并且与Apache内置的版本相冲çª�。详情请è§� http://www.djangoproject.com/r/articles/expat-apache-crash/.

• It may be because youre running mod_python and mod_php in the same Apache instance, with MySQL as your database back-end. In some cases, this causes a known mod_python issue due to version conflicts in PHP and the Python MySQL back-end. Theres full information in a mod_python FAQ entry, accessible via http://www.djangoproject.com/r/articles/php-modpython-faq/.

• 也有å�¯èƒ½æ˜¯åœ¨å�Œä¸€ä¸ªApache进程中，å�Œæ—¶ä½¿ç”¨äº†mod_python å’Œ mod_php，而且都使用MySQL作为数æ�®åº“å�Žç«¯ã€‚在有些情况下，这会造æˆ�PHPå’ŒPythonçš„MySQL模å�—的版本冲çª�。在mod_pythonçš„FAQ中有更详细的解释。 http://www.djangoproject.com/r/articles/php-modpython-faq/.

If you continue to have problems setting up mod_python, a good thing to do is get a bare-bones mod_python site working, without the Django framework. This is an easy way to isolate mod_python-specific problems. The article Getting mod_python Working details this procedure: http://www.djangoproject.com/r/articles/getting-modpython-working/.

如果还有安装mod_python的问题，有一个好的建议，就是先��行mod_python站点，而�使用Django框架。这是区分mod_python特定问题的好方法。下�的这篇文章给出了更详细的解释。 http://www.djangoproject.com/r/articles/getting-modpython-working/.

The next step should be to edit your test code and add an import of any Django-specific code youre using your views, your models, your URLconf, your RSS configuration, and so forth. Put these imports in your test handler function and access your test URL in a browser. If this causes a crash, youve confirmed its the importing of Django code that causes the problem. Gradually reduce the set of imports until it stops crashing, so as to find the specific module that causes the problem. Drop down further into modules and look into their imports as necessary. For more help, system tools like ldconfig on Linux, otool on Mac OS, and ListDLLs (from SysInternals) on Windows can help you identify shared dependencies and possible version conflicts.

下一个步骤应该是编辑一段测试代�，把你所有django相关代�import进去，你的views,models,URLconf,RSS�置，等等。把这些imports放进你的handler函数中，然�从�览器进入你的URL。如果这些导致了crash，你就�以确定是import的django代�引起了问题。�个去掉这些imports，直到��冲�，这样就能找到引起问题的那个模�。 深入了解�模�，看看它们的imports。�想获得更多帮助，�linux的ldconfig，Mac OS的otool和windows的ListDLLs（form sysInternals）都�以帮你识别共享�赖和�能的版本冲�。

FastCGI Overview

FastCGI 简介

FastCGI is an efficient way of letting an external application serve pages to a Web server. The Web server delegates the incoming Web requests (via a socket) to FastCGI, which executes the code and passes the response back to the Web server, which, in turn, passes it back to the clients Web browser.

如何能够由一个外部的应用程�很有效解释WEB �务器上的动�页�请求呢？答案就是使用FastCGI! 它的工作步骤简�的�述起�是这样的： 1�WEB�务器收到客户端的页�请求 2�WEB�务器将这个页�请求委派给一个FastCGI 外部进程（WEB�务器于FastCGI之间是通过socket�连接通讯的） 3�FastCGI外部进程得到WEB�务器委派过�的页�请求信��进行处�，并且将处�结果（动�页�内容）返回给WEB�务器 4�Web�务器将FastCGI返回回�的结果�转�给客户端�览器。

Like mod_python, FastCGI allows code to stay in memory, allowing requests to be served with no startup time. Unlike mod_python, a FastCGI process doesnt run inside the Web server process, but in a separate, persistent process.

和mod_python一样，FastCGI也是驻留在内存里为客户请求返回动�信�,而且也�掉了�传统的CGI一样�动进程时候的时间花销。但于mod_python��之处是它并�是作为模��行在web�务器�一进程内的，而是有自己的独立进程。

Why Run Code in a Separate Process?

为什么�在一个独立的进程中�行代�？

The traditional mod_* arrangements in Apache embed various scripting languages (most notably PHP, Python/mod_python, and Perl/mod_perl) inside the process space of your Web server. Although this lowers startup time (because code doesnt have to be read off disk for every request), it comes at the cost of memory use.

在以传统的方�的几�以mod_*方�嵌入到Apache的脚本语言中（常�的例如：PHP，Python/mod_python和Perl/mod_perl），他们都是以apache扩展模�的方�将自身嵌入到Apache进程中的。尽管这�方��以�低�动时候的时间花销（因为代��用在�次收到访问请求的时候都读去硬盘数�），但这是以增大内存的开销�作为代价的。

Each Apache process gets a copy of the Apache engine, complete with all the features of Apache that Django simply doesnt take advantage of. FastCGI processes, on the other hand, only have the memory overhead of Python and Django.

�一个Apache进程都是一个Apache引擎的副本，它完全包括了所有Apache所具有的一切功能特性（哪怕是对Django毫无好处的东西也一并加载进�）。而FastCGI就�一样了，它仅仅把Python和Django等必备的东东弄到内存中。

Due to the nature of FastCGI, its also possible to have processes that run under a different user account than the Web server process. Thats a nice security benefit on shared systems, because it means you can secure your code from other users.

��FastCGI自身的特点�以看到，FastCGI进程�以与Web�务器的进程分别�行在��的用户��下。对于一个多人共用的系统�说，这个特性对于安全性是�常有好处的，因为你�以安全的于别人分享和�用代�了。

Before you can start using FastCGI with Django, youll need to install flup , a Python library for dealing with FastCGI. Some users have reported stalled pages with older flup versions, so you may want to use the latest SVN version. Get flup at http://www.djangoproject.com/r/flup/.

如果你希望你的Django以FastCGI的方��行，那么你还必须安装 flup 这个Python库，这个库就是用于处�FastCGI的。很多用户都抱怨 flup 的�布版太久了，�是�更新。其实�是的，他们一直在努力的工作�，这是没有放出�而已。但你�以通过 http://www.djangoproject.com/r/flup/ 获�他们的最新的SVN版本。

Running Your FastCGI Server

�行你的 FastCGI �务器

FastCGI operates on a client/server model, and in most cases youll be starting the FastCGI server process on your own. Your Web server (be it Apache, lighttpd, or otherwise) contacts your Django-FastCGI process only when the server needs a dynamic page to be loaded. Because the daemon is already running with the code in memory, its able to serve the response very quickly.

FastCGI是以客户机/�务器方��行的，并且在很多情况下，你得自己去�动FastCGI的�务进程。 Web�务器（例如Apache,lighttpd等等）仅仅在有动�页�访问请求的时候�会去与你的Django-FastCGI进程交互。因为Fast-CGI已�一直驻留在内存里�了的，所以它�应起�也是很快的。

Note

注�

If youre on a shared hosting system, youll probably be forced to use Web server-managed FastCGI processes. If youre in this situation, you should read the section titled Running Django on a Shared-Hosting Provider with Apache, below.

在虚拟主机上使用的�，你�能会被强制的使用Web server-managed FastCGI进程。在这样的情况下，请�阅下�的“在Apache共享主机里�行Django�这一�节。

A Web server can connect to a FastCGI server in one of two ways: it can use either a Unix domain socket (a named pipe on Win32 systems) or a TCP socket. What you choose is a manner of preference; a TCP socket is usually easier due to permissions issues.

web�务器有两�方�于FastCGI进程交互：使用Unix domain socket(在win32里�是 命�管� )或者使用TCP socket.具体使用哪一个，那就根�你的�好而定了，但是TCP socket弄�好的�往往会�生一些��上的问题。

To start your server, first change into the directory of your project (wherever your manage.py is), and then run manage.py with the runfcgi command:

开始你的�务器项目，首先进入你的项目目录下（你的 manage.py 文件所在之处），然�使用 manage.py runfcgi 命令：

./manage.py runfcgi [options]

If you specify help as the only option after runfcgi , a list of all the available options will display.

想了解如何使用 runfcgi ，输入 manage.py runfcgi help 命令。

Youll need to specify either a socket or both host and port . Then, when you set up your Web server, youll just need to point it at the socket or host/port you specified when starting the FastCGI server.

你�以指定 socket 或者�时指定 host 和 port 。当你�创建Web�务器时，你�需�将�务器指�当你在�动FastCGI�务器时确定的socket或者host/port。

A few examples should help explain this:

范例：

Running a threaded server on a TCP port:

在TCP端�上�行一个线程�务器：

./manage.py runfcgi method=threaded host=127.0.0.1 port=3033

Running a preforked server on a Unix domain socket:

在Unix socket上�行prefork�务器：

./manage.py runfcgi method=prefork socket=/home/user/mysite.sock pidfile=django.pid

Run without daemonizing (backgrounding) the process (good for debugging):

�动，但�作为��进程（在调试时比较方便）：

./manage.py runfcgi daemonize=false socket=/tmp/mysite.sock

kill `cat $PIDFILE`

#!/bin/bash

# Replace these three settings.
PROJDIR="/home/user/myproject"
PIDFILE="$PROJDIR/mysite.pid"
SOCKET="$PROJDIR/mysite.sock"

cd $PROJDIR
if [ -f $PIDFILE ]; then
    kill `cat -- $PIDFILE`
    rm -f -- $PIDFILE
fi

exec /usr/bin/env - \
  PYTHONPATH="../python:.." \
  ./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE

Using Django with Apache and FastCGI

在Apache中以FastCGI的方�使用Django

To use Django with Apache and FastCGI, youll need Apache installed and configured, with mod_fastcgi installed and enabled. Consult the Apache and mod_fastcgi documentation for instructions: http://www.djangoproject.com/r/mod_fastcgi/.

在Apache和FastCGI上使用Django，你需�安装和�置Apache，并且安装mod_fastcgi。请��Apache和mod_fastcgi文档： http://www.djangoproject.com/r/mod_fastcgi/ 。

Once youve completed the setup, point Apache at your Django FastCGI instance by editing the httpd.conf (Apache configuration) file. Youll need to do two things:

当完�了安装，通过 httpd.conf （Apache的�置文件）�让Apache和Django FastCGI互相通信。你需��两件事：

• Use the FastCGIExternalServer directive to specify the location of your FastCGI server.

• 使用 FastCGIExternalServer 指明FastCGIçš„ä½�置。

• Use mod_rewrite to point URLs at FastCGI as appropriate.

• 使用 mod_rewrite 为FastCGI指定å�ˆé€‚çš„URL。

# Connect to FastCGI via a socket/named pipe:
FastCGIExternalServer /home/user/public_html/mysite.fcgi -socket /home/user/mysite.sock

# Connect to FastCGI via a TCP host/port:
FastCGIExternalServer /home/user/public_html/mysite.fcgi -host 127.0.0.1:3033

<VirtualHost 12.34.56.78>
  ServerName example.com
  DocumentRoot /home/user/public_html
  Alias /media /home/user/python/django/contrib/admin/media
  RewriteEngine On
  RewriteRule ^/(media.*)$ /$1 [QSA,L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L]
</VirtualHost>

FastCGI and lighttpd

FastCGI 和 lighttpd

lighttpd (http://www.djangoproject.com/r/lighttpd/) is a lightweight Web server commonly used for serving static files. It supports FastCGI natively and thus is also an ideal choice for serving both static and dynamic pages, if your site doesnt have any Apache-specific needs.

lighttpd (http://www.djangoproject.com/r/lighttpd/) 是一个轻�级的Web�务器，通常被用��供��页�的访问。它天生支�FastCGI，因此除�你的站点需�一些Apache特有的特性，�则，lighttpd对于��和动�页��说都是�想的选择。

Make sure mod_fastcgi is in your modules list, somewhere after mod_rewrite and mod_access , but not after mod_accesslog . Youll probably want mod_alias as well, for serving admin media.

确� mod_fastcgi 在模�列表中，它需�出现在 mod_rewrite 和 mod_access ，但是�在 mod_accesslog 之�。你也�能需� mod_alias 模�，��供管�所用的媒体资�。

Add the following to your lighttpd config file:

将下�的内容添加到你的lighttpd的�置文件中：

server.document-root = "/home/user/public_html"
fastcgi.server = (
    "/mysite.fcgi" => (
        "main" => (
            # Use host / port instead of socket for TCP fastcgi
            # "host" => "127.0.0.1",
            # "port" => 3033,
            "socket" => "/home/user/mysite.sock",
            "check-local" => "disable",
        )
    ),
)
alias.url = (
    "/media/" => "/home/user/django/contrib/admin/media/",
)

url.rewrite-once = (
    "^(/media.*)$" => "$1",
    "^/favicon\.ico$" => "/media/favicon.ico",
    "^(/.*)$" => "/mysite.fcgi$1",
)

# If the hostname is 'www.example1.com'...
$HTTP["host"] == "www.example1.com" {
    server.document-root = "/foo/site1"
    fastcgi.server = (
       ...
    )
    ...
}

# If the hostname is 'www.example2.com'...
$HTTP["host"] == "www.example2.com" {
    server.document-root = "/foo/site2"
    fastcgi.server = (
       ...
    )
    ...
}

Running Django on a Shared-Hosting Provider with Apache

在使用Apache的共享主机�务商处�行Django

Many shared-hosting providers dont allow you to run your own server daemons or edit the httpd.conf file. In these cases, its still possible to run Django using Web server-spawned processes.

许多共享主机的�务�供商��许�行你自己的�务进程，也��许修改 httpd.conf 文件。尽管如此，�然有�能通过Web�务器产生的�进程��行Django。

Note

备注

If youre using Web server-spawned processes, as explained in this section, theres no need for you to start the FastCGI server on your own. Apache will spawn a number of processes, scaling as it needs to.

如果你�使用�务器的�进程，你没有必�自己去�动FastCGI�务器。Apache会自动产生一些�进程，产生的数�按照需求和�置会有所��。

In your Web root directory, add this to a file named .htaccess

在你的Web根目录下，将下�的内容增加到 .htaccess 文件中：

AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L]

Then, create a small script that tells Apache how to spawn your FastCGI program. Create a file, mysite.fcgi , and place it in your Web directory, and be sure to make it executable

接�，创建一个脚本，告知Apache如何�行你的FastCGI程�。创建一个 mysite.fcgi 文件，并把它放在你的Web目录中，打开�执行��。

#!/usr/bin/python
import sys, os

# Add a custom Python path.
sys.path.insert(0, "/home/user/python")

# Switch to the directory of your project. (Optional.)
# os.chdir("/home/user/myproject")

# Set the DJANGO_SETTINGS_MODULE environment variable.
os.environ['DJANGO_SETTINGS_MODULE'] = "myproject.settings"

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")

touch mysite.fcgi

Running on a Single Server

�行在一��机�务器上

Most sites start out running on a single server, with an architecture that looks something like Figure 20-1.

大多数的站点一开始都�行在�机�务器上，看起��图20-1这样的构架。

Figure 20-1: a single server Django setup.

图 20-1：一个��务器的Django安装。

This works just fine for small- to medium-sized sites, and its relatively cheap you can put together a single-server site designed for Django for well under $3,000.

这对于�型和中型的站点�说还�错，并且也很便宜，一般�说，你�以在3000美元以下就�定一切。

However, as traffic increases youll quickly run into resource contention between the different pieces of software. Database servers and Web servers love to have the entire server to themselves, so when run on the same server they often end up fighting over the same resources (RAM, CPU) that theyd prefer to monopolize.

然而，当��增加的时候，你会迅速陷入��软件的 资�争夺 之中。数�库�务器和Web�务器都 喜欢 自己拥有整个�务器资�，因此当被安装在�机上时，它们总会争夺相�的资�（RAM, CPU），它们更愿�独享资�。

This is solved easily by moving the database server to a second machine, as explained in the following section.

通过把数�库�务器�移到第二�主机上，�以很容易地解决这个问题。这将在下一部分介�。

Separating Out the Database Server

分离出数�库�务器

As far as Django is concerned, the process of separating out the database server is extremely easy: youll simply need to change the DATABASE_HOST setting to the IP or DNS name of your database server. Its probably a good idea to use the IP if at all possible, as relying on DNS for the connection between your Web server and database server isnt recommended.

对于Django�说，把数�库�务器分离开�很容易：�需�简�地修改 DATABASE_HOST ，设置为新的数�库�务器的IP地�或者DNS域�。设置为IP地�总是一个好主�，因为使用DNS域�，还�牵涉到DNS�务器的��性连接问题。

With a separate database server, our architecture now looks like Figure 20-2.

使用了一个独立的数�库�务器以�，我们的构架��了图20-2。

Figure 20-2: Moving the database onto a dedicated server.

图 20-2：将数�库移到�独的�务器上。

Here were starting to move into whats usually called n-tier architecture. Dont be scared by the buzzword it just refers to the fact that different tiers of the Web stack get separated out onto different physical machines.

这里，我们开始步入 n-tier 构架。��被这个�所��，它�是说明了Web栈的��部分，被分离到了��的物�机器上。

At this point, if you anticipate ever needing to grow beyond a single database server, its probably a good idea to start thinking about connection pooling and/or database replication. Unfortunately, theres not nearly enough space to do those topics justice in this book, so youll need to consult your databases documentation and/or community for more information.

我们��看，如果�现需��止一�的数�库�务器，考虑使用连接池和数�库备份(冗余）将是一个好主�。�幸的是，本书没有足够的时间�讨论这个问题，所以你�考数�库文档或者�社区求助。

Running a Separate Media Server

�行一个独立的媒体�务器

We still have a big problem left over from the single-server setup: the serving of media from the same box that handles dynamic content.

使用�机�务器�然留下了一个大问题：处�动�内容的媒体资�，也是在�一�机器上完�的。

Those two activities perform best under different circumstances, and by smashing them together on the same box you end up with neither performing particularly well. So the next step is to separate out the media that is, anything not generated by a Django view onto a dedicated server (see Figure 20-3).

这两个活动是在��的�件下进行的，因此把它们强行凑和在�一�机器上，你��能获得很好的性能。下一步，我们�把媒体资�（任何 �是 由Django视图产生的东西）分离到别的�务器上（请看图20-3）。

Figure 20-3: Separating out the media server.

图 20-3：分离出媒体�务器。

Ideally, this media server should run a stripped-down Web server optimized for static media delivery. lighttpd and tux (http://www.djangoproject.com/r/tux/) are both excellent choices here, but a heavily stripped down Apache could work, too.

�想的情况是，这个媒体�务器是一个定制的Web�务器，为传���媒体资��了优化。lighttpd和tux (http://www.djangoproject.com/r/tux/) 都是�佳的选择，当然瘦身的Apache�务器也�以工作的很好。

For sites heavy in static content (photos, videos, etc.), moving to a separate media server is doubly important and should likely be the first step in scaling up.

对于拥有大���内容（照片�视频等）的站点�说，将媒体�务器分离出去显然有�更加��的�义，而且应该是扩大规模的时候所�采�的 第一步措施 。

This step can be slightly tricky, however. Djangos admin needs to be able to write uploaded media to the media server (the MEDIA_ROOT setting controls where this media is written). If media lives on another server, however, youll need to arrange a way for that write to happen across the network.

这一步需�一点点技巧，Django的admin管�接�需�能够获得足够的���处�上传的媒体（通过设置 MEDIA_ROOT ）。如果媒体资�在�外的一��务器上，你需�获得通过网络写�作的��。

The easiest way to do this is to use NFS to mount the media servers media directories onto the Web server(s). If you mount them in the same location pointed to by MEDIA_ROOT , media uploading will Just Work.

最简�的方案是使用NFS（网络文件系统）把媒体�务器的目录挂载到Web�务器上�。�� MEDIA_ROOT 设置正确，媒体的上传就�以正常工作。

Implementing Load Balancing and Redundancy

实现负担�衡和数�冗余备份

At this point, weve broken things down as much as possible. This three-server setup should handle a very large amount of traffic we served around 10 million hits a day from an architecture of this sort so if you grow further, youll need to start adding redundancy.

现在，我们已�尽�能地进行了分解。这�三��务器的构架�以承�很大的��，比如�天1000万的点击率。如果还需�进一步地增加，你就需�开始增加冗余备份了。

This is a good thing, actually. One glance at Figure 20-3 shows you that if even a single one of your three servers fails, youll bring down your entire site. So as you add redundant servers, not only do you increase capacity, but you also increase reliability.

这是个好主�。请看图 20-3，一旦三个�务器中的任何一个�生了故障，你就得关闭整个站点。因此在引入冗余备份的时候，你并��是增加了容�，�时也增加了��性。

For the sake of this example, lets assume that the Web server hits capacity first. Its easy to get multiple copies of a Django site running on different hardware just copy all the code onto multiple machines, and start Apache on both of them.

我们首先�考虑Web�务器的点击�。把�一个Django的站点�制多份，在多�机器上�时�行很容易，我们也�需��时�行多�机器上的Apache�务器。

However, youll need another piece of software to distribute traffic over your multiple servers: a load balancer . You can buy expensive and proprietary hardware load balancers, but there are a few high-quality open source software load balancers out there.

你还需��一个软件�帮助你在多��务器之间�衡网络��： ���衡器（load balancer） 。你�以购买昂贵的专有的硬件�衡器，当然也有一些高质�的开�的软件�衡器�供选择。

Apaches mod_proxy is one option, but weve found Perlbal (http://www.djangoproject.com/r/perlbal/) to be simply fantastic. Its a load balancer and reverse proxy written by the same folks who wrote memcached (see Chapter 13).

Apaches 的 mod_proxy 是一个�以考虑的选择，但�一个�置更棒的选择是：Perlbal (http://www.djangoproject.com/r/perlbal/) 。Perlbal是一个�衡器，�时也是一个��代�，它的开�者和memcached的开�者是�一拨人（请�13章）。

Note

备注

If youre using FastCGI, you can accomplish this same distribution/load balancing step by separating your front-end Web servers and back-end FastCGI processes onto different machines. The front-end server essentially becomes the load balancer, and the back-end FastCGI processes replace the Apache/mod_python/Django servers.

如果你使用FastCGI，你�样�以分离��的web�务器，并在多�其他机器上�行FastCGI�务器�实现相�的负载�衡的功能。��的�务器就相当于是一个�衡器，而��的FastCGI�务进程代替了Apache/mod_python/Django�务器。

With the Web servers now clustered, our evolving architecture starts to look more complex, as shown in Figure 20-4.

现在我们拥有了�务器集群，我们的构架慢慢演化，越�越��，如图20-4。

Figure 20-4: A load-balanced, redundant server setup.

图 20-4：负载�衡的�务器设置。

Notice that in the diagram the Web servers are referred to as a cluster to indicate that the number of servers is basically variable. Once you have a load balancer out front, you can easily add and remove back-end Web servers without a second of downtime.

值得一�的是，在图中，Web�务器指的是一个集群，�表示许多数�的�务器。一旦你拥有了一个��的�衡器，你就�以很方便地增加和删除��的Web�务器，而且�会造�任何网站��用的时间。

Going Big

慢慢�大

At this point, the next few steps are pretty much derivatives of the last one:

下�的这些步骤都是上�最�一个的�体：

• As you need more database performance, youll need to add replicated database servers. MySQL includes built-in replication; PostgreSQL users should look into Slony (http://www.djangoproject.com/r/slony/) and pgpool (http://www.djangoproject.com/r/pgpool/) for replication and connection pooling, respectively.

• 当你需è¦�更好的数æ�®åº“性能，你å�¯èƒ½éœ€è¦�增加数æ�®åº“的冗余æœ�务器。MySQL内置了备份功能；PostgreSQL应该看一下Slony (http://www.djangoproject.com/r/slony/) å’Œ pgpool (http://www.djangoproject.com/r/pgpool/) ，这两个分别是数æ�®åº“备份和连接池的工具。

• If the single load balancer isnt enough, you can add more load balancer machines out front and distribute among them using round-robin DNS.

• 如果å�•ä¸ªå�‡è¡¡å™¨ä¸�能达到è¦�求，你å�¯ä»¥å¢žåŠ æ›´å¤šçš„å�‡è¡¡å™¨ï¼Œå¹¶ä¸”使用轮训（round-robin）DNSæ�¥å®žçŽ°åˆ†å¸ƒè®¿é—®ã€‚

• If a single media server doesnt suffice, you can add more media servers and distribute the load with your load-balancing cluster.

• 如果å�•å�°åª’体æœ�务器ä¸�够用，你å�¯ä»¥å¢žåŠ æ›´å¤šçš„媒体æœ�务器，并通过集群æ�¥åˆ†å¸ƒæµ�é‡�。

• If you need more cache storage, you can add dedicated cache servers.

• 如果你需è¦�更多的高速缓存（cache），你å�¯ä»¥å¢žåŠ cacheæœ�务器。

• At any stage, if a cluster isnt performing well, you can add more servers to the cluster.

• 在任何情况下，å�ªè¦�集群工作性能ä¸�好，你都å�¯ä»¥å¾€ä¸Šå¢žåŠ æœ�务器。

After a few of these iterations, a large-scale architecture might look like Figure 20-5.

��了几次以�，一个大规模的构架会�图20-5。

Figure 20-5. An example large-scale Django setup.

图 20-5。大规模的Django安装。

Though weve shown only two or three servers at each level, theres no fundamental limit to how many you can add.

尽管我们�是在�一层上展示了两到三��务器，你�以在上���地增加更多。

Once you get up to this level, youve got quite a few options. Appendix A has some information from a few developers responsible for some large-scale Django installations. If youre planning a high-traffic Django site, its worth a read.

当你到了这一个阶段，你有一些选择。附录A有一些开�者关于大型系统的信�。如果你想�构建一个高��的Django站点，那值得一读。

Theres No Such Thing As Too Much RAM

RAM怎么也�嫌多

As of this writing, the really expensive RAM costs only about $200 per gigabyte pennies compared to the time spent tuning elsewhere. Buy as much RAM as you can possibly afford, and then buy a little bit more.

写这篇文章的时候，RAM的价格已��到了�G大约200美元。购买尽�能多的RAM，�在别的上�投资一点点。

Faster processors wont improve performance all that much; most Web servers spend up to 90% of their time waiting on disk I/O. As soon as you start swapping, performance will just die. Faster disks might help slightly, but theyre much more expensive than RAM, such that it doesnt really matter.

高速的处�器并�会大幅度地�高性能；大多数的Web�务器90%的时间都浪费在了硬盘IO上。当硬盘上的数�开始交�，性能就急剧下�。更快速的硬盘�以改善这个问题，但是比起RAM�说，那太贵了。

If you have multiple servers, the first place to put your RAM is in the database server. If you can afford it, get enough RAM to get fit your entire database into memory. This shouldnt be too hard. LJWorld.coms database including over half a million newspaper articles dating back to 1989 is under 2GB.

如果你拥有多��务器，首�的是�在数�库�务器上增加内存。如果你能负担得起，把你整个数�库都放入到内存中。这�会很难。LJWorld.com等网站的数�库�存了大�从1989年起至今的报纸和文章，内存的消耗也�到2G。

Next, max out the RAM on your Web server. The ideal situation is one where neither server swaps ever. If you get to that point, you should be able to withstand most normal traffic.

下一步，最大化Web�务器上的内存。最�想的情况是，没有一��务器进行�盘交�。如果你达到了这个水平，你就能应付大多数正常的��。

Turn Off Keep-Alive

�用 Keep-Alive

Keep-Alive is a feature of HTTP that allows multiple HTTP requests to be served over a single TCP connection, avoiding the TCP setup/teardown overhead.

Keep-Alive 是HTTP�供的功能之一，它的目的是�许多个HTTP请求�用一个TCP连接，也就是�许在�一个TCP连接上�起多个HTTP请求，这样有效的��了�个HTTP请求都�新建立自己的TCP连接的开销。

This looks good at first glance, but it can kill the performance of a Django site. If youre properly serving media from a separate server, each user browsing your site will only request a page from your Django server every ten seconds or so. This leaves HTTP servers waiting around for the next keep-alive request, and an idle HTTP server just consumes RAM that an active one should be using.

这一眼看上去是好事，但它足以�死Django站点的性能。如果你从�独的媒体�务器上�用户�供�务，�个光顾你站点的用户都大约10秒钟左��出一次请求。这就使得HTTP�务器一直在等待下一次keep-alive 的请求，空闲的HTTP�务器和工作时消耗一样多的内存。

Use memcached

使用 memcached

Although Django supports a number of different cache back-ends, none of them even come close to being as fast as memcached. If you have a high-traffic site, dont even bother with the other back-ends go straight to memcached.

尽管Django支�多���的cache��机制，没有一�的性能�以 接近 memcached。如果你有一个高��的站点，��犹豫，直接选择memcached。

Use memcached Often

�常使用memcached

Of course, selecting memcached does you no good if you dont actually use it. Chapter 13 is your best friend here: learn how to use Djangos cache framework, and use it everywhere possible. Aggressive, preemptive caching is usually the only thing that will keep a site up under major traffic.

当然，选择了memcached而�去使用它，你�会从中获得任何性能上的��。第13章将为你�供有用的信�：学习如何使用Django的cache框架，并且尽�能地使用它。大�的�抢��的高速缓存通常是一个站点在大��下正常工作的唯一瓶颈。

Join the Conversation

�加讨论

Each piece of the Django stack from Linux to Apache to PostgreSQL or MySQL has an awesome community behind it. If you really want to get that last 1% out of your servers, join the open source communities behind your software and ask for help. Most free-software community members will be happy to help.

Django相关的�一个部分，从Linux到Apache到PostgreSQL或者MySQL背�，都有一个�常棒的社区支�。如果你真想从你的�务器上榨干最�1%的性能，加入开�社区寻求帮助。多数的自由软件社区�员都会很��地�供帮助。

And also be sure to join the Django community. Your humble authors are only two members of an incredibly active, growing group of Django developers. Our community has a huge amount of collective experience to offer.

别忘了Django社区。这本书谦逊的作者�是Django开�团队中的两��员。我们的社区有大�的�验�以�供。