为什么Django开发自动静态文件服务器不适合生产环境？

Question

正如文档所述：https://docs.djangoproject.com/en/dev/howto/static-files/

当DEBUG设置为True时，服务器会自动提供静态文件，但它声明：

This method is grossly inefficient and probably insecure, so it is unsuitable for production.

但是，它具体存在哪些效率低下和不安全之处呢？我只有一个在Heroku上的小型项目，尚未将其设置为“生产”模式，我想知道确切的缺点是什么。

- dl8

Answer 1

性能相关原因：

• Web服务器在提供静态文件方面更加优秀。
• 据我所知，开发服务器是单线程的，一次只能响应一个请求，同时的请求会被阻塞（大多数浏览器会尝试并行下载资产时进行4个并发请求）。

安全相关原因：

• 使用应用程序来提供静态内容是过度的（简化对于安全性有好处）。
• 开发人员喜欢保持安全，因此这是一种免责声明。
• 调试模式会暴露关于服务器的大量信息。

Django起源于新闻出版业，在这个行业中通常有足够的流量来证明从专用的Web服务器提供静态内容是合理的，可能最初的开发人员对这种安排有偏见。

也就是说，有一些项目将默认的开发服务器替换为基于gunicorn或tornado的更强大的实现。

- Paulo Scardine

Answer 2

肯尼斯（requests 的作者，Heroku 公司的员工）持有不同观点 (来源):

事实上，Python/Django 通过服务静态文件在生产环境中表现良好--这些请求与动态请求没有区别。

性能将会很棒，但不如 nginx 好。

如果您非常关注效率，那么您不应该在服务器上托管这些文件，而是应该将它们推到 S3+Cloudfront 等 CDN 上。

此方法的另一种好处是可以实现开发和生产的相对平衡。

而且在 Heroku 上，你无法使用 Nginx 服务静态文件，在大多数其他 PaaS 上也无法做到这点，去年我在 cloud foundry 上面遇到了同样的问题。但是有一个解决方法:

在 Heroku 上，您的应用程序直接响应 HTTP 请求，而不是通过 Apache 或 Nginx 等其他 Web 服务器进行响应。

我们推荐大多数应用程序直接从 Django 或 CDN 提供其资源。

Django 不建议在生产环境中提供静态文件，因为其静态文件处理程序的设计。

幸运的是，有一个叫做 DJ-Static 的库，它使用一个生产准备好的 WSGI 资源服务器。

我已经为 Django 和 Static Assets 写了一份指南，地址在这里：   https://devcenter.heroku.com/articles/django-assets

阅读以下讨论以获取更多详细信息:

为 Django 应用程序提供静态文件

通过 gunicorn 服务静态文件

- Leonardo.Z