Django Book 翻译

Chapter 20: Deploying Django
----------------------------

第二十章：部署Django
------------------------------

Throughout this book, weve mentioned a number of goals that drive the development of
Django. Ease of use, friendliness to new programmers, abstraction of repetitive tasks
these all drive Djangos developers.

在这本书中，我们提到了驱使Django发展的很多目标。易用，对初学者友好，重复任务的抽象，
这些都驱使着Django继续发展。

However, since Djangos inception, theres always been another important goal: Django
should be easy to deploy, and it should make serving large amounts of traffic possible
with limited resources.

然而，从Django一开始，就有另一个重要的目标：Django应该容易被部署，并且它应该能够用
有限的资源提供大量的服务。

The motivations for this goal are apparent when you look at Djangos background: a
small, family-owned newspaper in Kansas can hardly afford top-of-the-line server
hardware, so Djangos original developers were concerned with squeezing the best
possible performance out of limited resources. Indeed, for years Djangos developers
acted as their own system administrators there simply wasnt enough hardware to *need*
dedicated sysadmins even as their sites handled tens of millions of hits a day.

这样的动机是很明显的，当你看到 Django 的背景：堪萨斯州一个小巧的、家族式报纸企业
负担不起高品质的服务器硬件，所以 Django 的最初开发者们都非常的关心如何才能从有限
的资源中挤压出最好的性能。确实，这些年来 Django 的开发者们充当了他们自己的系统管
理员。虽然他们的站点每天处理上千万的点击量，但他们确实没有那么多数量的硬件以至于*需要*专门的系统管理员。

As Django became an open source project, this focus on performance and ease of
deployment became important for a different reason: hobbyist developers have the same
requirements. Individuals who want to use Django are pleased to learn they can host a
small- to medium-traffic site for as little as $10 a month.

当 Django 成为一个开源项目后，关注在其性能和开发的简易性因为某些原因变得特别重要：
业余爱好者也有同样的需求。有一些人想要花费仅仅 10 美元并使用 Django 来体验制作一个
中小规模流量的站点。

But being able to scale down is only half the battle. Django also needs to be capable
of scaling *up* to meet the needs of large companies and corporations. Here, Django
adopts a philosophy common among LAMP-like Web stacks often called *shared nothing* .

但是小规模的应用只是目标的一半而已。Django 也需要能够增加其规模来满足大型公司和集团
的需求。这里，Django 采取了类似于 LAMP 形式的 Web 集的哲学理论，通常称为 *无共享(shared nothing)* 。

Whats LAMP?

什么是 LAMP？

The acronym LAMP was originally coined to describe a popular set of open source
software used to drive many Web sites:

LAMP 这个缩写最初是创造它来描述一系列驱动 Web 站点的流行的开源软件：

*   Linux (operating system)

*   Linux（操作系统）

*   Apache (Web server)

*   Apache（Web 服务器）

*   MySQL (database)

*   MySQL（数据库）

*   PHP (programming language)

*   PHP（编程语言）

Over time, though, the acronym has come to refer more to the philosophy of these types
of open source software stacks than to any one particular stack. So while Django uses
Python and is database-agnostic, the philosophies proven by the LAMP stack permeate
Djangos deployment mentality.

随着时间的推移，这个缩写已经变得涉及了更多开源软件栈的哲学思想，而不仅仅再是局限于特定的某一种了。所以当 Django 使用 Python 并可以使用多种数据库产品时，LAMP 软件栈证实的一些理论就渗透到 Django 中了。

There have been a few (mostly humorous) attempts at coining a similar acronym to
describe Djangos technology stack. The authors of this book are fond of LAPD (Linux,
Apache, PostgreSQL, and Django) or PAID (PostgreSQL, Apache, Internet, and Django). Use
Django and get PAID!

