为什么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上有一个小小的项目,我还没有设置为"生产"模式,我想知道究竟有什么缺点.

Answer 1

表现相关原因:

• Web服务器在提供静态文件方面要好几个数量级.
• AFAIK开发服务器是单线程的,并且每次只能响应一个请求,并发请求将被阻止(大多数浏览器会尝试并行下载资产的4个并发请求).

安全相关原因:

• 使用应用程序提供静态内容是过度的(简化有利于安全)
• 开发人员喜欢安全,所以这是一种免责声明
• 调试模式公开了很多关于服务器的信息

Django从新闻出版行业开始,一般来说有足够的流量来证明从专用Web服务器提供静态内容是合理的,可能原始开发人员对这种安排有偏见.

也就是说,有些项目通过基于gunicorn或tornado的更强大的实现来取代默认开发服务器.

Answer 2

Kenneth(请求的作者,由Heroku雇用)有不同的意见(来源):

实际上,通过Python/Django提供静态文件对于生产来说很好 - 这些请求与动态请求没有什么不同.

性能会很棒,但不如nginx好.

如果您非常关注效率,那么您不应该在服务器上托管这些文件,而是将它们推送到像S3 + Cloudfront之类的CDN.

这种方法的另一个好处是发展:生产平价.

在heroku上,你不能使用Nginx来服务静态文件,实际上你也无法在大多数其他PaaS上使用它,去年我在云代工厂遇到了同样的问题.但有一个解决方法:

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

我们建议大多数应用程序从Django或CDN为其资产提供服务.

由于其静态文件处理程序的设计,Django不建议在生产中提供静态文件.

幸运的是,有一个名为DJ-Static的库,可以使用生产就绪的WSGI资产服务器.

我在这里写了Django和Static Assets的指南:https: //devcenter.heroku.com/articles/django-assets

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

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

通过gunicorn提供静态文件