| ID | English原文 | 中文翻译 | 最近翻译记录 | 状态 | 操作 |
|---|---|---|---|---|---|
| 0#翻译 | Chapter 12: | 第十二章： | 翻译 | ||
| 1#翻译 | Deploying Django | 部署Django | 翻译 | ||
| 4#翻译 | This chapter covers the last essential step of building a Django application: | 本章包含创建Django程序的最后一个必不可少的步骤： | 翻译 | ||
| 5#翻译 | deploying it to a production server. | 在生产服务器上部署它。 | 翻译 | ||
| 7#翻译 | If you've been following along with our ongoing examples, you've likely been using the <literal>runserver</literal> , which makes things very easy with <literal>runserver</literal> , you don't have to worry about Web server setup. | 如果你一直跟着我们的例子做，你可能正在用<literal>runserver</literal>。使用这个命令确实很简单，你不必担心服务器的安装。 | 翻译 | ||
| 8#翻译 | But <literal>runserver</literal> is intended only for development on your local machine, not for exposure on the public Web. | 但是<literal>runserver</literal>只是用来协助你进行本地开发的，并不适合发布到公网。 | 翻译 | ||
| 9#翻译 | To deploy your Django application, you'll need to hook it into an industrial-strength Web server such as Apache. | 要部署你的Django应用，你需要把它挂接到工业强度的服务器上，如：Apache。 | 翻译 | ||
| 10#翻译 | In this chapter, we'll show you how to do that but, first, we'll give you a checklist of things to do in your codebase before you go live. | 在本章，我们将展示如何部署，但我们首先要给你一个(要做的事的)清单.。 | 翻译 | ||
| 12#翻译 | Preparing Your Codebase for Production | 准备你的代码库 | 翻译 | ||
| 14#翻译 | Fortunately, the <literal>runserver</literal> approximates a real Web server closely enough that not very many changes need to be made to a Django application in order to make it production-ready. | 很幸运，<literal>runserver</literal>非常接近于真实的Web服务器，所以我们不需要对Django应用做太多改动。 | 翻译 | ||
| 15#翻译 | But there are a few <emphasis>essential things</emphasis> you should do before you turn the switch. | 但是，有一些<emphasis>必要的事情</emphasis>需要你在发布之前完成。 | 翻译 | ||
| 17#翻译 | Turning Off Debug Mode | 关闭Debug模式 | 翻译 | ||
| 19#翻译 | When we created a project in Chapter 2, the command <literal>django-admin.py startproject</literal> created a <literal>settings.py</literal> file with <literal>DEBUG</literal> set to <literal>True</literal> . Many internal parts of Django check this setting and change their behavior if <literal>DEBUG</literal> mode is on. | 我们在第2章，用命令 <literal>django-admin.py startproject</literal>创建了一个项目 , 其中创建的 <literal>settings.py</literal> 文件的 <literal>DEBUG</literal> 设置默认为 <literal>True</literal>。许多Django内部模块会检查这个设置， 如果 <literal>DEBUG</literal> 模式被开启的话会改变它们的行为。 | 翻译 | ||
| 20#翻译 | For example, if <literal>DEBUG</literal> is set to <literal>True</literal> , then: | 例如， 如果 <literal>DEBUG</literal> 被设置成 <literal>True</literal> , 那么: | 翻译 | ||
| 22#翻译 | All database queries will be saved in memory as the object <literal>django.db.connection.queries</literal> . As you can imagine, this eats up memory! | 所有的数据库查询将以<literal>django.db.connection.queries</literal>的形式保存在内存中，你可以想象，它消耗内存！ | 翻译 | ||
| 24#翻译 | Any 404 error will be rendered by Django's special 404 error page (covered in Chapter 3) rather than returning a proper 404 response. | 任何404错误都将呈现Django的特殊的404页面(第3章有)而不是普通的404页面。 | 翻译 | ||
| 25#翻译 | This page contains potentially sensitive information and should <emphasis>not</emphasis> be exposed to the public Internet. | 这个页面包含潜在的敏感信息，<emphasis>不</emphasis>应该暴露在公共互联网上。 | 翻译 | ||
| 27#翻译 | Any uncaught exception in your Django application from basic Python syntax errors to database errors to template syntax errors will be rendered by the Django pretty error page that you've likely come to know and love. | 你的应用中任何未捕获的异常，从基本的Python语法错误到数据库错误以及模板语法错误都会返回漂亮的Django错误页面。 | 翻译 | ||
| 28#翻译 | This page contains even <emphasis>more</emphasis> sensitive information than the 404 page and should <emphasis>never</emphasis> be exposed to the public. | 这个页面包含了比404错误页面更多的敏感信息，所以这个页面绝对不要公开暴露。 | 翻译 | ||
| 30#翻译 | In short, setting <literal>DEBUG</literal> to <literal>True</literal> tells Django to assume only trusted developers are using your site. | 简单的说，把<literal> DEBUG</literal> 设置成<literal> True</literal> 相当于告诉Django你的网站只会被可信任的开发人员使用。 | 翻译 | ||
| 31#翻译 | The Internet is full of untrustworthy hooligans, and the first thing you should do when you're preparing your application for deployment is set <literal>DEBUG</literal> to <literal>False</literal> . | Internet里充满了不可信赖的事物，当你准备部署你的应用时，首要的事情就是把<literal> DEBUG</literal> 设置为<literal> False</literal> 。 | 翻译 | ||
| 33#翻译 | Turning Off Template Debug Mode | 关闭模板Debug模式 | 翻译 | ||
| 35#翻译 | Similarly, you should set <literal>TEMPLATE_DEBUG</literal> to <literal>False</literal> in production. | 类似地，你应该在生产环境中把<literal>TEMPLATE_DEBUG</literal>设置为<literal>False</literal>。 | 翻译 | ||
| 36#翻译 | If <literal>True</literal> , this setting tells Django's template system to save some extra information about every template, for use on the pretty error pages. | 如果这个设为<literal> True</literal> ，为了在那个好看的错误页面上显示足够的东西，Django的模版系统就会为每一个模版保存一些额外的信息。 | 翻译 | ||
| 38#翻译 | Implementing a 404 Template | 实现一个404模板 | 翻译 | ||
| 40#翻译 | If <literal>DEBUG</literal> is <literal>True</literal> , Django displays the useful 404 error page. | 如果<literal> DEBUG</literal> 设置为<literal> True</literal> ，Django会显示那个自带的404错误页面。 | 翻译 | ||
| 41#翻译 | But if <literal>DEBUG</literal> is <literal>False</literal> , then it does something different: | 但如果<literal> DEBUG</literal> 被设置成<literal> False</literal> ，那它的行为就不一样了： | 翻译 | ||
| 42#翻译 | it renders a template called <literal>404.html</literal> in your root template directory. | 它会显示一个在你的模版根目录中名字叫<literal> 404.html</literal> 的模版。 | 翻译 | ||
| 43#翻译 | So, when you're ready to deploy, you'll need to create this template and put a useful Page not found message in it. | 所以，当你准备部署你的应用时，你会需要创建这个模版并在里面放一些有意义的“页面未找到”的信息。 | 翻译 | ||
| 45#翻译 | Here's a sample <literal>404.html</literal> you can use as a starting point. | 这里有一个<literal> 404.html</literal>的示例，你可以从它开始。 | 翻译 | ||
| 46#翻译 | It assumes you're using template inheritance and have defined a <literal>base.html</literal> with blocks called <literal>title</literal> and <literal>content</literal> . | 假定你使用模板继承并定义了一个 <literal> base.html</literal>，该页面包含<literal>title</literal>和<literal>content</literal>两部分。 | 翻译 | ||
| 49#翻译 | To test that your <literal>404.html</literal> is working, just change <literal>DEBUG</literal> to <literal>False</literal> and visit a nonexistent URL. | 要测试你的<literal>404.html</literal>页面是否正常工作，仅仅需要将<literal>DEBUG</literal> 设置为<literal> False</literal> ，并且访问一个并不存在的URL。 | 翻译 | ||
| 50#翻译 | (This works on the <literal>runserver</literal> just as well as it works on a production server.) | （它在<literal> sunserver</literal> 上也能工作，和在产品服务器上一样。） | 翻译 | ||
| 52#翻译 | Implementing a 500 Template | 实现一个500模板 | 翻译 | ||
| 54#翻译 | Similarly, if <literal>DEBUG</literal> is <literal>False</literal> , then Django no longer displays its useful error/traceback pages in case of an unhandled Python exception. | 类似的，如果<literal> DEBUG</literal> 设置为<literal> False</literal> ，Djang不再会显示它自带的应对未处理的Python异常的错误反馈页面。 | 翻译 | ||
| 55#翻译 | Instead, it looks for a template called <literal>500.html</literal> and renders it. | 作为代替，它会查找一个名为<literal> 500.html</literal> 的模板并且显示它。 | 翻译 | ||
| 56#翻译 | Like <literal>404.html</literal> , this template should live in your root template directory. | 像<literal> 404.html</literal> 一样，这个模板应该被放置在你的模板根目录下。 | 翻译 | ||
| 58#翻译 | There's one slightly tricky thing about <literal>500.html</literal> . You can never be sure <emphasis>why</emphasis> this template is being rendered, so it shouldn't do anything that requires a database connection or relies on any potentially broken part of your infrastructure. | 这里有一个关于500.html的比较棘手的问题。你永远不能确定<literal> 为什么</literal>会显示这个模板，所以它不应该做任何需要连接数据库，或者依赖任何可能被破坏的基础构件的事情。 | 翻译 | ||
| 59#翻译 | (For example, it should not use custom template tags.) If it uses template inheritance, then the parent template(s) shouldn't rely on potentially broken infrastructure, either. | （例如：它不应该使用自定义模板标签。）如果它用到了模板继承，那么父模板也就不应该依赖可能被破坏的基础构件。 | 翻译 | ||
| 60#翻译 | Therefore, the best approach is to avoid template inheritance and use something very simple. | 因此，最好的方法就是避免模板继承，并且用一些非常简单的东西。 | 翻译 | ||
| 61#翻译 | Here's an example <literal>500.html</literal> as a starting point: | 这是一个<literal> 500.html</literal> 的例子，可以把它作为一个起点： | 翻译 | ||
| 64#翻译 | Setting Up Error Alerts | 设置错误警告 | 翻译 | ||
| 66#翻译 | When your Django-powered site is running and an exception is raised, you'll want to know about it, so you can fix it. | 当你使用Django制作的网站运行中出现了异常，你会希望去了解它以便于修正它。 | 翻译 | ||
| 67#翻译 | By default, Django is configured to send an e-mail to the site developers whenever your code raises an unhandled exception but you need to do two things to set it up. | 默认情况下，Django在你的代码引发未处理的异常时，将会给开发团队发送一封Email。但你需要做两件事来设置这种行为。 | 翻译 | ||
| 69#翻译 | First, change your <literal>ADMINS</literal> setting to include your e-mail address, along with the e-mail addresses of any other people who need to be notified. | 首先，改变你的<literal>ADMINS</literal>设置用来引入你的E-mail地址，还有那些任何需要被通知出现异常的联系人的E-mail地址。 | 翻译 | ||
| 70#翻译 | This setting takes a tuple of <literal>(name, email)</literal> tuples, like this: | 这个设置使用了类似于<literal>(姓名, Email)</literal>的元组，像这样： | 翻译 | ||
| 73#翻译 | Second, make sure your server is configured to send e-mail. | 第二，确保你的服务器配置为可以发送电子邮件。 | 翻译 | ||
| 74#翻译 | Setting up <literal>postfix</literal> , <literal>sendmail</literal> or any other mail server is outside the scope of this book, but on the Django side of things, you'll want to make sure your <literal>EMAIL_HOST</literal> setting is set to the proper hostname for your mail server. | 配置postfix,sendmail或其他邮件服务器超出了本书的范围，但与Django设置相关的是，你需要确保将EMAIL_HOST设置为你的邮件服务器的正确的主机名。 | 翻译 | ||
| 75#翻译 | It's set to <literal>'localhost'</literal> by default, which works out of the box for most shared-hosting environments. | 它默认设置为'localhost'，这个设置对大多数的共享主机系统环境适用. | 翻译 | ||
| 76#翻译 | You might also need to set <literal>EMAIL_HOST_USER</literal> , <literal>EMAIL_HOST_PASSWORD</literal> , <literal>EMAIL_PORT</literal> or <literal>EMAIL_USE_TLS</literal> , depending on the complexity of your arrangement. | 取决于你的安排的复杂性,你可能还需要设置 EMAIL_HOST_USER,EMAIL_HOST_PASSWORD,EMAIL_PORT或EMAIL_USE_TLS。 | 翻译 | ||
| 78#翻译 | Also, you can set <literal>EMAIL_SUBJECT_PREFIX</literal> to control the prefix Django uses in front of its error e-mails. | 你还可以设置EMAIL_SUBJECT_PREFIX以控制Django使用的通知错误的e-mail的前缀。 | 翻译 | ||
| 79#翻译 | It's set to <literal>'[Django] '</literal> by default. | 默认情况下它被设置为<literal>'[Django] '</literal>。 | 翻译 | ||
| 81#翻译 | Setting Up Broken Link Alerts | 设置连接中断警报 | 翻译 | ||
| 83#翻译 | If you have the <literal>CommonMiddleware</literal> installed (e.g., if your <literal>MIDDLEWARE_CLASSES</literal> setting includes <literal>'django.middleware.common.CommonMiddleware'</literal> , which it does by default), then you have the option of receiving an e-mail any time somebody visits a page on your Django-powered site that raises 404 with a non-empty referrer that is, every broken link. | 如果你安装有CommonMiddleware(也就是说，在你的MIDDLEWARE_CLASSES设置包含了'django.middleware.common.CommonMiddleware'的情况下，默认就安装了CommonMiddleware)，你就可以开启这个选项：有人在访问你的Django网站的一个非空的链接而导致一个404错误的发生和连接中断的情况，你将收到一封邮件. | 翻译 | ||
| 84#翻译 | If you want to activate this feature, set <literal>SEND_BROKEN_LINK_EMAILS</literal> to <literal>True</literal> (it's <literal>False</literal> by default), and set your <literal>MANAGERS</literal> setting to a person or people who will receive these broken-link e-mails. | 如果你想激活这个特性，把SEND_BROKEN_LINK_EMAILS设置为True(默认为False)，并设置你的MANAGERS为某个人或某些人的邮件地址，这些邮件地址将会收到报告连接中断错误的邮件。 | 翻译 | ||
| 85#翻译 | <literal>MANAGERS</literal> uses the same syntax as <literal>ADMINS</literal> . For example: | MANAGERS使用和ADMINS 同样的语法。例如： | 翻译 | ||
| 88#翻译 | Note that error e-mails can get annoying; they're not for everybody. | 请注意，错误的Email会令人感到反感，对于任何人来说都是这样。 | 翻译 | ||
| 90#翻译 | Using Different Settings for Production | 使用针对产品的不同的设置 | 翻译 | ||
| 92#翻译 | So far in this book, we've dealt with only a single settings file: | 在此书中，我们仅仅处理一个单一的设置文件。 | 翻译 | ||
| 93#翻译 | the <literal>settings.py</literal> generated by <literal>django-admin.py startproject</literal> . But as you get ready to deploy, you'll likely find yourself needing multiple settings files to keep your development environment isolated from your production environment. | settings.py文件由django-admin.py startproject命令生成。但是当你准备要进行部署的时候，你将发现你需要多个配置文件以使你的开发环境和产品环境相独立。 | 翻译 | ||
| 94#翻译 | (For example, you probably won't want to change <literal>DEBUG</literal> from <literal>False</literal> to <literal>True</literal> whenever you want to test code changes on your local machine.) Django makes this very easy by allowing you to use multiple settings files. | 比如，你可能不想每次在本地机器上测试代码改变的时候将DEBUG从False 改为True。Django通过使用多个配置文件而使得这种情况很容易得到避免。 | 翻译 | ||
| 96#翻译 | If you'd like to organize your settings files into production and development settings, you can accomplish this in one of three ways: | 如果你想把你的配置文件按照产品设置和开发设置组织起来，你可以通过下面三种方法的其中一种达到这个目的。 | 翻译 | ||
| 98#翻译 | Set up two full-blown, independent settings files. | 建立两个全面的，彼此独立的配置文件。 | 翻译 | ||
| 100#翻译 | Set up a base settings file (say, for development) and a second (say, production) settings file that merely imports from the first one and defines whatever overrides it needs to define. | 设置一个基本的配置文件（比如，为了开发)和第二个（为了产品)配置文件，第二个配置文件仅仅从基本的那个配置文件导入配置，并对需要定义的进行复写. | 翻译 | ||
| 102#翻译 | Use only a single settings file that has Python logic to change the settings based on context. | 使用一个单独的配置文件，此配置文件包含一个Python的逻辑判断，它根据上下文环境改变设置。 | 翻译 | ||
| 104#翻译 | We'll take these one at a time. | 我们将会依次解释这几种方式。 | 翻译 | ||
| 106#翻译 | First, the most basic approach is to define two separate settings files. | 首先，最基本的方法是定义两个单独的配置文件。 | 翻译 | ||
| 107#翻译 | If you're following along, you've already got <literal>settings.py</literal> . Now, just make a copy of it called <literal>settings_production.py</literal> . (We made this name up; you can call it whatever you want.) In this new file, change <literal>DEBUG</literal> , etc. | 如果你是跟随之前的例子做下来的，那么你已经有了一个settings.py了，现在你只需要将它复制一份并命名为settings_production.py（文件名可以按照你自己的喜好定义),在这个新文件中改变DEBUG等设置。 | 翻译 | ||
| 109#翻译 | The second approach is similar but cuts down on redundancy. | 第二种方法比较类似，但是减少了许多冗余。 | 翻译 | ||
| 110#翻译 | Instead of having two settings files whose contents are mostly similar, you can treat one as the base file and create another file that imports from it. | 作为使用两个内容大部分相同的配置文件的替代方式，你可以使用一个文件为基本文件，另外一个文件从基本文件中导入相关设定。 | 翻译 | ||
| 111#翻译 | For example: | 例如 | 翻译 | ||
| 114#翻译 | Here, <literal>settings_production.py</literal> imports everything from <literal>settings.py</literal> and just redefines the settings that are particular to production. | 此处，settings_production.py 从settings.py 导入所有的设定，仅仅只是重新定义了产品模式下需要特殊处理的设置。 | 翻译 | ||
| 115#翻译 | In this case, <literal>DEBUG</literal> is set to <literal>False</literal> , but we've also set different database access parameters for the production setting. | 在这个案例中，DEBUG 被设置为False，但是我们已经对产品模式设置了不同的数据库访问参数。 | 翻译 | ||
| 116#翻译 | (The latter goes to show that you can redefine <emphasis>any</emphasis> setting, not just the basic ones like <literal>DEBUG</literal> .) | （后者向你演示可以重新定义 任何 设置，并不只是象 DEBUG 这样的基本设置。） | 翻译 | ||
| 118#翻译 | Finally, the most concise way of accomplishing two settings environments is to use a single settings file that branches based on the environment. | 最后，最精简的达到两个配置环境设定的方案是使用一个配置文件，在此配置文件中根据不同的环境进行设置。 | 翻译 | ||
| 119#翻译 | One way to do this is to check the current hostname. | 达到这个目的，一个方法是检查当前的主机名。 | 翻译 | ||
| 120#翻译 | For example: | 例如： | 翻译 | ||
| 123#翻译 | Here, we import the <literal>socket</literal> module from Python's standard library and use it to check the current system's hostname. | 在这里，我们从Python标准库导入了<literal>socket</literal>模块，使用它来检查当前系统的主机名。 | 翻译 | ||
| 124#翻译 | We can check the hostname to determine whether the code is being run on the production server. | 我们可以通过检查主机名来确认代码是否运行在产品服务器上。 | 翻译 | ||
| 126#翻译 | A core lesson here is that settings files are <emphasis>just Python code</emphasis> . They can import from other files, they can execute arbitrary logic, etc. | 关键是配置文件仅仅是包含Python代码的文件。你可以从其他文件导入这些Python代码，可以通过这些代码执行任意的逻辑判断等操作。 | 翻译 | ||
| 127#翻译 | Just make sure that, if you go down this road, the Python code in your settings files is bulletproof. | 如果你打算采用这种方案，请确定这些配置文件中的代码是足够安全（防弹)的。 | 翻译 | ||
| 128#翻译 | If it raises any exceptions, Django will likely crash badly. | 如果这个配置文件抛出任何异常，Django有可能发生很严重的崩溃。 | 翻译 | ||
| 130#翻译 | Renaming settings.py | 重命名settings.py | 翻译 | ||
| 132#翻译 | Feel free to rename your <literal>settings.py</literal> to <literal>settings_dev.py</literal> or <literal>settings/dev.py</literal> or <literal>foobar.py</literal> Django doesn't care, as long as you tell it what settings file you're using. | 随便将你的settings.py重命名为settings_dev.py或settings/dev.py或foobar.py，Django 并不在乎你的配置文件叫什么名字，只要告诉它你使用哪个配置文件就可以了。 | 翻译 | ||
| 134#翻译 | But if you <emphasis>do</emphasis> rename the <literal>settings.py</literal> file that is generated by <literal>django-admin.py startproject</literal> , you'll find that <literal>manage.py</literal> will give you an error message saying that it can't find the settings. | 但是如果你真的重命名了由django-admin.py startproject 命令创建的settings.py文件，你会发现manage.py会给出一个错误信息说找不到配置文件。 | 翻译 | ||
| 135#翻译 | That's because it tries to import a module called <literal>settings</literal> . You can fix this either by editing <literal>manage.py</literal> to change <literal>settings</literal> to the name of your module, or by using <literal>django-admin.py</literal> instead of <literal>manage.py</literal> . In the latter case, you'll need to set the <literal>DJANGO_SETTINGS_MODULE</literal> environment variable to the Python path to your settings file (e.g., <literal>'mysite.settings'</literal> ). | 那是由于它尝试从这个文件中导入一个叫做settings的模块，你可以通过修改manage.py 文件，将 import settings 语句改为导入你自己的模块，或者使用django-admin.py而不是使用manage.py，在后一种方式中你需要设置 DJANGO_SETTINGS_MODULE 环境变量为你的配置文件所在的Python 路径(比如'mysite.settings'）。 | 翻译 | ||
| 137#翻译 | DJANGO_SETTINGS_MODULE | DJANGO_SETTINGS_MODULE | 翻译 | ||
| 139#翻译 | With those code changes out of the way, the next part of this chapter will focus on deployment instructions for specific environments, such as Apache. | 通过这种方式的代码改变后，本章的下一部分将集中在对具体环境(比如Apache)的发布所需要的指令上。 | 翻译 | ||
| 140#翻译 | The instructions are different for each environment, but one thing remains the same: | 这些指令针对每一种环境都不同，但是有一件事情是相同的。 | 翻译 | ||
| 141#翻译 | in each case, you will have to tell the Web server your <literal>DJANGO_SETTINGS_MODULE</literal> . This is the entry point into your Django application. | 在每一种环境中，你都需要告诉Web服务器你的DJANGO_SETTINGS_MODULE是什么,这是你的Django应用程序的入口。 | 翻译 | ||
| 142#翻译 | The <literal>DJANGO_SETTINGS_MODULE</literal> points to your settings file, which points to your <literal>ROOT_URLCONF</literal> , which points to your views, and so on. | DJANGO_SETTINGS_MODULE指向你的配置文件，而你的配置文件指向你的ROOT_URLCONF，在ROOT_URLCONF中指向了你的视图以及其他的部分。 | 翻译 | ||
| 144#翻译 | <literal>DJANGO_SETTINGS_MODULE</literal> is the Python path to your settings file. | DJANGO_SETTINGS_MODULE是你的配置文件的Python的路径。 | 翻译 | ||
| 145#翻译 | For example, assuming the <literal>mysite</literal> directory is on your Python path, the <literal>DJANGO_SETTINGS_MODULE</literal> for our ongoing example is <literal>'mysite.settings'</literal> . | 比如，假设mysite是在你的Python路径中，DJANGO_SETTINGS_MODULE对于我们正在进行的例子就是'mysite.settings'。 | 翻译 | ||
| 147#翻译 | Using Django with Apache and mod_python | 用Apache和mod_python来部署Django | 翻译 | ||
| 149#翻译 | Apache with mod_python historically has been the suggested setup for using Django on a production server. | 目前，Apache和mod_python是在生产服务器上部署Django的最健壮搭配。 | 翻译 | ||
| 151#翻译 | mod_python (<reference name="http://www.djangoproject.com/r/mod_python/" refuri="http://www.djangoproject.com/r/mod_python/">http://www.djangoproject.com/r/mod_python/</reference>) is an Apache plug-in that embeds Python within Apache and loads Python code into memory when the server starts. | mod_python (<reference name="http://www.djangoproject.com/r/mod_python/" refuri="http://www.djangoproject.com/r/mod_python/">http://www.djangoproject.com/r/mod_python/</reference>)是一个在Apache中嵌入Python的Apache插件，它在服务器启动时将Python代码加载到内存中。 | 翻译 | ||
| 152#翻译 | Code stays in memory throughout the life of an Apache process, which leads to significant performance gains over other server arrangements. | 代码在Apache进程的整个生命周期内驻留在内存中，这对服务器调度有着非常积极的意义。 | 翻译 | ||
| 154#翻译 | Django requires Apache 2.x and mod_python 3.x. | Django 需要Apaceh 2.x 和mod_python 3.x支持。 | 翻译 | ||
| 156#翻译 | Note | 备注 | 翻译 | ||
| 158#翻译 | Configuring Apache is <emphasis>well</emphasis> beyond the scope of this book, so we'll simply mention details as needed. | 如何配置Apache超出了本书的范围，因此下面将只简单介绍必要的细节。 | 翻译 | ||
| 159#翻译 | Luckily, many great resources are available if you need to learn more about Apache. | 幸运的是，如果需要进一步学习Apache的相关知识，你可以找到相当多的绝佳资源。 | 翻译 | ||
| 160#翻译 | A few of them we like are: | 我们喜欢去的几个地方: | 翻译 | ||
| 162#翻译 | The free online Apache documentation, available via <reference name="http://www.djangoproject.com/r/apache/docs/" refuri="http://www.djangoproject.com/r/apache/docs/">http://www.djangoproject.com/r/apache/docs/</reference> | 开源的Apache在线文档，位于 <reference name="http://www.djangoproject.com/r/apache/docs/" refuri="http://www.djangoproject.com/r/apache/docs/">http://www.djangoproject.com/r/apache/docs/</reference> | 翻译 | ||
| 164#翻译 | <emphasis>Pro Apache, Third Edition</emphasis> (Apress, 2004) by Peter Wainwright, available via <reference name="http://www.djangoproject.com/r/books/pro-apache/" refuri="http://www.djangoproject.com/r/books/pro-apache/">http://www.djangoproject.com/r/books/pro-apache/</reference> | <emphasis>Pro Apache，第三版</emphasis> (Apress, 2004),作者Peter Wainwright, 位于 <reference name="http://www.djangoproject.com/r/books/pro-apache/" refuri="http://www.djangoproject.com/r/books/pro-apache/">http://www.djangoproject.com/r/books/pro-apache/</reference> | 翻译 | ||
| 166#翻译 | <emphasis>Apache: | Apache： | 翻译 | ||
| 167#翻译 | The Definitive Guide, Third Edition</emphasis> (O'Reilly, 2002) by Ben Laurie and Peter Laurie, available via <reference name="http://www.djangoproject.com/r/books/pro-apache/" refuri="http://www.djangoproject.com/r/books/pro-apache/">http://www.djangoproject.com/r/books/pro-apache/</reference> | The Definitive Guide, 第三版</emphasis> (OReilly, 2002),作者Ben Laurie和Peter Laurie, 位于 <reference name="http://www.djangoproject.com/r/books/apache-pra/" refuri="http://www.djangoproject.com/r/books/apache-pra/">http://www.djangoproject.com/r/books/apache-pra/</reference> | 翻译 | ||
| 169#翻译 | Basic Configuration | 基本配置 | 翻译 | ||
| 171#翻译 | To configure Django with mod_python, first make sure you have Apache installed with the mod_python module activated. | 为了配置基于 mod_python 的 Django，首先要安装有可用的 mod_python 模块的 Apache。 | 翻译 | ||
| 172#翻译 | This usually means having a <literal>LoadModule</literal> directive in your Apache configuration file. | 这通常意味着应该有一个 <literal>LoadModule</literal> 指令在 Apache 配置文件中。 | 翻译 | ||
| 173#翻译 | It will look something like this: | 它看起来就像是这样： | 翻译 | ||
| 176#翻译 | Then, edit your Apache configuration file and add a <literal><Location></literal> directive that ties a specific URL path to a specific Django installation. | 然后，更改Apache配置文件，增加一个<literal>Location</literal>命令指向Django的安装路径。 | 翻译 | ||
| 177#翻译 | For example: | 例如： | 翻译 | ||
| 180#翻译 | Make sure to replace <literal>mysite.settings</literal> with the appropriate <literal>DJANGO_SETTINGS_MODULE</literal> for your site. | 要确保把 <literal>DJANGO_SETTINGS_MODULE</literal> 中的 <literal>mysite.settings</literal> 项目换成与你的站点相应的内容。 | 翻译 | ||
| 182#翻译 | This tells Apache, Use mod_python for any URL at or under /', using the Django mod_python handler. | 它告诉 Apache，任何在 / 这个路径之后的 URL 都使用 Django 的 mod_python 来处理。 | 翻译 | ||
| 183#翻译 | It passes the value of <literal>DJANGO_SETTINGS_MODULE</literal> so mod_python knows which settings to use. | 它 将 <literal>DJANGO_SETTINGS_MODULE</literal> 的值传递过去，使得 mod_python 知道这时应该使用哪个配置。 | 翻译 | ||
| 185#翻译 | Note that we're using the <literal><Location></literal> directive, not the <literal><Directory></literal> directive. | 注意这里使用 <literal>Location</literal> 指令而不是 <literal>Directory</literal> 。 | 翻译 | ||
| 186#翻译 | The latter is used for pointing at places on your filesystem, whereas <literal><Location></literal> points at places in the URL structure of a Web site. | 后者用于指向你的文件系统中的一个位置，然而 <literal>Location</literal> 指向一个 Web 站点的 URL 位置。 | 翻译 | ||
| 187#翻译 | <literal><Directory></literal> would be meaningless here. | 在这里使用<literal>Directory</literal>没有意义。 | 翻译 | ||
| 189#翻译 | Apache likely runs as a different user than your normal login and may have a different path and sys.path. | Apache 可能不但会运行在你正常登录的环境中，也会运行在其它不同的用户环境中；也可能会有不同的文件路径或 sys.path。 | 翻译 | ||
| 190#翻译 | You may need to tell mod_python how to find your project and Django itself. | 你需要告诉 mod_python 如何去寻找你的项目及 Django 的位置。 | 翻译 | ||
| 193#翻译 | You can also add directives such as <literal>PythonAutoReload Off</literal> for performance. | 你也可以加入一些其它指令，比如 <literal>PythonAutoReload Off</literal> 以提升性能。 | 翻译 | ||
| 194#翻译 | See the mod_python documentation for a full list of options. | 查看 mod_python 文档获得详细的指令列表。 | 翻译 | ||
| 196#翻译 | Note that you should set <literal>PythonDebug Off</literal> on a production server. | 注意，你应该在产品服务器上设置 <literal>PythonDebug Off</literal> 。 | 翻译 | ||
| 197#翻译 | If you leave <literal>PythonDebug On</literal> , your users will see ugly (and revealing) Python tracebacks if something goes wrong within mod_python. | 如果你使用<literal>PythonDebug On</literal>的话，在程序产生错误时，你的用户会看到mod_python内部难看的（并且是暴露的）Python对错误的追踪信息。 | 翻译 | ||
| 199#翻译 | Restart Apache, and any request to your site (or virtual host if you've put this directive inside a <literal><VirtualHost></literal> block) will be served by Django. | 重启 Apache 之后所有对你的站点的请求（或者是当你用了 <literal>VirtualHost</literal> 指令后则是虚拟主机）都会由 Django 来处理。 | 翻译 | ||
| 201#翻译 | Running Multiple Django Installations on the Same Apache Instance | 在同一个 Apache 的实例中运行多个 Django 程序 | 翻译 | ||
| 203#翻译 | It's entirely possible to run multiple Django installations on the same Apache instance. | 在同一个 Apache 实例中运行多个 Django 程序是完全可能的。 | 翻译 | ||
| 204#翻译 | You might want to do this if you're an independent Web developer with multiple clients but only a single server. | 如果你是一个独立的 Web 开发人员，只有一台服务器并有多个不同的客户时，你可能会想这么做。 | 翻译 | ||
| 206#翻译 | To accomplish this, just use <literal>VirtualHost</literal> like so: | 想实现这个，只要像下面这样使用 <literal>VirtualHost</literal>： | 翻译 | ||
| 209#翻译 | If you need to put two Django installations within the same <literal>VirtualHost</literal> , you'll need to take a special precaution to ensure mod_python's code cache doesnt mess things up. | 如果你需要在同一个 <literal>VirtualHost</literal> 中运行两个 Django 程序，你需要特别留意一下以 确保 mod_python 的代码缓存不被弄得乱七八糟。 | 翻译 | ||
| 210#翻译 | Use the <literal>PythonInterpreter</literal> directive to give different <literal><Location></literal> directives separate interpreters: | 使用 <literal>PythonInterpreter</literal> 指令来为不同的 <literal>location</literal>指定不同的解释器： | 翻译 | ||
| 213#翻译 | The values of <literal>PythonInterpreter</literal> don't really matter, as long as theyre different between the two <literal>Location</literal> blocks. | 这个 <literal>PythonInterpreter</literal> 中的值不重要，只要它们在两个 <literal>Location</literal> 块中不同。 | 翻译 | ||
| 215#翻译 | Running a Development Server with mod_python | 用 mod_python 运行一个开发服务器 | 翻译 | ||
| 217#翻译 | Because mod_python caches loaded Python code, when deploying Django sites on mod_python you'll need to restart Apache each time you make changes to your code. | 因为 mod_python 缓存了载入的Python 的代码，所以当在 mod_python上发布 Django 站点时，你每改动一次代码就需要重启 Apache 一次。 | 翻译 | ||
| 218#翻译 | This can be a hassle, so here's a quick trick to avoid it: | 这还真是件麻烦事，所以这有个办法来避免它： | 翻译 | ||
| 219#翻译 | just add <literal>MaxRequestsPerChild 1</literal> to your config file to force Apache to reload everything for each request. | 只要 加入 <literal>MaxRequestsPerChild 1</literal> 到配置文件中强制 Apache 在每个请求时都重新载入所有的 代码。 | 翻译 | ||
| 220#翻译 | But don't do that on a production server, or we'll revoke your Django privileges. | 但是不要在产品服务器上使用这个指令，这会撤销 Django 的特权。 | 翻译 | ||
| 222#翻译 | If you're the type of programmer who debugs using scattered <literal>print</literal> statements (we are), note that <literal>print</literal> statements have no effect in mod_python; they don't appear in the Apache log, as you might expect. | 如果你是一个用分散的 <literal>print</literal> 语句（我们就是这样）来调试的程序员，注意这 <literal>print</literal> 语 句在 mod_python 中是无效的；它不会像你希望的那样产生一个 Apache 日志。 | 翻译 | ||
| 223#翻译 | If you have the need to print debugging information in a mod_python setup, you'll probably want to use Python's standard logging package. | 如果你需要在 mod_python 中打印调试信息，可能需要用到 Python 标准日志包（Pythons standard logging package）。 | 翻译 | ||
| 224#翻译 | More information is available at <reference name="http://docs.python.org/lib/module-logging.html" refuri="http://docs.python.org/lib/module-logging.html">http://docs.python.org/lib/module-logging.html</reference>. | 更多的信息请参见 <reference name="http://docs.python.org/lib/module-logging.html" refuri="http://docs.python.org/lib/module-logging.html">http://docs.python.org/lib/module-logging.html</reference> 。 | 翻译 | ||
| 226#翻译 | Serving Django and Media Files from the Same Apache Instance | 使用相同的Apache实例来服务Django和Media文件 | 翻译 | ||
| 228#翻译 | Django should not be used to serve media files itself; leave that job to whichever Web server you choose. | Django本身不用来服务media文件；应该把这项工作留给你选择的网络服务器。 | 翻译 | ||
| 229#翻译 | We recommend using a separate Web server (i.e., one that's not also running Django) for serving media. | 我们推荐使用一个单独的网络服务器（即没有运行Django的一个）来服务media。 | 翻译 | ||
| 230#翻译 | For more information, see the Scaling section. | 想了解更多信息，看下面的章节。 | 翻译 | ||
| 232#翻译 | If, however, you have no option but to serve media files on the same Apache <literal>VirtualHost</literal> as Django, here's how you can turn off mod_python for a particular part of the site: | 不过，如果你没有其他选择，只能在Django所在的Apache <literal>VirtualHost</literal> 上服务media文件，这里你可以针对这个站点的特定部分关闭mod_python： | 翻译 | ||
| 235#翻译 | Change <literal>Location</literal> to the root URL of your media files. | 将 <literal>Location</literal> 改成你的media文件所处的根目录。 | 翻译 | ||
| 237#翻译 | You can also use <literal><LocationMatch></literal> to match a regular expression. | 你也可以使用 <literal><LocationMatch></literal> 来匹配正则表达式。 | 翻译 | ||
| 238#翻译 | For example, this sets up Django at the site root but explicitly disables Django for the <literal>media</literal> subdirectory and any URL that ends with <literal>.jpg</literal> , <literal>.gif</literal> , or <literal>.png</literal> : | 比如，下面的写法将Django定义到网站的根目录，并且显式地将 <literal>media</literal> 子目录以及任何以 <literal>.jpg</literal> ， <literal>.gif</literal> ， 或者 <literal>.png</literal> 结尾的URL屏蔽掉: | 翻译 | ||
| 241#翻译 | In all of these cases, you'll need to set the <literal>DocumentRoot</literal> directive so Apache knows where to find your static files. | 在所有这些例子中，你必须设置 <literal>DocumentRoot</literal> ，这样Apache才能知道你存放静态文件的位置。 | 翻译 | ||
| 243#翻译 | Error Handling | 错误处理 | 翻译 | ||
| 245#翻译 | When you use Apache/mod_python, errors will be caught by Django in other words, they won't propagate to the Apache level and won't appear in the Apache <literal>error_log</literal> . | 当你使用 Apache/mod_python 时，错误会被 Django 捕捉，它们不会传播到 Apache 那里，也不会出现在 Apache 的 <literal>错误日志</literal> 中。 | 翻译 | ||
| 247#翻译 | The exception to this is if something is really messed up in your Django setup. | 除非你的 Django 设置的确出了问题。 | 翻译 | ||
| 248#翻译 | In that case, you'll see an ominous Internal Server Error page in your browser and the full Python traceback in your Apache <literal>error_log</literal> file. | 在这种情况下，你会在浏览器上看到一个 内部服务器错误的页面，并在 Apache 的 <literal>错误日志</literal> 中看到 Python 的完整回溯信息。 | 翻译 | ||
| 249#翻译 | The <literal>error_log</literal> traceback is spread over multiple lines. | <literal>错误日志</literal> 的回溯信息有多行。 | 翻译 | ||
| 250#翻译 | (Yes, this is ugly and rather hard to read, but it's how mod_python does things.) | （当然，这些信息是难看且难以阅读的，不过mod_python就是这么工作的。） | 翻译 | ||
| 252#翻译 | Handling a Segmentation Fault | 处理段错误(Segmentation Fault) | 翻译 | ||
| 254#翻译 | Sometimes, Apache segfaults when you install Django. | 有时候，Apache会在你安装Django的时候发生段错误。 | 翻译 | ||
| 255#翻译 | When this happens, it's almost <emphasis>always</emphasis> one of two causes mostly unrelated to Django itself: | 这时，基本上 <emphasis>总是</emphasis>由以下两个与Django本身无关的原因其中之一所造成： | 翻译 | ||
| 257#翻译 | It may be that your Python code is importing the <literal>pyexpat</literal> module (used for XML parsing), which may conflict with the version embedded in Apache. | 有可能是因为，你使用了 <literal>pyexpat</literal> 模块（进行XML解析）并且与Apache内置的版本相冲突。 | 翻译 | ||
| 258#翻译 | For full information, see Expat Causing Apache Crash at <reference name="http://www.djangoproject.com/r/articles/expat-apache-crash/" refuri="http://www.djangoproject.com/r/articles/expat-apache-crash/">http://www.djangoproject.com/r/articles/expat-apache-crash/</reference>. | 详情请见expat导致Apache崩溃 <reference name="http://www.djangoproject.com/r/articles/expat-apache-crash/" refuri="http://www.djangoproject.com/r/articles/expat-apache-crash/">http://www.djangoproject.com/r/articles/expat-apache-crash/</reference>. | 翻译 | ||
| 260#翻译 | It may be because you're running mod_python and mod_php in the same Apache instance, with MySQL as your database backend. | 也有可能是在同一个Apache进程中，同时使用了mod_python 和 mod_php，而且都使用MySQL作为数据库后端。 | 翻译 | ||
| 261#翻译 | In some cases, this causes a known mod_python issue due to version conflicts in PHP and the Python MySQL back-end. | 在有些情况下，这会造成PHP和Python的MySQL模块的版本冲突。 | 翻译 | ||
| 262#翻译 | There's full information in a mod_python FAQ entry, accessible via <reference name="http://www.djangoproject.com/r/articles/php-modpython-faq/" refuri="http://www.djangoproject.com/r/articles/php-modpython-faq/">http://www.djangoproject.com/r/articles/php-modpython-faq/</reference>. | 在mod_python的FAQ中有更详细的解释。 | 翻译 | ||
| 264#翻译 | 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. | 如果还有安装mod_python的问题，有一个好的建议，就是先只运行mod_python站点，而不使用Django框架。 | 翻译 | ||
| 265#翻译 | This is an easy way to isolate mod_python-specific problems. | 这是区分mod_python特定问题的好方法。 | 翻译 | ||
| 266#翻译 | The article Getting mod_python Working details this procedure: | 下面的这篇文章给出了更详细的解释。 | 翻译 | ||
| 267#翻译 | <reference name="http://www.djangoproject.com/r/articles/getting-modpython-working/" refuri="http://www.djangoproject.com/r/articles/getting-modpython-working/">http://www.djangoproject.com/r/articles/getting-modpython-working/</reference>. | <reference name="http://www.djangoproject.com/r/articles/getting-modpython-working/" refuri="http://www.djangoproject.com/r/articles/getting-modpython-working/">http://www.djangoproject.com/r/articles/getting-modpython-working/</reference>. | 翻译 | ||
| 269#翻译 | The next step should be to edit your test code and add an import of any Django-specific code you're using your views, your models, your URLconf, your RSS configuration, and so forth. | 下一个步骤应该是编辑一段测试代码，把你所有Django相关代码import进去，包括你的views,models,URLconf,RSS配置，等等。 | 翻译 | ||
| 270#翻译 | Put these imports in your test handler function and access your test URL in a browser. | 把这些imports放进你的handler函数中，然后从浏览器进入你的URL。 | 翻译 | ||
| 271#翻译 | If this causes a crash, you've confirmed its the importing of Django code that causes the problem. | 如果这些导致了崩溃，你就可以确定是import的Django代码引起了问题。 | 翻译 | ||
| 272#翻译 | Gradually reduce the set of imports until it stops crashing, so as to find the specific module that causes the problem. | 逐个去掉这些imports，直到不再崩溃，这样就能找到引起问题的那个模块。 | 翻译 | ||
| 273#翻译 | Drop down further into modules and look into their imports as necessary. | 深入了解各模块，看看它们的imports。 | 翻译 | ||
| 274#翻译 | For more help, system tools like <literal>ldconfig</literal> on Linux, <literal>otool</literal> on Mac OS, and <literal>ListDLLs</literal> (from SysInternals) on Windows can help you identify shared dependencies and possible version conflicts. | 要想获得更多帮助，像linux的<literal>ldconfig</literal>，Mac OS的<literal>otool</literal>和windows的<literal>ListDLLs</literal>（来自sysInternals）都可以帮你识别共享依赖和可能的版本冲突。 | 翻译 | ||
| 276#翻译 | An Alternative: | 一种替代方案： | 翻译 | ||
| 277#翻译 | mod_wsgi | mod_wsgi | 翻译 | ||
| 279#翻译 | As an alternative to mod_python, you might consider using mod_wsgi (<reference name="http://code.google.com/p/modwsgi/" refuri="http://code.google.com/p/modwsgi/">http://code.google.com/p/modwsgi/</reference>), which has been developed more recently than mod_python and is getting some traction in the Django community. | 作为一个mod_python模块的替代，你可以考虑使用mod_wsgi模块(<reference name="http://code.google.com/p/modwsgi/" refuri="http://code.google.com/p/modwsgi/">http://code.google.com/p/modwsgi/</reference>),此模块开发的时间比mod_python的开发时间离现在更近一些，在Django社区已有一些使用。 | 翻译 | ||
| 280#翻译 | A full overview is outside the scope of this book, but see the official Django documentation for more information. | 一个完整的概述超出了本书的范围，你可以从官方的Django文档查看到更多的信息。 | 翻译 | ||
| 282#翻译 | Using Django with FastCGI | 使用FastCGI部署Django应用 | 翻译 | ||
| 284#翻译 | 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。 | 翻译 | ||
| 286#翻译 | Additionally, in some situations, FastCGI allows better security and possibly better performance than mod_python. | 此外，在很多情况下，FastCGI能够提供比mod_python更为优越的安全性和效能。 | 翻译 | ||
| 287#翻译 | For small sites, FastCGI can also be more lightweight than Apache. | 针对小型站点，相对于Apache来说FastCGI更为轻量级。 | 翻译 | ||
| 289#翻译 | FastCGI Overview | FastCGI 简介 | 翻译 | ||
| 291#翻译 | FastCGI is an efficient way of letting an external application serve pages to a Web server. | 借助于FastCGI，外部应用程序可以解释WEB服务器上的动态页面请求呢？ | 翻译 | ||
| 292#翻译 | 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 client's Web browser. | Web服务器把请求（以socket形式）传给FastCGI，FastCGI执行代码，然后把响应返回给Web服务器，继而又发回给客户端浏览器。 | 翻译 | ||
| 294#翻译 | Like mod_python, FastCGI allows code to stay in memory, allowing requests to be served with no startup time. | 和mod_python一样，FastCGI也是驻留在内存里为客户请求返回动态信息,而且也免掉了像传统的CGI一样启动进程时候的时间花销。 | 翻译 | ||
| 295#翻译 | Unlike mod_python, a FastCGI process doesn't run inside the Web server process, but in a separate, persistent process. | 但于mod_python不同之处是它并不是作为模块运行在Web服务器同一进程内的，而是有自己的独立进程。 | 翻译 | ||
| 297#翻译 | Why Run Code in a Separate Process? | 为什么要在一个独立的进程中运行代码？ | 翻译 | ||
| 299#翻译 | The traditional <literal>mod_*</literal> 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. | 在以传统的方式的几种以<literal>mod_*</literal>方式嵌入到Apache的脚本语言中（常见的例如：PHP，Python/mod_python和Perl/mod_perl），他们都是以Apache扩展模块的方式将自身嵌入到Apache进程中的。 | 翻译 | ||
| 300#翻译 | Although this lowers startup time (because code doesn't have to be read off disk for every request), it comes at the cost of memory use. | 尽管这么做缩短了启动时间（因为不需要每次处理请求时都读磁盘），但是它占用了内存。 | 翻译 | ||
| 302#翻译 | Each Apache process gets a copy of the Apache engine, complete with all the features of Apache that Django simply doesn't take advantage of. | 每一个Apache进程都是一个Apache引擎的副本，它完全包括了所有Apache所具有的一切功能特性（哪怕是对Django毫无好处的东西也一并加载进来）。 | 翻译 | ||
| 303#翻译 | FastCGI processes, on the other hand, only have the memory overhead of Python and Django. | 而FastCGI就不一样了，它仅仅把Python和Django等必备的东东弄到内存中。 | 翻译 | ||
| 305#翻译 | Due to the nature of FastCGI, it's also possible to have processes that run under a different user account than the Web server process. | 依据FastCGI自身的特点可以看到，FastCGI进程可以与Web服务器的进程分别运行在不同的用户权限下。 | 翻译 | ||
| 306#翻译 | That's a nice security benefit on shared systems, because it means you can secure your code from other users. | 对于一个多人共用的系统来说，这个特性对于安全性是非常有好处的，因为你可以安全地与别人分享和重用代码了。 | 翻译 | ||
| 308#翻译 | Before you can start using FastCGI with Django, you'll need to install <literal>flup</literal> , a Python library for dealing with FastCGI. | 如果你希望你的Django以FastCGI的方式运行，那么你还必须安装 <literal>flup</literal> 这个Python库，这个库就是用于处理FastCGI的。 | 翻译 | ||
| 309#翻译 | Some users have reported stalled pages with older <literal>flup</literal> versions, so you may want to use the latest SVN version. | 一些用户都抱怨 <literal>flup</literal> 的发布版太久了，老是不更新，这样你可以使用最新的SVN版本。 | 翻译 | ||
| 310#翻译 | Get <literal>flup</literal> at <reference name="http://www.djangoproject.com/r/flup/" refuri="http://www.djangoproject.com/r/flup/">http://www.djangoproject.com/r/flup/</reference>. | 地址是<reference name="http://www.djangoproject.com/r/flup/" refuri="http://www.djangoproject.com/r/flup/">http://www.djangoproject.com/r/flup/</reference>。 | 翻译 | ||
| 312#翻译 | Running Your FastCGI Server | 运行你的 FastCGI 服务器 | 翻译 | ||
| 314#翻译 | FastCGI operates on a client/server model, and in most cases you'll be starting the FastCGI server process on your own. | FastCGI是以客户机/服务器方式运行的，并且在很多情况下，你得自己去启动FastCGI的服务进程。 | 翻译 | ||
| 315#翻译 | 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. | Web服务器（例如Apache,lighttpd等等）仅仅在有动态页面访问请求的时候才会去与你的Django-FastCGI进程交互。 | 翻译 | ||
| 316#翻译 | Because the daemon is already running with the code in memory, it's able to serve the response very quickly. | 因为Fast-CGI已经一直驻留在内存里面了的，所以它响应起来也是很快的。 | 翻译 | ||
| 318#翻译 | Note | 注释 | 翻译 | ||
| 320#翻译 | If you're on a shared hosting system, you'll probably be forced to use Web server-managed FastCGI processes. | 在虚拟主机上使用的话，你可能会被强制的使用Web server-managed FastCGI进程。 | 翻译 | ||
| 321#翻译 | If you're in this situation, you should read the section titled Running Django on a Shared-Hosting Provider with Apache, below. | 在这样的情况下，请参阅下面的“在Apache共享主机里运行Django”这一小节。 | 翻译 | ||
| 323#翻译 | A Web server can connect to a FastCGI server in one of two ways: | Web服务器有两种方式与FastCGI进行交互： | 翻译 | ||
| 324#翻译 | it can use either a Unix domain socket (a <emphasis>named pipe</emphasis> on Win32 systems) or a TCP socket. | 使用Unix domain socket(在Win32里面是 <emphasis>命名管道</emphasis> )或者使用TCP socket。 | 翻译 | ||
| 325#翻译 | What you choose is a manner of preference; a TCP socket is usually easier due to permissions issues. | 具体使用哪一个，那就根据你的偏好而定了，但是TCP socket通常更容易一些因为一些权限上的问题。 | 翻译 | ||
| 327#翻译 | To start your server, first change into the directory of your project (wherever your <literal>manage.py</literal> is), and then run <literal>manage.py</literal> with the <literal>runfcgi</literal> command: | 启动你的服务器项目。首先进入你的项目目录下（你的 <literal>manage.py</literal> 文件所在之处），然后使用 <literal>manage.py runfcgi</literal> 命令： | 翻译 | ||
| 330#翻译 | If you specify <literal>help</literal> as the only option after <literal>runfcgi</literal> , a list of all the available options will display. | 想了解如何使用 <literal>runfcgi</literal> ，输入 <literal>manage.py runfcgi help</literal> 命令。 | 翻译 | ||
| 332#翻译 | You'll need to specify either a <literal>socket</literal> or both <literal>host</literal> and <literal>port</literal> . Then, when you set up your Web server, you'll just need to point it at the socket or host/port you specified when starting the FastCGI server. | 你需要指定 <literal>socket</literal> 或者同时指定 <literal>host</literal> 和 <literal>port</literal> 。当你创建Web服务器时，你只需要将服务器指向当你在启动FastCGI服务器时确定的socket或者host/port。 | 翻译 | ||
| 334#翻译 | A few examples should help explain this: | 范例： | 翻译 | ||
| 336#翻译 | Running a threaded server on a TCP port: | 在TCP端口上运行一个线程服务器： | 翻译 | ||
| 339#翻译 | Running a preforked server on a Unix domain socket: | 在Unix socket上运行prefork服务器： | 翻译 | ||
| 342#翻译 | Run without daemonizing (backgrounding) the process (good for debugging): | 启动，但不作为后台进程（在调试时比较方便）： | 翻译 | ||
| 345#翻译 | Stopping the FastCGI Daemon | 停止FastCGI的行程 | 翻译 | ||
| 347#翻译 | If you have the process running in the foreground, it's easy enough to stop it: | 如果你的FastCGI是在前台运行的，那么停止它就非常简单了： | 翻译 | ||
| 348#翻译 | simply press Ctrl+C to stop and quit the FastCGI server. | 简单地按Ctrl+C就可以退出FastCGI服务器。 | 翻译 | ||
| 349#翻译 | However, when you're dealing with background processes, you'll need to resort to the Unix <literal>kill</literal> command. | 但如果是在后台运行的话，你就要使用Unix的<literal>kill</literal>命令来杀掉它。 | 翻译 | ||
| 351#翻译 | If you specify the <literal>pidfile</literal> option to your <literal>manage.py runfcgi</literal> , you can kill the running FastCGI daemon like this: | 如果你在 <literal>manage.py runfcgi</literal> 中指定了 <literal>pidfile</literal> 这个选项，那么你可以这样来杀死这个FastCGI后台进程： | 翻译 | ||
| 354#翻译 | where <literal>$PIDFILE</literal> is the <literal>pidfile</literal> you specified. | <literal>$PIDFILE</literal> 就是你指定的那个 <literal>pidfile</literal>。 | 翻译 | ||
| 356#翻译 | To easily restart your FastCGI daemon on Unix, you can use this small shell script: | 你可以使用下面这个脚本方便地重启Unix里的FastCGI守护进程： | 翻译 | ||
| 359#翻译 | Using Django with Apache and FastCGI | 在Apache中以FastCGI的方式使用Django | 翻译 | ||
| 361#翻译 | To use Django with Apache and FastCGI, you'll need Apache installed and configured, with mod_fastcgi installed and enabled. | 在Apache和FastCGI上使用Django，你需要安装和配置Apache，并且启用mod_fastcgi。 | 翻译 | ||
| 362#翻译 | Consult the Apache and mod_fastcgi documentation for instructions: | 请参见Apache和mod_fastcgi文档： | 翻译 | ||
| 363#翻译 | <reference name="http://www.djangoproject.com/r/mod_fastcgi/" refuri="http://www.djangoproject.com/r/mod_fastcgi/">http://www.djangoproject.com/r/mod_fastcgi/</reference>. | <reference name="http://www.djangoproject.com/r/mod_fastcgi/" refuri="http://www.djangoproject.com/r/mod_fastcgi/">http://www.djangoproject.com/r/mod_fastcgi/</reference> 。 | 翻译 | ||
| 365#翻译 | Once you've completed the setup, point Apache at your Django FastCGI instance by editing the <literal>httpd.conf</literal> (Apache configuration) file. | 当完成了安装，通过 <literal>httpd.conf</literal> （Apache的配置文件）来让Apache和Django FastCGI互相通信。 | 翻译 | ||
| 366#翻译 | You'll need to do two things: | 你需要做两件事： | 翻译 | ||
| 368#翻译 | Use the <literal>FastCGIExternalServer</literal> directive to specify the location of your FastCGI server. | 使用 <literal>FastCGIExternalServer</literal> 指明FastCGI的位置。 | 翻译 | ||
| 370#翻译 | Use <literal>mod_rewrite</literal> to point URLs at FastCGI as appropriate. | 使用 <literal>mod_rewrite</literal> 为FastCGI指定合适的URL。 | 翻译 | ||
| 372#翻译 | Specifying the Location of the FastCGI Server | 指定 FastCGI Server 的位置 | 翻译 | ||
| 374#翻译 | The <literal>FastCGIExternalServer</literal> directive tells Apache how to find your FastCGI server. | <literal>FastCGIExternalServer</literal> 告诉Apache如何找到FastCGI服务器。 | 翻译 | ||
| 375#翻译 | As the FastCGIExternalServer docs (<reference name="http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/" refuri="http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/">http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/</reference>) explain, you can specify either a <literal>socket</literal> or a <literal>host</literal> . Here are examples of both: | 按照FastCGIExternalServer 文档（ <reference name="http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/" refuri="http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/">http://www.djangoproject.com/r/mod_fastcgi/FastCGIExternalServer/</reference> ），你可以指明 <literal>socket</literal> 或者 <literal>host</literal> 。以下是两个例子： | 翻译 | ||
| 378#翻译 | In either case, the the directory /home/user/public_html/ should exist, though the file <literal>/home/user/public_html/mysite.fcgi</literal> doesn't actually have to exist. | 在这两个例子中， /home/user/public_html/ 目录必须存在，而 <literal>/home/user/public_html/mysite.fcgi</literal> 文件不一定存在。 | 翻译 | ||
| 379#翻译 | It's just a URL used by the Web server internally a hook for signifying which requests at a URL should be handled by FastCGI. | 它仅仅是一个Web服务器内部使用的接口，这个URL决定了哪些URL请求会被FastCGI处理（下一部分详细讨论）。 | 翻译 | ||
| 380#翻译 | (More on this in the next section.) | （下一章将会有更多有关于此的介绍） | 翻译 | ||
| 382#翻译 | Using mod_rewrite to Point URLs at FastCGI | 使用mod_rewrite为FastCGI指定URL | 翻译 | ||
| 384#翻译 | The second step is telling Apache to use FastCGI for URLs that match a certain pattern. | 第二步是告诉Apache为符合一定模式的URL使用FastCGI。 | 翻译 | ||
| 385#翻译 | To do this, use the mod_rewrite module and rewrite URLs to <literal>mysite.fcgi</literal> (or whatever you specified in the <literal>FastCGIExternalServer</literal> directive, as explained in the previous section). | 为了实现这一点，请使用mod_rewrite 模块，并将这些URL重定向到 <literal>mysite.fcgi</literal> （或者正如在前文中描述的那样，使用任何在 <literal>FastCGIExternalServer</literal> 指定的内容）。 | 翻译 | ||
| 387#翻译 | In this example, we tell Apache to use FastCGI to handle any request that doesn't represent a file on the filesystem and doesn't start with <literal>/media/</literal> . This is probably the most common case, if you're using Djangos admin site: | 在这个例子里面，我们告诉Apache使用FastCGI来处理那些不针对文件系统上的文件以及不以<literal>/media/</literal>开头的请求。这可能是使用Django管理站点的最普遍情况了。 | 翻译 | ||
| 390#翻译 | FastCGI and lighttpd | FastCGI 和 lighttpd | 翻译 | ||
| 392#翻译 | lighttpd (<reference name="http://www.djangoproject.com/r/lighttpd/" refuri="http://www.djangoproject.com/r/lighttpd/">http://www.djangoproject.com/r/lighttpd/</reference>) is a lightweight Web server commonly used for serving static files. | lighttpd (<reference name="http://www.djangoproject.com/r/lighttpd/" refuri="http://www.djangoproject.com/r/lighttpd/">http://www.djangoproject.com/r/lighttpd/</reference>) 是一个轻量级的Web服务器，通常被用来提供静态页面的访问。 | 翻译 | ||
| 393#翻译 | It supports FastCGI natively and thus is also an ideal choice for serving both static and dynamic pages, if your site doesn't have any Apache-specific needs. | 它天生支持FastCGI，因此除非你的站点需要一些Apache特有的特性，否则，lighttpd对于静态和动态页面来说都是理想的选择。 | 翻译 | ||
| 395#翻译 | Make sure <literal>mod_fastcgi</literal> is in your modules list, somewhere after <literal>mod_rewrite</literal> and <literal>mod_access</literal> , but not after <literal>mod_accesslog</literal> . You'll probably want <literal>mod_alias</literal> as well, for serving admin media. | 确保 <literal>mod_fastcgi</literal> 在模块列表中，它需要出现在 <literal>mod_rewrite</literal> 和 <literal>mod_access</literal> ，但是要在 <literal>mod_accesslog</literal> 之前。有可能也想使用<literal>mod_alias</literal>来提供媒体管理。 | 翻译 | ||
| 397#翻译 | Add the following to your lighttpd config file: | 将下面的内容添加到你的lighttpd的配置文件中： | 翻译 | ||
| 400#翻译 | Running Multiple Django Sites on One lighttpd Instance | 在一个lighttpd进程中运行多个Django站点 | 翻译 | ||
| 402#翻译 | lighttpd lets you use conditional configuration to allow configuration to be customized per host. | lighttpd允许你使用条件配置来为每个站点分别提供设置。 | 翻译 | ||
| 403#翻译 | To specify multiple FastCGI sites, just add a conditional block around your FastCGI config for each site: | 为了支持FastCGI的多站点，只需要在FastCGI的配置文件中，为每个站点分别建立条件配置项： | 翻译 | ||
| 406#翻译 | You can also run multiple Django installations on the same site simply by specifying multiple entries in the <literal>fastcgi.server</literal> directive. | 你也可以通过 <literal>fastcgi.server</literal> 中指定多个入口，在同一个站点上实现运行多个Django应用。 | 翻译 | ||
| 407#翻译 | Add one FastCGI host for each. | 请为每一个安装指定一个FastCGI主机。 | 翻译 | ||
| 409#翻译 | Running Django on a Shared-Hosting Provider with Apache | 在使用Apache的共享主机服务商处运行Django。 | 翻译 | ||
| 411#翻译 | Many shared-hosting providers don't allow you to run your own server daemons or edit the <literal>httpd.conf</literal> file. | 许多共享主机的服务提供商不允许运行你自己的服务进程，也不允许修改 <literal>httpd.conf</literal> 文件。 | 翻译 | ||
| 412#翻译 | In these cases, it's still possible to run Django using Web server-spawned processes. | 尽管如此，仍然有可能通过Web服务器产生的子进程来运行Django。 | 翻译 | ||
| 414#翻译 | Note | 注意 | 翻译 | ||
| 416#翻译 | If you're using Web server-spawned processes, as explained in this section, there's no need for you to start the FastCGI server on your own. | 如果你要使用服务器的子进程，你没有必要自己去启动FastCGI服务器。 | 翻译 | ||
| 417#翻译 | Apache will spawn a number of processes, scaling as it needs to. | Apache会自动产生一些子进程，产生的数量按照需求和配置会有所不同。 | 翻译 | ||
| 419#翻译 | In your Web root directory, add this to a file named <literal>.htaccess</literal> | 在你的Web根目录下，将下面的内容增加到 <literal>.htaccess</literal> 文件中： | 翻译 | ||
| 422#翻译 | Then, create a small script that tells Apache how to spawn your FastCGI program. | 接着，创建一个脚本，告知Apache如何运行你的FastCGI程序。 | 翻译 | ||
| 423#翻译 | Create a file, <literal>mysite.fcgi</literal> , and place it in your Web directory, and be sure to make it executable | 创建一个 <literal>mysite.fcgi</literal> 文件，并把它放在你的Web目录中，打开可执行权限。 | 翻译 | ||
| 426#翻译 | Restarting the Spawned Server | 重启新产生的进程服务器 | 翻译 | ||
| 428#翻译 | If you change any Python code on your site, you'll need to tell FastCGI the code has changed. | 如果你改变了站点上任何的Python代码，你需要告知FastCGI。 | 翻译 | ||
| 429#翻译 | But there's no need to restart Apache in this case. | 但是，这不需要重启Apache。 | 翻译 | ||
| 430#翻译 | Rather, just reupload <literal>mysite.fcgi</literal> or edit the file so that the timestamp on the file changes. | 而只需要重新上传<literal>mysite.fcgi</literal>或者编辑改文件，使得修改时间发生了变化。 | 翻译 | ||
| 431#翻译 | When Apache sees the file has been updated, it will restart your Django application for you. | 当Apache服务器发现文件被更新了，它会自动为你重启Django应用。 | 翻译 | ||
| 433#翻译 | If you have access to a command shell on a Unix system, you can accomplish this easily by using the <literal>touch</literal> command: | 如果你拥有Unix系统命令行的可执行权限，只需要简单地使用 <literal>touch</literal> 命令： | 翻译 | ||
| 436#翻译 | Scaling | 可扩展性 | 翻译 | ||
| 438#翻译 | Now that you know how to get Django running on a single server, let's look at how you can scale out a Django installation. | 既然你已经知道如何在一台服务器上运行Django，让我们来研究一下，如何扩展我们的Django安装。 | 翻译 | ||
| 439#翻译 | 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. | 这一部分我们将讨论，如何把一台服务器扩展为一个大规模的服务器集群，这样就能满足每小时上百万的点击率。 | 翻译 | ||
| 441#翻译 | It's 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. | 有一点很重要，每一个大型的站点大的形式和规模不同，因此可扩展性其实并不是一种千篇一律的行为。 | 翻译 | ||
| 442#翻译 | The following coverage should suffice to show the general principle, and whenever possible we'll try to point out where different choices could be made. | 以下部分会涉及到一些通用的原则，并且会指出一些不同选择。 | 翻译 | ||
| 444#翻译 | First off, we'll make a pretty big assumption and exclusively talk about scaling under Apache and mod_python. | 首先，我们来做一个大的假设，只集中地讨论在Apache和mod_python下的可扩展性问题。 | 翻译 | ||
| 445#翻译 | Though we know of a number of successful medium- to large-scale FastCGI deployments, we're much more familiar with Apache. | 尽管我们也知道一些成功的中型和大型的FastCGI策略，但是我们更加熟悉Apache。 | 翻译 | ||
| 447#翻译 | Running on a Single Server | 运行在一台单机服务器上 | 翻译 | ||
| 449#翻译 | Most sites start out running on a single server, with an architecture that looks something like Figure 12-1. | 大多数的站点一开始都运行在单机服务器上，看起来像图12-1这样的构架。 | 翻译 | ||
| 451#翻译 | <image alt="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-1.png" uri="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-1.png"/><cnid>205 | <image alt="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png" uri="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png"/><cnid>198 | 翻译 | ||
| 452#翻译 | Figure 12-1: | 图 12-1： | 翻译 | ||
| 453#翻译 | a single server Django setup. | 一个单服务器的Django安装。 | 翻译 | ||
| 455#翻译 | This works just fine for small- to medium-sized sites, and it's relatively cheap you can put together a single-server site designed for Django for well under $3,000. | 这对于小型和中型的站点来说还不错，并且也很便宜，一般来说，你可以在3000美元以下就搞定一切。 | 翻译 | ||
| 457#翻译 | However, as traffic increases you'll quickly run into <emphasis>resource contention</emphasis> between the different pieces of software. | 然而，当流量增加的时候，你会迅速陷入不同软件的 <emphasis>资源争夺</emphasis> 之中。 | 翻译 | ||
| 458#翻译 | Database servers and Web servers <emphasis>love</emphasis> 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 they'd prefer to monopolize. | 数据库服务器和Web服务器都 <emphasis>喜欢</emphasis> 自己拥有整个服务器资源，因此当被安装在单机上时，它们总会争夺相同的资源（RAM, CPU），它们更愿意独享资源。 | 翻译 | ||
| 460#翻译 | This is solved easily by moving the database server to a second machine, as explained in the following section. | 通过把数据库服务器迁移到第二台主机上，可以很容易地解决这个问题。 | 翻译 | ||
| 462#翻译 | Separating Out the Database Server | 分离出数据库服务器 | 翻译 | ||
| 464#翻译 | As far as Django is concerned, the process of separating out the database server is extremely easy: | 对于Django来说，把数据库服务器分离开来很容易： | 翻译 | ||
| 465#翻译 | you'll simply need to change the <literal>DATABASE_HOST</literal> setting to the IP or DNS name of your database server. | 只需要简单地修改 <literal>DATABASE_HOST</literal> ，设置为新的数据库服务器的IP地址或者DNS域名。 | 翻译 | ||
| 466#翻译 | It's 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 isn't recommended. | 设置为IP地址总是一个好主意，因为使用DNS域名，还要牵涉到DNS服务器的可靠性连接问题。 | 翻译 | ||
| 468#翻译 | With a separate database server, our architecture now looks like Figure 12-2. | 使用了一个独立的数据库服务器以后，我们的构架变成了图12-2。 | 翻译 | ||
| 470#翻译 | <image alt="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-2.png" uri="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-2.png"/><cnid>213 | <image alt="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png" uri="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png"/><cnid>207 | 翻译 | ||
| 471#翻译 | Figure 12-2: | 图 20-2： | 翻译 | ||
| 472#翻译 | Moving the database onto a dedicated server. | 将数据库移到单独的服务器上。 | 翻译 | ||
| 474#翻译 | Here we're starting to move into what's usually called <emphasis>n-tier</emphasis> architecture. | 这里，我们开始步入 <emphasis>n-tier</emphasis> 构架。 | 翻译 | ||
| 475#翻译 | Don't 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. | 不要被这个词所吓坏，它只是说明了Web栈的不同部分，被分离到了不同的物理机器上。 | 翻译 | ||
| 477#翻译 | At this point, if you anticipate ever needing to grow beyond a single database server, it's probably a good idea to start thinking about connection pooling and/or database replication. | 我们再来看，如果发现需要不止一台的数据库服务器，考虑使用连接池和数据库备份将是一个好主意。 | 翻译 | ||
| 478#翻译 | Unfortunately, there's not nearly enough space to do those topics justice in this book, so you'll need to consult your databases documentation and/or community for more information. | 不幸的是，本书没有足够的时间来讨论这个问题，所以你参考数据库文档或者向社区求助。 | 翻译 | ||
| 480#翻译 | Running a Separate Media Server | 运行一个独立的媒体服务器 | 翻译 | ||
| 482#翻译 | We still have a big problem left over from the single-server setup: | 使用单机服务器仍然留下了一个大问题： | 翻译 | ||
| 483#翻译 | the serving of media from the same box that handles dynamic content. | 处理动态内容的媒体资源，也是在同一台机器上完成的。 | 翻译 | ||
| 485#翻译 | 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. | 这两个活动是在不同的条件下进行的，因此把它们强行凑和在同一台机器上，你不可能获得很好的性能。 | 翻译 | ||
| 486#翻译 | So the next step is to separate out the media that is, anything <emphasis>not</emphasis> generated by a Django view onto a dedicated server (see Figure 12-3). | 下一步，我们要把媒体资源（任何 <emphasis>不是</emphasis> 由Django视图产生的东西）分离到别的服务器上（请看图12-3）。 | 翻译 | ||
| 488#翻译 | <image alt="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-3.png" uri="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-3.png"/><cnid>220 | <image alt="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png" uri="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png"/><cnid>215 | 翻译 | ||
| 489#翻译 | Figure 12-3: | 图 12-3： | 翻译 | ||
| 490#翻译 | Separating out the media server. | 分离出媒体服务器。 | 翻译 | ||
| 492#翻译 | Ideally, this media server should run a stripped-down Web server optimized for static media delivery. | 理想的情况是，这个媒体服务器是一个定制的Web服务器，为传送静态媒体资源做了优化。 | 翻译 | ||
| 493#翻译 | lighttpd and tux (<reference name="http://www.djangoproject.com/r/tux/" refuri="http://www.djangoproject.com/r/tux/">http://www.djangoproject.com/r/tux/</reference>) are both excellent choices here, but a heavily stripped down Apache could work, too. | lighttpd和tux (<reference name="http://www.djangoproject.com/r/tux/" refuri="http://www.djangoproject.com/r/tux/">http://www.djangoproject.com/r/tux/</reference>) 都是极佳的选择，当然瘦身的Apache服务器也可以工作的很好。 | 翻译 | ||
| 495#翻译 | For sites heavy in static content (photos, videos, etc.), moving to a separate media server is doubly important and should likely be the <emphasis>first</emphasis> step in scaling up. | 对于拥有大量静态内容（照片、视频等）的站点来说，将媒体服务器分离出去显然有着更加重要的意义，而且应该是扩大规模的时候所要采取的 <emphasis>第一</emphasis>步措施 。 | 翻译 | ||
| 497#翻译 | This step can be slightly tricky, however. | 这一步需要一点点技巧。 | 翻译 | ||
| 498#翻译 | If your application involves file uploads, Django needs to be able to write uploaded media to the media server. | 如果你的应用牵涉到文件上载，Django需要能够向媒体服务器写入上载媒体。 | 翻译 | ||
| 499#翻译 | If media lives on another server, you'll need to arrange a way for that write to happen across the network. | 如果媒体是在另外一台服务器上的，你需要部署一种方法使得Django可以通过网络去写这些媒体。 | 翻译 | ||
| 501#翻译 | Implementing Load Balancing and Redundancy | 实现负担均衡和数据冗余备份 | 翻译 | ||
| 503#翻译 | At this point, we've broken things down as much as possible. | 现在，我们已经尽可能地进行了分解。 | 翻译 | ||
| 504#翻译 | 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, you'll need to start adding redundancy. | 这种三台服务器的构架可以承受很大的流量，比如每天1000万的点击率。如果还想再进一步的话，就需要数据冗余了。 | 翻译 | ||
| 506#翻译 | This is a good thing, actually. | 这是个好主意。 | 翻译 | ||
| 507#翻译 | One glance at Figure 12-3 shows you that if even a single one of your three servers fails, you'll bring down your entire site. | 请看图 12-3，一旦三个服务器中的任何一个发生了故障，你就得关闭整个站点。 | 翻译 | ||
| 508#翻译 | So as you add redundant servers, not only do you increase capacity, but you also increase reliability. | 因此在引入冗余备份的时候，你并不只是增加了容量，同时也增加了可靠性。 | 翻译 | ||
| 510#翻译 | For the sake of this example, let's assume that the Web server hits capacity first. | 我们首先来考虑Web服务器的点击量。 | 翻译 | ||
| 511#翻译 | It's relatively 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. | 在多台机器上同时运行多份Django站点的拷贝很容易，我们只需要拷贝多份代码到多台机器上，然后为每台计算机都启动Apache服务器。 | 翻译 | ||
| 513#翻译 | However, you'll need another piece of software to distribute traffic over your multiple servers: | 你还需要另一个软件来帮助你在多台服务器之间均衡网络流量： | 翻译 | ||
| 514#翻译 | a <emphasis>load balancer</emphasis> . You can buy expensive and proprietary hardware load balancers, but there are a few high-quality open source software load balancers out there. | <emphasis>流量均衡器（load balancer）</emphasis> 。你可以购买昂贵的专有的硬件均衡器，当然也有一些高质量的开源的软件均衡器可供选择。 | 翻译 | ||
| 516#翻译 | Apache's <literal>mod_proxy</literal> is one option, but we've found Perlbal (<reference name="http://www.djangoproject.com/r/perlbal/" refuri="http://www.djangoproject.com/r/perlbal/">http://www.djangoproject.com/r/perlbal/</reference>) to be fantastic. | Apaches 的 <literal>mod_proxy</literal> 是一个可以考虑的选择，但另一个更理想的选择是Perbal(<reference name="http://www.djangoproject.com/r/perlbal/" refuri="http://www.djangoproject.com/r/perlbal/">http://www.djangoproject.com/r/perlbal/</reference>)： | 翻译 | ||
| 517#翻译 | It's a load balancer and reverse proxy written by the same folks who wrote <literal>memcached</literal> (see <reference name="Chapter 15" refuri="../chapter15/">Chapter 15</reference>). | 它是一个负载均衡和反向代理的程序，是由编写<literal>memcached</literal>的团队开发的(见第15章)。 | 翻译 | ||
| 519#翻译 | Note | 注意 | 翻译 | ||
| 521#翻译 | If you're 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. | 如果你使用FastCGI，你可以采用分离前台的Web服务器，并在其他多台机器上运行FastCGI服务器的方式来实现相同的负载均衡的功能。 | 翻译 | ||
| 522#翻译 | The front-end server essentially becomes the load balancer, and the back-end FastCGI processes replace the Apache/mod_python/Django servers. | 前台的服务器就相当于是一个均衡器，而后台的FastCGI服务进程代替了Apache/mod_python/Django服务器。 | 翻译 | ||
| 524#翻译 | With the Web servers now clustered, our evolving architecture starts to look more complex, as shown in Figure 12-4. | 现在我们拥有了服务器集群，我们的构架慢慢演化，越来越复杂，如图12-4。 | 翻译 | ||
| 526#翻译 | <image alt="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-4.png" uri="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-4.png"/><cnid>234 | <image alt="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-4.png" uri="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-4.png"/><cnid>231 | 翻译 | ||
| 527#翻译 | Figure 12-4: | 图 12-4： | 翻译 | ||
| 528#翻译 | A load-balanced, redundant server setup. | 负载均衡的服务器设置。 | 翻译 | ||
| 530#翻译 | Notice that in the diagram the Web servers are referred to as a cluster to indicate that the number of servers is basically variable. | 值得一提的是，在图中，Web服务器指的是一个集群，来表示许多数量的服务器。 | 翻译 | ||
| 531#翻译 | Once you have a load balancer out front, you can easily add and remove back-end Web servers without a second of downtime. | 一旦你拥有了一个前台的均衡器，你就可以很方便地增加和删除后台的Web服务器，而且不会造成任何网站不可用的时间。 | 翻译 | ||
| 533#翻译 | Going Big | 慢慢变大 | 翻译 | ||
| 535#翻译 | At this point, the next few steps are pretty much derivatives of the last one: | 下面的这些步骤都是上面最后一个的变体： | 翻译 | ||
| 537#翻译 | As you need more database performance, you might want to add replicated database servers. | 当你需要更好的数据库性能，你可能需要增加数据库的冗余服务器。 | 翻译 | ||
| 538#翻译 | MySQL includes built-in replication; PostgreSQL users should look into Slony (<reference name="http://www.djangoproject.com/r/slony/" refuri="http://www.djangoproject.com/r/slony/">http://www.djangoproject.com/r/slony/</reference>) and pgpool (<reference name="http://www.djangoproject.com/r/pgpool/" refuri="http://www.djangoproject.com/r/pgpool/">http://www.djangoproject.com/r/pgpool/</reference>) for replication and connection pooling, respectively. | MySQL内置了备份功能；PostgreSQL应该看一下Slony (<reference name="http://www.djangoproject.com/r/slony/" refuri="http://www.djangoproject.com/r/slony/">http://www.djangoproject.com/r/slony/</reference>) 和 pgpool (<reference name="http://www.djangoproject.com/r/pgpool/" refuri="http://www.djangoproject.com/r/pgpool/">http://www.djangoproject.com/r/pgpool/</reference>) ，这两个分别是数据库备份和连接池的工具。 | 翻译 | ||
| 540#翻译 | If the single load balancer isn't enough, you can add more load balancer machines out front and distribute among them using round-robin DNS. | 如果单个均衡器不能达到要求，你可以增加更多的均衡器，并且使用轮询（round-robin）DNS来实现分布访问。 | 翻译 | ||
| 542#翻译 | If a single media server doesn't suffice, you can add more media servers and distribute the load with your load-balancing cluster. | 如果单台媒体服务器不够用，你可以增加更多的媒体服务器，并通过集群来分布流量。 | 翻译 | ||
| 544#翻译 | If you need more cache storage, you can add dedicated cache servers. | 如果你需要更多的高速缓存（cache），你可以增加cache服务器。 | 翻译 | ||
| 546#翻译 | At any stage, if a cluster isn't performing well, you can add more servers to the cluster. | 在任何情况下，只要集群工作性能不好，你都可以往上增加服务器。 | 翻译 | ||
| 548#翻译 | After a few of these iterations, a large-scale architecture might look like Figure 12-5. | 重复了几次以后，一个大规模的构架会像图12-5。 | 翻译 | ||
| 550#翻译 | <image alt="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-5.png" uri="http://new-media.djangobook.com/content/en/2.0/chapter12/scaling-5.png"/><cnid>245 | <image alt="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-5.png" uri="http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-5.png"/><cnid>243 | 翻译 | ||
| 551#翻译 | Figure 12-5. | 图 12-5。 | 翻译 | ||
| 552#翻译 | An example large-scale Django setup. | 大规模的Django安装。 | 翻译 | ||
| 554#翻译 | Though we've shown only two or three servers at each level, there's no fundamental limit to how many you can add. | 尽管我们只是在每一层上展示了两到三台服务器，你可以在上面随意地增加更多。 | 翻译 | ||
| 556#翻译 | Performance Tuning | 性能优化 | 翻译 | ||
| 558#翻译 | If you have huge amount of money, you can just keep throwing hardware at scaling problems. | 如果你有大笔大笔的钱，遇到扩展性问题时，你可以简单地投资硬件。 | 翻译 | ||
| 559#翻译 | For the rest of us, though, performance tuning is a must. | 对于剩下的人来说，性能优化就是必须要做的一件事。 | 翻译 | ||
| 561#翻译 | Note | 注意 | 翻译 | ||
| 563#翻译 | Incidentally, if anyone with monstrous gobs of cash is actually reading this book, please consider a substantial donation to the Django Foundation. | 顺便提一句，谁要是有大笔大笔的钞票，请捐助一点给Django项目。 | 翻译 | ||
| 564#翻译 | We accept uncut diamonds and gold ingots, too. | 我们也接受未切割的钻石和金币。 | 翻译 | ||
| 566#翻译 | Unfortunately, performance tuning is much more of an art than a science, and it is even more difficult to write about than scaling. | 不幸的是，性能优化比起科学来说更像是一种艺术，并且这比扩展性更难描述。 | 翻译 | ||
| 567#翻译 | If you're 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应用，你需要花大量的时间和精力学习如何优化构架中的每一部分。 | 翻译 | ||
| 569#翻译 | The following sections, though, present a few Django-specific tuning tips we've discovered over the years. | 以下部分总结了多年以来的经验，是一些专属于Django的优化技巧。 | 翻译 | ||
| 571#翻译 | There's No Such Thing As Too Much RAM | RAM怎么也不嫌多 | 翻译 | ||
| 573#翻译 | Even the really expensive RAM is relatively affordable these days. | 最近，即使那些昂贵的RAM也相对来说可以负担的起了。 | 翻译 | ||
| 574#翻译 | Buy as much RAM as you can possibly afford, and then buy a little bit more. | 购买尽可能多的RAM，再在别的上面投资一点点。 | 翻译 | ||
| 576#翻译 | Faster processors won't improve performance all that much; most Web servers spend up to 90% of their time waiting on disk I/O. | 高速的处理器并不会大幅度地提高性能；大多数的Web服务器90%的时间都浪费在了硬盘IO上。 | 翻译 | ||
| 577#翻译 | As soon as you start swapping, performance will just die. | 当硬盘上的数据开始交换，性能就急剧下降。 | 翻译 | ||
| 578#翻译 | Faster disks might help slightly, but they're much more expensive than RAM, such that it doesn't really matter. | 更快速的硬盘可以稍微改善这个问题，但是比起RAM来说，那太贵了。 | 翻译 | ||
| 580#翻译 | If you have multiple servers, the first place to put your RAM is in the database server. | 如果你拥有多台服务器，首要的是要在数据库服务器上增加内存。 | 翻译 | ||
| 581#翻译 | If you can afford it, get enough RAM to get fit your entire database into memory. | 如果你能负担得起，把你整个数据库都放入到内存中。 | 翻译 | ||
| 582#翻译 | This shouldn't be too hard; weve developed a site with more than half a million newspaper articles, and it took under 2GB of space. | 这应该不是很困难，我们已经开发过一个站点上面有多于一百万条报刊文章，这个站点使用了不到2GB的空间。 | 翻译 | ||
| 584#翻译 | Next, max out the RAM on your Web server. | 下一步，最大化Web服务器上的内存。 | 翻译 | ||
| 585#翻译 | The ideal situation is one where neither server swaps ever. | 最理想的情况是，没有一台服务器进行磁盘交换。 | 翻译 | ||
| 586#翻译 | If you get to that point, you should be able to withstand most normal traffic. | 如果你达到了这个水平，你就能应付大多数正常的流量。 | 翻译 | ||
| 588#翻译 | Turn Off Keep-Alive | 禁用 Keep-Alive | 翻译 | ||
| 590#翻译 | <literal>Keep-Alive</literal> is a feature of HTTP that allows multiple HTTP requests to be served over a single TCP connection, avoiding the TCP setup/teardown overhead. | <literal>Keep-Alive</literal> 是HTTP提供的功能之一，它的目的是允许多个HTTP请求复用一个TCP连接，也就是允许在同一个TCP连接上发起多个HTTP请求，这样有效的避免了每个HTTP请求都重新建立自己的TCP连接的开销。 | 翻译 | ||
| 592#翻译 | This looks good at first glance, but it can kill the performance of a Django site. | 这一眼看上去是好事，但它足以眼中影响Django站点的性能。 | 翻译 | ||
| 593#翻译 | If you're 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. | 如果你从单独的媒体服务器上向用户提供服务，每个光顾你站点的用户只会大约10秒钟左右发出一次请求。 | 翻译 | ||
| 594#翻译 | 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. | 这就使得HTTP服务器一直在等待下一次keep-alive 的请求，空闲的HTTP服务器和工作时消耗一样多的内存。 | 翻译 | ||
| 596#翻译 | Use memcached | 使用 memcached | 翻译 | ||
| 598#翻译 | Although Django supports a number of different cache back-ends, none of them even come <emphasis>close</emphasis> to being as fast as memcached. | 尽管Django支持多种不同的cache后台机制，没有一种的性能可以 <emphasis>接近</emphasis> memcached。 | 翻译 | ||
| 599#翻译 | If you have a high-traffic site, don't even bother with the other backends go straight to memcached. | 如果你有一个高流量的站点，不要犹豫，直接选择memcached。 | 翻译 | ||
| 601#翻译 | Use memcached Often | 经常使用memcached | 翻译 | ||
| 603#翻译 | Of course, selecting memcached does you no good if you don't actually use it. | 当然，选择了memcached而不去使用它，你不会从中获得任何性能上的提升。 | 翻译 | ||
| 604#翻译 | <reference name="Chapter 15" refuri="../chapter15/">Chapter 15</reference> is your best friend here: | 可以参考<reference name="Chapter 15" refuri="../chapter15/">第十五章</reference> | 翻译 | ||
| 605#翻译 | learn how to use Django's cache framework, and use it everywhere possible. | 学习如何使用Django的cache框架，并且尽可能地使用它。 | 翻译 | ||
| 606#翻译 | Aggressive, preemptive caching is usually the only thing that will keep a site up under major traffic. | 大量的可抢占式的高速缓存通常是一个站点在大流量下正常工作的唯一方法。 | 翻译 | ||
| 608#翻译 | Join the Conversation | 参加讨论 | 翻译 | ||
| 610#翻译 | Each piece of the Django stack from Linux to Apache to PostgreSQL or MySQL has an awesome community behind it. | Django相关的每一个部分，从Linux到Apache到PostgreSQL或者MySQL背后，都有一个非常棒的社区支持。 | 翻译 | ||
| 611#翻译 | 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. | 如果你真想从你的服务器上榨干最后1%的性能，加入开源社区寻求帮助。 | 翻译 | ||
| 612#翻译 | Most free-software community members will be happy to help. | 多数的自由软件社区成员都会很乐意地提供帮助。 | 翻译 | ||
| 614#翻译 | And also be sure to join the Django community. | 别忘了Django社区。 | 翻译 | ||
| 615#翻译 | Your humble authors are only two members of an incredibly active, growing group of Django developers. | 这本书谦逊的作者只是不断增长着Django开发团队中的两位成员。 | 翻译 | ||
| 616#翻译 | Our community has a huge amount of collective experience to offer. | 我们的社区有大量的经验可以提供。 | 翻译 | ||
| 618#翻译 | What's Next? | 接下来做什么？ | 翻译 | ||
| 620#翻译 | The remaining chapters focus on other Django features that you may or may not need, depending on your application. | 下面的章节集中在其他的一些Django特性上，你是否需要它们取决于你的应用项目。 | 翻译 | ||
| 621#翻译 | Feel free to read them in any order you choose. | 可以自由选择阅读。 | 翻译 |