这里尝试建立一个类似的缩写来描述 Django 的技术栈。本书的作者喜欢用 LAPD（Linux,
Apache, PostgreSQL, and Django）或PAID（PostgreSQL, Apache, Internet, and Django）。
使用 Django 并采用 PAID 吧！

Shared Nothing
``````````````

无共享
``````````````

At its core, the philosophy of shared nothing is really just the application of loose
coupling to the entire software stack. This architecture arose in direct response to
what was at the time the prevailing architecture: a monolithic Web application server
that encapsulates the language, database, and Web server even parts of the operating
system into a single process (e.g., Java).

无共享哲学的核心实际上就是应用程序在整个软件栈上的松耦合思想。这个架构的产生直接响应了当时的主流架构背景：将web应用服务器作为不可分的整体，它将语言、数据库、web服务器甚至操作系统的一部分封装到单个进程中(如java)。

When it comes time to scale, this can be a major problem; its nearly impossible to
split the work of a monolithic process across many different physical machines, so
monolithic applications require enormously powerful servers. These servers, of course,
cost tens or even hundreds of thousands of dollars, putting large-scale Web sites out
of the reach of cash-hungry individuals and small companies.

当需要伸缩性时，就会碰到下面这个主要问题：几乎不可能把混为一体的进程所干的事情分解到许多不同的物理机器上，因此这类应用就必须要有极为强大的服务器来支撑。这些服务器，需要花费数万甚至数十万美金，从而使这类大规模Web网站远离了财政不宽裕的个人和小公司。

What the LAMP community noticed, however, was that if you broke each piece of the Web
stack up into individual components, you could easily start with an inexpensive server
and simply add more inexpensive servers as you grew. If your $3,000 database server
couldnt handle the load, youd simply buy a second (or third, or fourth) until it could.
If you needed more storage capacity, youd add an NFS server.

LAMP社区注意到，如果将Web栈分解为多个独立的组件，人们就能从容的从廉价的服务器开始自己的事业，而在发展壮大时只需要添加更多的廉价服务器。如果3000美元的数据库服务器不足以处理负载，只需要简单的购买第二个(或第三、第四个)直到足够。如果需要更多的存储空间，只需增加新的NFS服务器。

For this to work, though, Web applications had to stop assuming that the same server
would handle each request or even each part of a single request. In a large-scale LAMP
(and Django) deployment, as many as half a dozen servers might be involved in handling
a single page! The repercussions of this are numerous, but they boil down to these
points:

但是，为了使这个成为可能，Web应用必须不再假设由同一个服务器处理所有的请求，甚至处理单个请求的所有部分。在大规模LAMP(以及Django)的部署环境中，处理一个页面甚至会涉及到多达半打的服务器！这一条件会对各方面产生诸多影响，但可以归结到以下几点：

*   *State cannot be saved locally* . In other words, any data that must be available
    between multiple requests must be stored in some sort of persistent storage like
    the database or a centralized cache.

*   *不能在本地保存状态* 。也就是说，任何需要在多个请求间共享的数据都必须保存在某种形式的持久性存储(如数据库)或集中化缓存中。

*   *Software cannot assume that resources are local* . For example, the Web platform
    cannot assume that the database runs on the same server; it must be capable of
    connecting to a remote database server.

*   *软件不能假设资源是本地的* 。例如，Web平台不能假设数据库运行于同一个服务器上；因此，它必须能够连接到远程数据库服务器。

*   *Each piece of the stack must be easily moved or replicated* . If Apache for some
    reason doesnt work for a given deployment, you should be able to swap it out for
    another server with a minimum of fuss. Or, on a hardware level, if a Web server
    fails, you should be able to replace it with another physical box with minimum
    downtime. Remember, this whole philosophy is based around deployment on cheap,
    commodity hardware. Failure of individual machines is to be expected.

