Содержание


Разворачиваем приложения Django на production-сервере

Comments

Django

Django – это инфраструктура Web-разработки с открытым исходным кодом, написанная на языке Python. Она предназначена для автоматизации как можно большего количества процессов, чтобы можно было сконцентрироваться на разработке ПО не отвлекаясь на изобретение очередного «колеса». В Django изначально закладывалась нежесткая связанность различных частей инфраструктуры, чтобы с ними можно было работать независимо друг от друга. Эта независимость означает, что можно использовать только части Django, которые вам нужны, не заботясь о проблемах взаимозависимости компонентов.

Использование Django сокращает количество необходимого кода, что делает написание Web-приложений более быстрым и существенно облегчает поддержку приложения в будущем. Django строго следует принципу DRY (не повторяйся – Don't Repeat Yourself), согласно которому каждый отдельный кусок кода или данных должен храниться только в одном месте. Это намного упрощает и ускоряет процесс изменения ПО, так как если в приложение потребуется внести изменение, его нужно будет сделать в единственном месте.

Инфраструктура Django была создана командой Web-разработчиков, работавших в газете Lawrence Journal-World в 2003 году. Под давлением жестких временных рамок при разработке и расширении приложений, они решили создать инфраструктуру Web-разработки, которая бы сохраняла им время и позволяла укладываться в жесткие сроки. Инфраструктура Django была выпущена как проект с открытым кодом в июле 2005 года, и сейчас ее разработкой занимается сообщество из тысяч программистов по всему миру.

Инфраструктура Django распространяется под открытой лицензией BSD (Berkeley Software Distribution), которая разрешает распространение и использование исходного кода и исполняемых файлов с изменениями или без них, если в распространяемом пакете присутствует информация об авторских правах, условиях лицензии и отказе от ответственности. Если применимо, эта информация также должна быть представлена в документации и дополнительных материалах распространяемого ПО. Также лицензия оговаривает, что ни название Django, ни имена разработчиков Django не могут быть использованы для продвижения продуктов без получения письменного одобрения.

Настраиваем окружение разработки Django

К счастью, процесс установки Django довольно прямолинеен, поэтому настроить среду разработки можно быстро и просто. Django написана целиком на Python, поэтому, чтобы ее установить, нужно сначала установить Python. Если вы используете Mac OS X или Linux®, то вполне возможно, что Python уже установлен на вашей машине. Набрав в командной строке python (используйте приложение Terminal.app на Mac), вы должны увидеть примерно то же, что показано в листинге 1.

Листинг 1. Убеждаемся, что Python установлен
$ python
Python 2.5.1 (r251:54863, Nov 11 2008, 17:46:48) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Listing 1 - Checking for Python on Mac OS X

Django может быть установлена при наличии Python версии от 2.3 до 2.6. Если у вас ОС от Microsoft® Windows® или вам нужно обновиться до более новой версии, загрузите Python по этой ссылке. Для пользователей Windows имеется простой установочный пакет, поэтому установка Python проходит легко.

Убедившись, что на вашей машине установлен Python, можно приступать к установке Django. Имеется три варианта: установить официальный релиз Django, воспользоваться установочным пакетом, специфичным для определенного дистрибутива, или установить последнюю находящуюся в разработке инженерную (trunk) версию из Subversion. В данной статье мы рассмотрим только установку официального релиза. С инструкциями по установке инженерной версии можно ознакомиться в официальной документации (см. раздел Ресурсы).

Первым шагом установки официального релиза Django является загрузка tar-архива с установочным пакетом с сайта Django. После загрузки извлеките его содержимое. В Linux просто выполните следующую команду в сеансе оболочки (убедитесь, что вы находитесь в директории, куда был загружен этот пакет). На момент написания статьи версия 1.0.2 являлась последней официальной версией, поэтому при необходимости замените имя файла в этой команде точным именем пакета, который вы загрузили: tar zxvf Django-1.0.2-final.tar.gz.

В Mac OS X, скорее всего, Web-браузер по окончании загрузки автоматически разархивирует пакет, поэтому файл будет называться Django-1.0.2-final.tar. Чтобы извлечь этот файл, воспользуйтесь следующей командой: tar xvf Django-1.0.2-final.tar. В Windows для извлечения архива можно воспользоваться такой утилитой, как 7-Zip.

После извлечения содержимого tar-архива в некоторую директорию (вероятно, с именем Django-1.0.2-final), перейдите в эту директорию в командной строке. Для установки Django выполните следующую команду (на Mac OS X или Linux): sudo python setup.py install. При работе в Windows убедитесь, что ваша командная строка открыта с привилегиями администратора и выполните команду: setup.py install.

В результате Django будет установлена в папку, где хранятся сторонние установочные пакеты Python, после чего можно приступать к разработке на Django. Перед тем как приступить к изучению анатомии приложения Django, убедимся, что наша среда разработки правильно работает. Сначала проверим, что Django установлена правильно. Запустите интерпретатор Python, выполнив в командной строке команду python. Теперь выполним в интерпретаторе Python команды, показанные в листинге 2 (набирать >>> не надо):

Листинг 2. Проверяем, что Django установлена правильно
>>> import django
>>> django.VERSION

Если установка прошла успешно, вы увидите текст, показанный в листинге 3.

Листинг 3. Django успешно установлена
(1, 0, 2, 'final', 0)
>>>

Теперь, когда мы проверили, что Django установлена, проверим работу сервера разработки. Чтобы это сделать, нам нужно создать новый проект. Создайте директорию для хранения проектов Django (на моей системе Mac OS X она называется /home/joe/django) и переместитесь в нее. Находясь в ней, выполните следующую команду: django-admin.py startproject testproject.

В результате в директории проектов появится новая директория с именем testproject. Эта директория содержит четыре файла: __init__.py, manage.py, settings.py и urls.py. Сейчас мы не будем разбираться с тем, что делает каждый из этих файлов, а забежим немного вперед и запустим проект. Убедитесь, что вы находитесь в директории проекта (перейдите в нее с помощью команды cd testproject) и выполните следующую команду: python manage.py runserver. Результат ее выполнения должен быть таким, как в листинге 4.

Листинг 4. Запуск сервера разработки Django
Validating models...
0 errors found

Django version 1.0.2 final, using settings 'testproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Это сообщение говорит о том, что теперь по URL http://127.0.0.1:8000/ запущен сервер разработки. Откройте свой любимый браузер и укажите этот URL в адресной строке. Вы должны увидеть страницу, похожую на ту, что показана на рисунке 1.

Рисунок 1. Страница приветствия Django
Welcome to Django Page
Welcome to Django Page

Итак, теперь у нас есть функционирующая среда разработки Django. Стоит заметить, что хотя в этой среде можно запускать полноценные приложения Django, она не подходит для использования в качестве реальной рабочей среды приложения.

Анатомия приложения Django

Архитектура Django основана на идеях шаблона модель–представление–контроллер (Model-View-Controller или MVC) в том смысле, что в ней разделяются уровни логики приложения, пользовательского интерфейса (UI) и доступа к данным с целью дать возможность изменять каждый из этих уровней независимо от других. Однако, согласно документации проекта, Django следует похожему шаблону, который называется модель–шаблон–представление (Model-Template-View или MTV). Модель можно рассматривать как уровень доступа к данным, на котором приложение взаимодействует с любыми базами данных и источниками информации. Шаблон – это уровень, определяющий то, как данные должны быть представлены пользователю; он соответствует уровню представления в шаблоне MVC. В шаблоне MTV уровень представления описывает, какие данные должны быть представлены пользователю. Он не определяет, как именно они должны быть представлены, а делегирует эту задачу уровню шаблона. Что же до уровня контроллера шаблона MVC, считается, что в Django его роль выполняет сама инфраструктура, которая в соответствии с конфигурацией адресов URL определяет, какому представлению следует послать тот или иной запрос.

Помимо моделей, шаблонов и представлений, Django предлагает «из коробки» такую продвинутую функциональность, как конфигурация адресов URL, автоматический интерфейс администрирования, кэширование и прочее. Так же как и в Python, «батарейки в комплекте» являются одной из ключевых идей философии Django. Django поставляется совместно с большой стандартной библиотекой дополнительных пакетов, которые можно использовать в своих приложениях без необходимости дополнительной загрузки чего-либо.

Уровень модели приложения Django обрабатывается в инфраструктуре Django уровнем доступа к данным. Внутри этого уровня находится все, относящееся к данным: настройки соединения, параметры валидации, отношения и т.д. «Из коробки» в Django включена поддержка PostgreSQL (базы данных, предпочитаемой создателями Django), MySQL, SQLite и Oracle. Информация о том, какую базу данных следует использовать, храниться в файле настроек, и уровень модели будет одним и тем же независимо от того, какую именно базу данных выбрать.

Модели в Django можно рассматривать как описание схемы таблиц базы данных, представленное в виде кода на Python. Django использует модель для генерации и выполнения в базе данных инструкций SQL. База данных в свою очередь возвращает результат, который Django переводит в структуру данных Python, доступную для использования приложением Django. Очевидным преимуществом такого подхода является то, что можно переключаться между различными СУБД (например, перейти с MySql на PostgreSQL) не меняя при этом модели приложения.

В листинге 5 показан пример определения модели. Обычно определения моделей хранятся в файле models.py в директории приложения Django.

Листинг 5. Пример модели Django
from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    email = models.EmailField()
    date_of_birth = models.DateField()

Уровень шаблона приложения Django позволяет отделять пользовательский интерфейс или уровень представления Web-приложения от данных. В нем используются переменные-заглушки и простые логические инструкции чтобы задать, какие данные следует разместить в шаблоне. Обычно шаблоны генерируют результат в формате HTML, однако также могут генерировать XML или любой другой тип документа.

Главная идея уровня шаблона заключается в разделении кода уровня представления и кода уровня бизнес-логики. Это означает, что Python-программист может сосредоточиться на разработке приложения, оставляя работу над шаблонами Web-дизайнеру. Это также означает, что разработчик и дизайнер могут работать над одним и тем же проектом одновременно, так как эти компоненты полностью отделены друг от друга.

Система шаблонов Django не позволяет выполнять код Python напрямую из шаблона. В шаблонах имеется набор примитивных возможностей программирования, таких как переменные, логические инструкции (например, if), средства организации циклов (for), которые предоставляют более чем достаточно логики, необходимой для реализации представления данных. В листинге 6 показано, как может выглядеть шаблон Django.

Листинг 6. Пример шаблона Django
<html> <head>
<title>Your message has been sent</title>
</head>
<body>
<h1>Thank you!</h1>
<p>Just wanted to say a quick thanks, {{ name }}, for the message you have just
    sent.</p>
<p>It was sent on {{ sent_date|date:"j F Y" }}. We aim to respond within 
    48 hours.</p>
<p>Thanks again!</p>
</body>
</html>

В листинге 7 показано, как использовать этот шаблон в приложении Django.

Листинг 7. Использование простого шаблона Django в функции представления
def send_message(request):
    name = "Joe Lennon"
    sent_date = datetime.datetime.now()
    return render_to_response('thankyou.html', locals())

Функции представления, часто называемые просто представлениями, - это обычные функции Python, принимающие в качестве параметра объект запроса и возвращающие объект ответа. Объект запроса представляет запрос, поступивший на Web-сервер, и представление имеет доступ ко всем параметрам, переданным в этом запросе. Представления можно хранить в любом месте приложения, однако обычно их помещают в файле views.py. В листинге 7 показан пример функции представления с именем send_message. Она принимает параметр request, отображает результат с помощью шаблона (thankyou.html) и возвращает его в качестве ответа.

Мы только что сказали, что представления могут находиться где угодно. Если это так, как же Django узнает, где их искать? Ответ находится в URL-конфигурации, в которой определяется, какому представлению соответствует тот или иной URL-адрес. URL-конфигурация описывается в файле urls.py. Она задает отображение URL-адреса в функцию представления. Например, url-адресу /send_message/ можно поставить в соответствие наше представление send_message, показанное в листинге 7. Фактически конфигурация URL-адресов своей работой обеспечивает поддержку красивых URL-адресов: например, вместо использования строки запроса myfile.php?param1=value1, URL-адрес может выглядеть так: /myfile/value1/.

В листинге 8 приведен пример файла urls.py, связывающего URL-адрес /send_message/ с нашей функцией представления send_message, показанной в листинге 7.

Листинг 8. Пример URL-конфигурации
from django.conf.urls.defaults import *
from testproject.views import send_message

urlpatterns = patterns('',
    ('^send_message/$', send_message),
)

Одной из самых интересных и обсуждаемых возможностей Django является автоматический интерфейс администрирования. Разработчики Web-приложений, работавшие над проектами, в которых требовалось помимо самого приложения разработать еще внутренний интерфейс для администрирования, могут поделиться тем, какую скуку и неудовлетворенность нагоняет работа над таким интерфейсом. Интерфейсы администрирования обычно незамысловаты, их разработка не требует много навыков и не развивает ваше программистское мастерство. Автоматически генерируемый интерфейс администрирования Django представляет очень большую ценность, так как он устраняет необходимость выполнения этой рутинной работы.

Создав модели приложения и задав настройки базы данных, можно включить для своего приложения интерфейс администрирования. После этого перейдите в браузере по адресу http://127.0.0.1:8000/admin/, зарегистрируйтесь, и вы сможете управлять вашим приложением изнутри. Интерфейс предоставляет отличные средства управления аутентификацией отдельных пользователей и групп пользователей. Также имеется множество возможностей настройки интерфейса по своему вкусу. На рисунке 2 показан внешний вид приложения администрирования.

Рисунок 2. Автоматический интерфейс администрирования Django в действии
Django automatic admin interface in action
Django automatic admin interface in action

Мы сделали краткий обзор создания приложения Django и посмотрели, как работает лежащий в его основе шаблон MTV. Мы познакомились с тем, что представляют собой модели, шаблоны, представления и URL-конфигурация, а также мельком взглянули на потрясающий автоматический интерфейс администрирования Django. Если вы хотите подробнее узнать о разработке приложений с помощью Django, посетите официальный Web-сайт проекта Django и почитайте документацию, или же почитайте Django Book (см. раздел Ресурсы). Оба источника предлагают отличные руководства по всему, что связано с Django; в них, по сравнению с этой статьей, раскрывается гораздо больше деталей.

Далее мы познакомимся с развертыванием приложений Django на production-серверах.

Готовим приложение Django к развертыванию

Как мы видели, инфраструктура Django включает в себя сервер разработки, идеально подходящий для отладки и тестирования приложений Django. К сожалению, этот сервер предназначен для работы в локальном окружении и не способен выдерживать нагрузку, возникающую в реальной работе, когда Web-приложение используется одновременно многими пользователями. Поэтому приложения Django необходимо разворачивать на мощном Web-сервере, таком как Apache или lighttpd. Сначала мы узнаем, что нужно сделать, чтобы подготовить приложение к развертыванию, а затем узнаем, как подготовить Web-сервер к обслуживанию вашего приложения Django.

Перед обсуждением того, как настроить production-окружение для работы приложения Django, нам необходимо кое-что сделать в настройках самого приложения. Очень важно сделать эти изменения, так как иначе вы рискуете выставить напоказ любую уязвимость приложения Django из-за наличия отладочных сообщений об ошибках и т.д.

Естественно, мы не хотим менять эти настройки в окружении разработки, так как отладочная информация и сообщения об ошибках очень важны при сопровождении приложения. Для решения этой проблемы можно хранить два файла настроек: один для сервера разработки, а другой - для production-сервера. Также в качестве альтернативы можно использовать следующий прием, позволяющий хранить все настройки в одном файле, и сообщать Django, что в окружении разработки нужно использовать соответствующие настройки для разработки. Чтобы это сделать, приведите файл settings.py к виду, показанному в листинге 9, (конечно же, замените joe-mac-mini на имя используемого вами сервера разработки).

Листинг 9. Разделяем настройки окружения разработки и production-окружения
import socket
if socket.get_hostname() == 'joe-mac-mini':
    #здесь находятся настройки сервера разработки
else:
    #здесь находятся настройки production-сервера

Теперь, когда мы разделили настройки для наших двух окружений, давайте посмотрим, какие настройки нам следует изменить в production-окружении. Два главных параметра, которые нужно поменять – это DEBUG и TEMPLATE_DEBUG. При создании приложения Django с помощью команды django-admin.py startproject эти параметры по умолчанию устанавливаются в True. В production-окружении обязательно нужно поменять значения этих параметров на False. Поместите в разделе Production вашего файла settings.py следующую строку: DEBUG = TEMPLATE_DEBUG = False.

По умолчанию Django посылает электронное сообщение каждый раз при возникновении в приложении необработанного исключения. Чтобы эта функциональность заработала, сообщим Django, на какой адрес следует посылать сообщение. Это делается с помощью параметра ADMINS в файле settings.py(листинг 10).

Листинг 10. Задаем администраторов приложения
ADMINS = (
    ('Joe Lennon', 'joe@joelennon.ie'),
)

Если при разработке приложения Django вы допускали в своем коде ошибки, то могли заметить, что Django, чтобы помочь вам отыскать источник проблемы, генерирует страницы с информацией об ошибке, а также множеством другой полезной информации. При выключении режима отладки эти страницы исчезают, так как они представляют собой потенциальную угрозу безопасности приложения. В результате, если кто-нибудь натолкнется на ошибку (например, 404 – страница не найдена, 403 - доступ запрещен или 500 – внутренняя ошибка сервера), то он увидит лишь неуклюжую страницу с кодом ошибки. Чтобы это исправить, рекомендуется создать симпатичные и толковые шаблоны страниц ошибок и разместить их в папке шаблонов вашего приложения. Каждый шаблон должен называться в соответствии с кодом ошибки, которую он представляет. Для шаблона «страница не найдена» используйте имя 404.html, для «внутренняя ошибка сервера» - 505.html и т.д.

Настроив приложение для работы в production-окружении, мы покажем, как следует настроить это окружение для обслуживания приложения Django. Хотя Django может работать на FastCGI или lighttpd, наиболее типичным вариантом является использование Apache и mod_python. Затем мы кратко ознакомимся с развертыванием приложения Django при размещении в разделяемом окружении, в котором доступ к httpd.conf запрещен.

Развертываем приложение Django на Apache с mod_python

Согласно документации Django, рекомендуемым вариантом развертывания является Web-сервер Apache с модулем mod_python. Django может работать с HTTP-сервером Apache версии не ниже 2.0 и модулем mod_python версии 3.0 и позднее. mod_python – это модуль Apache, интегрирующий в Web-сервер поддержку языка программирования Python. Он работает гораздо быстрее, чем традиционный способ выполнения сценариев Python с помощью CGI.

Чтобы загрузить в Apache модуль mod_python, добавьте в файл httpd.conf следующую строку: LoadModule python_module /usr/lib/apache2/modules/mod_python.so.

Помимо загрузки модуля mod_python, также нужно задать директиву Location, которая сообщит Apache, какой URL-адрес следует связать с нашим приложением Django. В листинге 11 показаны настройки для ранее созданного проекта testproject.

Листинг 11. Директива Location проекта testproject
<Location "/testproject">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE testproject.settings
    PythonDebug Off
</Location>

Эта директива сообщает Apache, что проект testproject доступен по URL-адресу /testproject. Например, если сервер имеет доменное имя example.com, то наше приложение Django будет доступно по адресу http://www.example.com/testproject/. Чтобы эти новые настройки начали действовать, просто перезагрузите сервер Apache.

Разработчики Django настоятельно рекомендуют не обслуживать запросы к медиа-файлам (таким, как изображения, видео, аудио и т.д.) на том же Web-сервере, где работает само приложение. Но во многих случаях сделать так не представляется возможным, по крайней мере, на первых порах. Чтобы настроить обработку запросов к медиа-файлам, добавим в файл httpd.conf следующую директиву(листинг 12).

Листинг 12. Сообщаем Apache, что не нужно использовать mod_python для медиа-файлов
<LocationMatch "\.(png|gif|jpg|mov|mp3|avi|wav)$">
    SetHandler None
</LocationMatch>

Вот и все, что нужно настроить в Apache и mod_python для развертывания приложения Django на production Web-сервере. Далее мы рассмотрим сценарий развертывания при размещении приложения на Web-сервере совместного доступа, когда изменять файл httpd.conf запрещено.

Разворачиваем приложения Deploying Django в окружении разделяемого Web-хостинга

К сожалению, выделенные серверы и виртуальные частные серверы довольны дороги, поэтому такие варианты развертывания приложения подходят не всем. Часто приложение сначала разворачивают на разделяемом хостинге, а переход на выделенный сервер осуществляется, когда приложение набирает популярность. К счастью, большинство поставщиков решений разделяемого хостинга поддерживают Python, поэтому приложения Django можно разворачивать и в таком окружении.

В отличие от выделенного окружения, здесь конечные пользователи обычно не имеют возможности выполнять отдельный процесс сервера или редактировать конфигурационный файл httpd.conf. Это означает, что пользователь не сможет сделать изменения, описанные в предыдущем разделе, а значит, не сможет запустить таким способом Django. К счастью, есть возможность развернуть Django в окружении разделяемого хостинга с помощью ответвляемых от Web-сервера процессов, выполняющих программу FastCGI. Создайте файл с именем .htaccess и поместите его в ту же директорию, где будет разворачиваться приложение Django(листинг 13).

Листинг 13. Файл .htaccess
AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ testproject.fcgi/$1 [QSA,L]

Затем создадим небольшой сценарий Python, который будет информировать Apache о различных настройках проекта Django и выполнять программу FastCGI. Имя этого файла может быть любым, но оно должно совпадать с именем файла в строке RewriteRule файла .htaccess. В листинге 13 мы использовали имя файла testproject.fcgi, поэтому именно так и назовем файл сценария(листинг 14).

Листинг 14. Файл testproject.fcgi
#!/usr/bin/python
import sys, os
sys.path.insert(0, "/home/joelennon/python")
os.environ['DJANGO_SETTINGS_MODULE'] = "testproject.settings"

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

Убедитесь, что этот файл является исполняемым. Если вы можете создать сеанс оболочки с сервером разделяемого хостинга, авторизуйтесь, перейдите в директорию, где хранится этот файл, и выполните команду chmod 755 testproject.fcgi.

Если вы не можете создать сеанс оболочки, можно поменять права доступа к файлу с помощью хорошего FTP-клиента. Каждый раз, после изменения кода приложения, следует менять временную метку этого файла. Таким образом, мы сообщаем Apache, что приложение было обновлено, после чего он перезапускает наше приложение Django. Если вы можете создать сеанс оболочки, нужно просто выполнить команду touch testproject.fcgi. В противном случае, чтобы обновить временную метку этого файла, можно заново загрузить его на сервер или отредактировать его и заново сохранить.

Если вы предпочитаете не связываться с этими конфигурационными файлами, можно воспользоваться услугами хостинга, предоставляющего поддержку Django «из коробки». MediaTemple - популярный поставщик услуг хостинга - предлагает надстройку Django GridContainer к своему решению GridService начиная от $20 в месяц за 256 МБ RAM. GridContainer работает на lighttpd/FastCGI, а количество RAM-памяти можно увеличивать в соответствии с масштабами приложения.

Масштабируем схему развертывания приложения Django

Если ваше приложение Django пользуется успехом, то, вероятно, вам потребуется сделать схему его развертывания как можно более масштабируемой. Часто Web-приложения отлично работают при средней нагрузке, но такие феномены, как Digg-эффект могут направлять на приложение такое количество трафика, которое может нарушить работу приложения. К счастью, Django и Python масштабируемы по своей природе, однако есть несколько моментов, на которые следует обратить внимание по мере роста вашего приложения.

Если ваше приложение Django работает в окружении разделяемого хостинга, и вы начинаете чувствовать, что ему не хватает ресурсов, первым очевидным решением является переход на выделенную машину. Если вас не устраивает цена вопроса, можно рассмотреть возможность размещения на виртуальном частном сервере – промежуточном решении между разделяемым хостингом и выделенным сервером.

По мере роста приложения ресурсы выделенного сервера также могут закончиться очень быстро. Вот несколько рецептов, которые могут снизить загруженность вашего сервера.

  • Отключите все неиспользуемые процессы и демоны, такие как серверы почты, серверы потокового вещания, игровые серверы или любые другие необязательные процессы, потребляющие драгоценное время процессора и RAM.
  • Переместите ваши медиа-файлы на облачную платформу, такую как Amazon S3. Это позволит вам использовать Web-сервер только для обработки запросов Django.
  • Отключите в настройках Apache параметр Keep-Alive. Keep-Alive – это расширение протокола HTTP, позволяющее создавать постоянные HTTP-соединения. Оно позволяет посылать множество запросов по одному и тому же TCP-соединению, что чрезвычайно ускоряет обслуживание статических документов HTML и изображений. К сожалению, это расширение может негативно влиять на производительность приложения Django. Обратите внимание, что этот параметр следует выключать только в том случае, если вы переместили медиа-файлы на отдельный сервер. Чтобы выключить Keep-Alive, найдите соответствующую строку в файле httpd.conf и поменяйте ее на Keep-Alive Off.
  • Используйте встроенную инфраструктуру кэширования Django. Она основана на memcached – популярной распределенной системе кэширования объектов. Эффективное кэширование может сильно улучшить производительность приложений Django.
  • Обновите ваш сервер. Установите столько RAM-памяти, сколько возможно. Если не хватает дискового пространства, подумайте о добавлении еще одного диска. Более чем вероятно, что проблемы производительности сервера вызваны нехваткой RAM-памяти. Не расходуйте деньги на обновление процессора, лучше потратьте их на RAM-память.
  • Купите еще один сервер. Может наступить время, когда сервер не сможет в одиночку справляться с нагрузкой вашего приложения Django. Как только оно настанет, добавьте еще один сервер. Запустите Web-сервер на одной машине, а сервер базы данных - на другой. Машину с большим количеством RAM-памяти используйте для сервера базы данных. Если необходимо, добавьте новой машине RAM-памяти и дискового пространства.
  • Используйте репликацию базы данных. Если серверу базы данных не хватает ресурсов, можно снизить нагрузку на него, организовав репликацию между несколькими серверами. Впоследствии в систему репликации можно добавлять серверы, чтобы обеспечить ее дополнительными ресурсами.
  • Добавьте избыточность. В крупных приложениях наличие даже одной ошибки в Web-сервере или сервере базы данных равнозначно ожиданию наступления катастрофы. По возможности, следует добавить избыточные серверы, которые будут использоваться в случае выхода из строя основных серверов. Кроме того, использование средств аппаратной и программной балансировки нагрузки, таких как mod_proxy, которые будут распределять трафик между вашими серверами, может кардинально улучшить производительность вашего приложения.

Важно продумать возможности масштабирования своего приложения Django как можно раньше. Тогда вы сможете выработать план действий, покрывающий все возможные сценарии. И поэтому, если Digg-эффект парализует работу вашего приложения, вы сможете просто выполнить очередной этап вашего плана масштабирования и встретить своих новых пользователей с открытыми объятиями и, что более важно, с быстро работающим приложением.

Заключение

Мы рассмотрели инфраструктуру Django с двух сторон: с позиции разработчика, только начинающего работу с ней, и с позиции человека, имеющего уже полностью готовое приложение Django и желающего узнать больше о развертывании приложения в Web. Также мы узнали, какие возможности следует рассмотреть для улучшения масштабируемости приложения в будущем. Мы рассмотрели, из чего состоит приложение Django и узнали о шаблоне MTV (Model-Template-View или модель–шаблон–представление), на котором оно основано. Мы увидели, что Django – это легковесная, простая в установке и изучении инфраструктура с отличной документацией и динамичным сообществом разработчиков и пользователей. Все это делает Django отличной инфраструктурой для разработки вашего следующего Web-приложения.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=630723
ArticleTitle=Разворачиваем приложения Django на production-сервере
publish-date=03042011