我们建议使用单独的 Web 服务器——即不运行 Django 的服务器——来提供媒体服务。
为什么?
一般而言,将静态内容(例如图像、CSS 和 JS 文件)放在不同的服务器上,此外,放在不同的域/子域上是个好主意。这允许为静态文件提供服务的软件得到高度优化和极快的速度(例如,nginx)。
另一个主要好处来自网络流量的减少。如果您从与动态 Django 应用程序相同的域中提供静态内容,那么客户端浏览器会将您域的 cookie 作为其 HTTP 请求的一部分发送,即使对于静态文件也是如此。这是不必要的开销 - 静态文件将始终是静态的 - 但这是必需的,因为客户端无法区分静态和动态内容之间的区别。另一方面,如果静态内容是从不同的域提供的,则可以将其配置为“无cookie 域”,从而最大限度地减少请求开销。
这是 Web 框架中常见的策略。这里的想法是简单地使用最好的工具来提供静态内容。Apache、Nginx、lighttpd 和其他现代网络服务器都非常擅长提供静态内容,因此如果您可以轻松配置这些服务器来完成这项工作,您将获得以下好处:
通过将媒体移动到特定目录,您可以更轻松地为此任务配置网络服务器。
这对安全也有好处。一个非常简单的方法是让用户上传的文件远离您的核心服务器文件。单独的文件夹权限等。但是,是的,速度优势很大。
从单个主机下载资产时,现代 Web 浏览器通常会打开两个(几个?)套接字。所以你会得到index.html
哪些引用了一堆图像、js 文件、css 等。每个额外的文件都由一个阻塞套接字下载。
如果您从单独的主机中提取静态文件,您将获得额外的两个套接字来下载文件 - 因此在生产中这工作得更快。
这种并行化还允许您运行不同的服务器引擎(好吧,它们可以在同一个盒子上 - 但你仍然只能获得两个套接字),专门处理它们所服务的内容 - 例如原始nginx
内容和动态内容。fastcgi
django
从技术和理论的角度来看,这里的答案肯定都是正确的。但实际上,对于绝大多数 Django 部署,我什至不会考虑为媒体和 Django 应用程序使用单独的服务器(即机器、虚拟或物理)。只是没有必要。它是过早的优化——“万恶之源”。
相反,我会使用一个通用的 httpd 服务器(Apache、nginx、...)进行部署,让它通过 WSGI/FastCGI 运行应用程序,并让它也提供静态和媒体文件。这行得通。您可以避免很多麻烦,特别是如果您考虑为用户媒体使用单独的服务器。
如果您的网站成功到足以出现性能问题,您将很乐意修复它。您的第一步甚至可能只是租用更快的服务器。
这至少适用于您唯一关心的问题与性能相关的情况。出于安全原因,您可能必须使用单独的服务器,甚至可能是因为您的客户需要它。