*   *Web栈中的每个部分都必须易于移动或复制* 。如果在部署时因为某种原因Apache不能工作，必须能够在最小的代价下切换到其它服务器。或者，在硬件层次，如果Web服务器崩溃，必须能够在最小的宕机时间内替换到另一台机器。请记住，整个哲学基于将应用部署在廉价的、商品化的硬件上。因此，本就应当预见到单个机器的失效。

As youve probably come to expect, Django handles this more or less transparently no
part of Django violates these principles but knowing the philosophy helps when it comes
time to scale up.

就所期望的那样，Django或多或少透明的处理好了这件事情，没有一个部分违反这些原则。但是，了解架构设计背后的哲学，在我们处理伸缩性时将会有所裨益。

But Does It Work?

但这果真解决问题？

This philosophy might sound good on paper (or on your screen), but does it actually
work?

这一哲学可能在理论上(或者在屏幕上)看起来不错，但是否真的能解决问题？

Well, instead of answering directly, lets instead look at a by-no-means-complete list
of a few companies that have based their business on this architecture. You might
recognize some of these names:

好了，我们不直接回答这个问题，先请看一下将业务建立在上述架构上的公司的不完全列表。大家可能已经熟悉其中的一些名字：

*   Amazon

*   Amazon

*   Blogger

*   Blogger

*   Craigslist

*   Craigslist

*   Facebook

*   Facebook

*   Google

*   Google

*   LiveJournal

*   LiveJournal

*   Slashdot

*   Slashdot

*   Wikipedia

*   Wikipedia

*   Yahoo

*   Yahoo

*   YouTube

*   YouTube

To paraphrase the famous scene from *When Harry Met Sally* : Well have what theyre
having!

请允许我用 *当哈利遇见沙莉* 中的著名场景来比喻：他们有的我们也会有！

A Note on Personal Preferences
``````````````````````````````

关于个人偏好的备注
``````````````````

Before we get into the details, a quick aside.

在进入细节之前，短暂跑题一下。

Open source is famous for its so-called religious wars; much (digital) ink has been
spilled arguing over text editors (``emacs`` vs. ``vi`` ), operating systems (Linux vs.
Windows vs. Mac OS), database engines (MySQL vs. PostgreSQL), and of course programming
languages.

开源运动因其所谓的宗教战争而闻名；许多墨水(以及墨盒、硒鼓等)被挥洒在各类争论上：文本编辑器(``emacs`` vs. ``vi`` ),操作系统(Linux vs.Windows vs. Mac OS),数据库引擎(MySQL vs. PostgreSQL), 当然还包括编程语言。

We try to stay away from these battles. There just isnt enough time.

我们希望远离这些战争。仅仅因为没有足够的时间。

However, there are a number of choices when it comes to deploying Django, and were
constantly asked for our preferences. Since stating these preferences comes dangerously
close to firing a salvo in one of the aforementioned battles, weve mostly refrained.
However, for the sake of completeness and full disclosure, well state them here. We
prefer the following:

但是，在部署Django确实有很多选择，而且我们也经常被问及个人偏好。表述这些会使社区处于引发上类战争的危险边缘，所以我们在一直以来非常克制。但是，出于完整性和全无保留的目的，我们将在这里表述自己的偏好。以下是我们的优先选择：

*   Linux (Ubuntu, specifically) as our operating system

*   操作系统: Linux(具体而言是Ubuntu)

*   Apache and mod_python for the Web server

*   Web服务器: Apache和mod_python

*   PostgreSQL as a database server

*   数据库服务器：PostgreSQL

Of course, we can point to many Django users who have made other choices with great
success.

当然，我们也看到，许多做了不同选择的Django用户同样也大获成功。

Using Django with Apache and mod_python
```````````````````````````````````````

用Apache和mod_python来部署Django
````````````````````````````````

Apache with mod_python currently is the most robust setup for using Django on a
production server.

目前，Apache和mod_python是在生产服务器上部署Django的最健壮搭配。

mod_python (`http://www.djangoproject.com/r/mod_python/`_) is an Apache plug-in that
embeds Python within Apache and loads Python code into memory when the server starts.
Code stays in memory throughout the life of an Apache process, which leads to
significant performance gains over other server arrangements.

