5

如所述：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 上有一个小型项目，我还没有设置为“生产”模式，我想知道确切的缺点是什么。

4

2 回答 2

7

性能相关原因：

  • Web 服务器在提供静态文件方面要好几个数量级。
  • AFAIK 开发服务器是单线程的，一次只能响应一个请求，并发请求将被阻塞（大多数浏览器会发出 4 个并发请求以尝试并行下载资产）。

安全相关原因：

  • 使用应用程序提供静态内容是多余的（简化有利于安全）
  • 开发人员喜欢安全起见，所以这是一种免责声明
  • 调试模式暴露了很多关于服务器的信息

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

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

于 2013-11-05T06:50:57.583 回答
6

Kenneth（请求的作者，受雇于 Heroku）有不同的看法（来源）：

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

性能会很棒，但不如 nginx。

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

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

而在heroku上，你不能使用Nginx来服务器静态文件，实际上你也不能在大多数其他PaaS上做到这一点，去年我在cloud Foundry上遇到了同样的问题。但是有一个解决方法：

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

我们建议大多数应用程序从 Django 或 CDN 提供它们的资产。

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

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

我在这里为 Django 和静态资产编写了指南： https ://devcenter.heroku.com/articles/django-assets

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

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

通过 gunicorn 提供静态文件

于 2013-11-05T06:49:07.667 回答