【问题标题】:Django, Nginx & Varnish gzip params to be activated要激活的 Django、Nginx 和 Varnish gzip 参数
【发布时间】:2017-03-28 07:31:57
【问题描述】:

我有一个带有 Gunicorn 的 Django 应用程序,通过 Varnish 并使用 Nginx 提供服务。

MyDjangoApp --> Gunicorn --> Varnish --> Nginx --> 客户端

我必须保留哪一个 gzip 参数?

在 Django 中?

MIDDLEWARE_CLASSES = (
    # Remove Django Gzip middleware as we already have it in nginx ?
    'django.middleware.gzip.GZipMiddleware',
    ....

在 Nginx 中?

http {
    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    ....

在清漆中?

sub vcl_backend_response {
    if (bereq.url ~ "html$") {
            set beresp.do_gzip = true;
    }
....

我必须激活所有 confs 还是只激活 Nginx ? 如果我在 Django 中为 ex 激活 GZipMiddleware,我不需要在 Varnish 和 Nginx 上激活它,否则我错过了什么?

【问题讨论】:

  • 同时使用varnish和nginx是不是有点矫枉过正?

标签: django nginx gzip varnish


【解决方案1】:

我应该在哪里进行 gzip 压缩的方法是这样的:

在 Varnish 后面的网络服务器上启用 gzip。

在你的情况下,你可以把它保存在 Django 中。

不要更改默认的 Varnish gzip 参数。 (让它使用default behaviour 处理gzip)

为什么?

  • Varnish 可以将压缩后的对象存储在其缓存中(很好,节省存储空间)。
  • 在提供缓存对象时不会花费任何 CPU 时间进行压缩(大多数客户端会要求压缩对象,Varnish 可以直接提供)

因此,您可以通过适当级别的压缩来节省 CPU 和 RAM。

【讨论】:

  • 似乎是逻辑,我是否也必须在 Nginx 上禁用 gzip,因为它已经被 Django 压缩了?
  • 保留它是安全的,因为 Nginx 会看到响应 gzip 并且不会执行双重 gzip。
猜你喜欢
  • 2017-08-28
  • 1970-01-01
  • 2021-10-20
  • 2011-06-26
  • 2019-01-31
  • 2012-02-29
  • 1970-01-01
  • 2011-06-20
  • 1970-01-01
相关资源
最近更新 更多