mod_python (`http://www.djangoproject.com/r/mod_python/`_)是一个在Apache中嵌入Python的Apache插件，它在服务器启动时将Python代码加载到内存中。(译注：这里的内存是指虚拟内存)
代码在Apache进程的整个生命周期中都驻留在内存中，与其它服务器的做法相比，这将带来重要的性能提升。

Django requires Apache 2.x and mod_python 3.x, and we prefer Apaches prefork MPM, as
opposed to the worker MPM.

Django要求Apache2.x和mod_python3.x，并且我们优先考虑Apache的prefork MPM模式，而不是worker MPM。

Note

备注

Configuring Apache is *well* beyond the scope of this book, so well simply mention
details as needed. Luckily, a number of great resources are available if you need to
learn more about Apache. A few of them we like are as follows:

如何配置Apache超出了本书的范围，因此下面将只简单介绍必要的细节。幸运的是，如果需要进一步学习Apache的相关知识，可以找到相当多的绝佳资源。下面是我们所中意的部分资料：

*   The free online Apache documentation, available via
    `http://www.djangoproject.com/r/apache/docs/`_

*   开源的Apache在线文档，位于 `http://www.djangoproject.com/r/apache/docs/`_

*   *Pro Apache, Third Edition* (Apress, 2004) by Peter Wainwright, available via
    `http://www.djangoproject.com/r/books/pro-apache/`_

*   *Pro Apache，第三版* (Apress, 2004),作者Peter Wainwright, 位于 `http://www.djangoproject.com/r/books/pro-apache/`_

*   *Apache: The Definitive Guide, Third Edition* (OReilly, 2002) by Ben Laurie and
    Peter Laurie, available via `http://www.djangoproject.com/r/books/apache-pra/`_

*   *Apache: The Definitive Guide, 第三版* (OReilly, 2002),作者Ben Laurie和Peter Laurie, 位于 `http://www.djangoproject.com/r/books/apache-pra/`_

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 配置文件中。它看起来就像是这样：

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

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

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 的位置。

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 配置是像这样的：

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 配置转换成像下面这样：

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`` 你可以实现：

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>`` 指令分别解释：

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：

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屏蔽掉:

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）都可以帮你识别共享依赖和可能的版本冲突。

Using Django with FastCGI
`````````````````````````

使用FastCGI部署Django应用
`````````````````````````

Although Django under Apache and mod_python is the most robust deployment setup, many
people use shared hosting, on which FastCGI is the only available deployment option.

尽管将使用Apache和mod_python搭建Django环境是最具鲁棒性的，但在很多虚拟主机平台上，往往只能使用FastCGI

Additionally, in some situations, FastCGI allows better security and possibly better
performance than mod_python. For small sites, FastCGI can also be more lightweight than
Apache.

此外，在很多情况下，FastCGI能够提供比mod_python更为优越的安全性和效能。针对小型站点，相对于Apache来说FastCGI更为轻量级。

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`` 命令：

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端口上运行一个线程服务器：

    Running a preforked server on a Unix domain socket:

    在Unix socket上运行prefork服务器：

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

    启动，但不作为后台进程（在调试时比较方便）：

Stopping the FastCGI Daemon
...........................

停止FastCGI的行程
...........................

If you have the process running in the foreground, its easy enough to stop it: simply
press Ctrl+C to stop and quit the FastCGI server. However, when youre dealing with
background processes, youll need to resort to the Unix ``kill`` command.

如果你的FastCGI是在前台运行的，那么只需按Ctrl+C就可以很方便的停止这个进程了。但如果是在后台运行的话，你就要使用Unix的 ``kill`` 命令来杀掉它。

If you specify the ``pidfile`` option to your ``manage.py runfcgi`` , you can kill the
running FastCGI daemon like this:

