为什么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从新闻出版行业开始，一般来说有足够的流量来证明从专用网络服务器提供静态内容是合理的，可能原始开发者对这种安排有偏见。

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

Answer 2

Kenneth（Heroku聘用的requests的作者）有不同的意见（source）：

  

实际上，通过Python / Django提供静态文件是可以的   生产 - 这些要求与动态请求没有什么不同。

     

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

     

如果你非常关心效率，那么你不应该这样做   无论如何要在你的服务器上托管这些文件，你会推动它们   像S3 + Cloudfront之类的CDN。

     

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

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

  

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

     

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

     

Django建议不要在生产中提供静态文件   其静态文件处理程序的设计。

     

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

     

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

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

Serving static files for a Django app

serving static files via gunicorn