Почему документы Django предлагают отдельный сервер для статических файлов?

Ответ 1

В общем, неплохо поставить статический контент - например. изображения, CSS и JS файлы - на другом сервере и, кроме того, на другой домен/поддомен. Это позволяет программному обеспечению, которое поддерживает статические файлы, быть высоко оптимизированными и невероятно быстрыми (например, nginx).

Другим основным преимуществом является снижение сетевого трафика. Если вы используете статический контент из того же домена, что и ваше динамическое приложение Django, браузеры браузера отправляют ваши файлы cookie домена как часть своего HTTP-запроса даже для статических файлов. Это лишние накладные расходы - статические файлы всегда будут статическими, но это необходимо, потому что клиент не может отличить статический и динамический контент. Если, с другой стороны, статический контент обслуживался из другого домена, тогда он может быть настроен как " cookieless domain", таким образом минимизируя накладные расходы.

Ответ 2

Это обычная стратегия среди веб-фреймворков. Идея здесь состоит в том, чтобы просто использовать лучший инструмент для работы со статическим контентом. Apache, Nginx, lighttpd и другие современные веб-серверы чрезвычайно полезны для обслуживания статического контента, поэтому, если вы можете легко настроить эти серверы для выполнения этой работы, у вас есть несколько преимуществ:

• Эти запросы быстро растут.
• Вы не занимаетесь своими тяжелыми процессами python, выполняющими мирские задачи, поэтому они могут обрабатывать запросы приложений.
• В будущем, имея этот отдельный процесс обработки статического контента, вы имеете большую гибкость с точки зрения использования CDN или распространения активов на другие серверы.

Перемещение медиафайлов в конкретный каталог упрощает настройку веб-сервера для этой задачи.

Ответ 3

Современные веб-браузеры часто открывают два (несколько?) сокетов при загрузке активов с одного хоста. Таким образом, вы получаете index.html, который ссылается на кучу изображений, js файлов, css и т.д. Каждый дополнительный файл загружается одним блокирующим сокетом.

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

Эта параллелизация также позволяет запускать разные серверные движки (хорошо, они могут быть в одном и том же поле, но тогда у вас все еще есть только два сокета), которые специализируются на том, что они обслуживают - например nginx для сырого содержимого и fastcgi для динамического содержимого django.

Ответ 4

Это также хорошо для безопасности. Довольно суровый подход заключается в том, чтобы сохранить загруженные пользователем файлы в стороне от файлов основного сервера. Отдельные разрешения на папку и т.д. Но да, большие преимущества скорости.

Ответ 5

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

Вместо этого я развернусь с использованием общего httpd-сервера (Apache, nginx,...) и позволю ему запустить приложение через WSGI/FastCGI и, чтобы он мог также загружать статические и мультимедийные файлы. Это просто работает. Вы избавляете себя от многих неприятностей, особенно если вы рассматривали использование отдельного сервера для пользовательских носителей.

Если ваш сайт достаточно успешный, чтобы иметь проблемы с производительностью, вы с удовольствием исправите его. И ваш первый шаг может состоять в том, чтобы просто арендовать более быстрый сервер.

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