如果你在 ``manage.py runfcgi`` 中指定了 ``pidfile`` 这个选项，那么你可以这样来杀死这个FastCGI后台进程：

where ``$PIDFILE`` is the ``pidfile`` you specified.

``$PIDFILE`` 就是你在 ``pidfile`` 指定的那个。

To easily restart your FastCGI daemon on Unix, you can use this small shell script:

你可以使用下面这个脚本方便地重启Unix里的FastCGI守护进程：

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。

Specifying the Location of the FastCGI Server
.............................................

指定 FastCGI Server 的位置
.............................................

The ``FastCGIExternalServer`` directive tells Apache how to find your FastCGI server.
As the FastCGIExternalServer docs
(`http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/`_) explain, you can
specify either a ``socket`` or a ``host`` . Here are examples of both:

``FastCGIExternalServer`` 告诉Apache如何找到FastCGI服务器。 按照FastCGIExternalServer 文档（ `http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/`_ ），你可以指明 ``socket`` 或者 ``host`` 。以下是两个例子：

In either case, the the directory /home/user/public_html/ should exist, though the file
``/home/user/public_html/mysite.fcgi`` doesnt actually have to exist. Its just a URL
used by the Web server internally a hook for signifying which requests at a URL should
be handled by FastCGI. (More on this in the next section.)

在这两个例子中， /home/user/public_html/ 目录必须存在，而 ``/home/user/public_html/mysite.fcgi`` 文件不一定存在。它仅仅是一个Web服务器内部使用的接口，这个URL决定了对于哪些URL的请求会被FastCGI处理（下一部分详细讨论）。

Using mod_rewrite to Point URLs at FastCGI
..........................................

使用mod_rewrite为FastCGI指定URL
..........................................

The second step is telling Apache to use FastCGI for URLs that match a certain pattern.
To do this, use the mod_rewrite module and rewrite URLs to ``mysite.fcgi`` (or whatever
you specified in the ``FastCGIExternalServer`` directive, as explained in the previous
section).

第二步是告诉Apache为符合一定模式的URL使用FastCGI。为了实现这一点，请使用mod_rewrite 模块，并将这些URL重定向到 ``mysite.fcgi`` （或者正如在前文中描述的那样，使用任何在 ``FastCGIExternalServer`` 指定的内容）。

In this example, we tell Apache to use FastCGI to handle any request that doesnt
represent a file on the filesystem and doesnt start with ``/media/`` . This is probably
the most common case, if youre using Djangos admin site:

在这个例子里面，我们告诉Apache使用FastCGI来处理那些在文件系统上不提供文件(译者注：也就是指向虚拟文件)和没有从 ``/media/`` 开始的任何请求。如果你使用Django的admin站点，下面可能是一个最普通的例子：

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的配置文件中：

Running Multiple Django Sites on One lighttpd Instance
......................................................

在一个lighttpd进程中运行多个Django站点
......................................................

lighttpd lets you use conditional configuration to allow configuration to be customized
per host. To specify multiple FastCGI sites, just add a conditional block around your
FastCGI config for each site:

lighttpd允许你使用条件配置来为每个站点分别提供设置。为了支持FastCGI的多站点，只需要在FastCGI的配置文件中，为每个站点分别建立条件配置项：

You can also run multiple Django installations on the same site simply by specifying
multiple entries in the ``fastcgi.server`` directive. Add one FastCGI host for each.

你也可以通过 ``fastcgi.server`` 中指定多个入口，在同一个站点上实现多个Django安装。请为每一个安装指定一个FastCGI主机。

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`` 文件中：

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目录中，打开可执行权限。

Restarting the Spawned Server
.............................

重启新产生的进程服务器
.............................

If you change any Python code on your site, youll need to tell FastCGI the code has
changed. But theres no need to restart Apache in this case. Rather, just reupload
``mysite.fcgi`` or edit the file so that the timestamp on the file changes. When Apache
sees the file has been updated, it will restart your Django application for you.

