【问题标题】:Why is django's development automatic static file server not suitable for production?为什么django开发的自动静态文件服务器不适合生产?
【发布时间】:2013-11-15 22:45:15
【问题描述】:

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

【问题讨论】:

    标签: django django-staticfiles


    【解决方案1】:

    性能相关原因:

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

    安全相关原因:

    • 使用应用提供静态内容是多余的(简化有利于安全)
    • 开发人员喜欢安全起见,因此这是一种免责声明
    • 调试模式会暴露很多关于服务器的信息

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

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

    【讨论】:

      【解决方案2】:

      Kenneth(requests 的作者,受雇于 Heroku)有不同的看法 (source):

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

      性能会很棒,但不如 nginx。

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

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

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

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

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

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

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

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

      阅读以下讨论了解更多详情:

      Serving static files for a Django app

      serving static files via gunicorn

      【讨论】:

        猜你喜欢
        • 2019-11-17
        • 1970-01-01
        • 1970-01-01
        • 2017-11-15
        • 2015-10-02
        • 2015-11-06
        • 2014-01-17
        • 2012-06-03
        • 1970-01-01
        相关资源
        最近更新 更多