如果你改变了站点上任何的python代码，你需要告知FastCGI。但是，这不需要重启Apache，而只需要重新上传 ``mysite.fcgi`` 或者编辑改文件，使得修改时间发生了变化，它会自动帮你重启Django应用。

If you have access to a command shell on a Unix system, you can accomplish this easily
by using the ``touch`` command:

如果你拥有Unix系统命令行的可执行权限，只需要简单地使用 ``touch`` 命令：

Scaling
```````

可扩展性
``````````````

Now that you know how to get Django running on a single server, lets look at how you
can scale out a Django installation. This section walks through how a site might scale
from a single server to a large-scale cluster that could serve millions of hits an
hour.

既然你已经知道如何在一台服务器上运行Django，让我们来研究一下，如何扩展我们的Django安装。这一部分我们将讨论，如何把一台服务器扩展为一个大规模的服务器集群，这样就能满足每小时上百万的点击率。

Its important to note, however, that nearly every large site is large in different
ways, so scaling is anything but a one-size-fits-all operation. The following coverage
should suffice to show the general principle, and whenever possible well try to point
out where different choices could be made.

有一点很重要，每一个大型的站点大的形式和规模不同，因此可扩展性其实并不是一种千篇一律的行为。以下部分会涉及到一些通用的原则，并且会指出一些不同选择。

First off, well make a pretty big assumption and exclusively talk about scaling under
Apache and mod_python. Though we know of a number of successful medium- to large-scale
FastCGI deployments, were much more familiar with Apache.

首先，我们来做一个大的假设，只集中地讨论在Apache和mod_python下的可扩展性问题。尽管我们也知道一些成功的中型和大型的FastCGI策略，但是我们更加熟悉Apache。

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这样的构架。

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png

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。

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png

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）。

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png

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。

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-4.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-4.png

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-4.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-4.png

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。

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-5.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-5.png

.. image:: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-5.png
    :alt: http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-5.png

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站点，那值得一读。

Performance Tuning
``````````````````

性能优化
``````````````````

If you have huge amount of money, you can just keep throwing hardware at scaling
problems. For the rest of us, though, performance tuning is a must.

如果你有大笔大笔的钱，遇到扩展性问题时，你可以简单地投资硬件。对于剩下的人来说，性能优化就是必须要做的一件事。

Note

备注

Incidentally, if anyone with monstrous gobs of cash is actually reading this book,
please consider a substantial donation to the Django project. We accept uncut diamonds
and gold ingots, too.

顺便提一句，谁要是有大笔大笔的钞票，请捐助一点Django项目。我们也接受未切割的钻石和金币。

Unfortunately, performance tuning is much more of an art than a science, and it is even
more difficult to write about than scaling. If youre serious about deploying a
large-scale Django application, you should spend a great deal of time learning how to
tune each piece of your stack.

不幸的是，性能优化比起科学来说更像是一种艺术，并且这比扩展性更难描述。如果你真想要构建一个大规模的Django应用，你需要花大量的时间和精力学习如何优化构架中的每一部分。

The following sections, though, present a few Django-specific tuning tips weve
discovered over the years.

以下部分总结了多年以来的经验，是一些专属于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开发团队中的两位成员。我们的社区有大量的经验可以提供。

Whats Next?
```````````

下一步？
```````````

Youve reached the end of our regularly scheduled program. The following appendixes all
contain reference material that you might need as you work on your Django projects.

你已经看到了正文的结束部分了。下面的这些附录都包含了许多参考资料，当你构建你的Django项目时，有可能会用到。

We wish you the best of luck in running your Django site, whether its a little toy for
you and a few friends, or the next Google.

我们希望你的Django站点运行良好，无论你的站点是你和你朋友之间的一个小玩具，还是下一个Google。