目前需求需要优化前后端 nginx 之间传输的流量，压缩数据节约小水管带宽，所以准备开启全流量压缩，大概流程就是前端 nginx 会 set 一个 header 到后端 nginx，proxy_set_header Accept-Encoding "gzip"; 让后端 nginx 开启压缩，前端 nginx 再使用这个模块解压数据返回给不支持解压 gzip 的客国外服务器户端

网上搜了下，这个模块没有看到被大量投入使用的场景，所以上到线上环境，有点担心 gunzip 解压带给前端 nginx 的内存和 CPU 压力会有多高，内心慌的一匹。。有把这个模块线上实战的老铁吗？

大规模用过，没问题

应该就是吃内存和 cpu 的问题吧

gzip 很常见吧，阿里云腾讯云的 cdn 的 nginx 都有开 gzip，而且大部分网站也有开 gzip，比起后端的资源占用，nginx 这里真的不值得一提
另外，现在开始流行 br 算法了

好的，老哥

他说的是服务端解压 gzip 不是压缩

br 我知道，但是没找到 nginx 的解压模块。

还可以研究一下 http_gzip_static_module 模块

baidu:
Content-Encoding: gzip
google:
content-encoding: br

前后端 nginx 之间的链路真的这么紧张吗？这种做法有点骚啊。前端 nginx 还要判断用户端是否支持 gzip，鸡肋。

回源强制 gzip
发现客户端不支持 gzip 并且源站返回 gzip 内容就解压
本来前端 nginx 就必须判断客户端是否支持 gzip

CDN 回源强制 gzip?这个苛刻点了吧，一般场景没这样干的吧？如果用户浏览器访问不支持压缩，那 CDN 的缓存就没意义了，或者 CDN 有 2 种缓存，压缩和非压缩的。

可以只缓存一份压缩的，客户端不支持压缩再解压

这就需要在 CDN 的缓存服务器写逻辑配置了吧？还有贵司也太精打细算了吧。。我是觉得是否有必要这么做，虽然技术上可行。

我上面说了 nginx 没找到 br 算法解压模块，大佬你给写 nginx 的 br 解压模块吗

做法是有点极端，但是我的现实环境就是这样。。CND 不清楚，但是我测试 nginx 本身就实现了你说的逻辑，发现客户端不支持解压才会去解压。


google 出的，你为什么不找 google
https://github.com/google/ngx_brotli

用 nginx lua 写个监控 CPU 和内存的程序吧，根据当前负载动态调整要不要压缩，以及压缩比都可以调整~

我擦，你是一直看东西只看一半吗。。

解压的开销一般小于压缩的开销

没必要用这个模块啊，你的需求其实在前端开始 nginx cache 就可以减少很多前后端的压力了。还有这楼里很多人分不清 gzip 和 gunzip 模块的区别……

看了好一会儿明白了…
楼主问题很简单，upstream 只提供了 gzip 的结果，但是 client 可能不接受。作为中间层就需要特殊处理下。
其实看过算法就知道，只要没啥漏洞，compress 固然可能要考虑性能，decompress 无论如何都是一把梭直接就能过… 除非有重大 bug

cache 已经开了，对于动态数据准备再开启全压缩，我的场景就是这么特殊。。目标是前后端 nginx 的流量传输越小越好，小水管带宽还限流。。

回头看看源码，准备一把梭了！

不需要判断客户端是否支持 gzip
不支持的就让他滚蛋好了
全程压缩发给客户端！！

兄弟不要鸡冻。。

想当年我上司为了兼容部分根本没消费能力的垃圾客户，不让用 gzip
那是电商网站啊！！

ngx lua 怎么实现监控 CPU、内存？有例子码？

nginx worker 里开个定时器，每隔一秒检测下就可以了。简单点直接用 lua 读 /proc/ 里的文件获取 CPU 等。觉得 lua 麻烦可以用其他程序写，通过文件或者管道和 lua 交互。最终通过 lua 设置 nginx 变量，决定压缩开不开以及比例。

流下了没有钱的眼泪

之前试过按网络流量监控的。之前买了个按流量计费的 ecs，所以在性能和流量之间找一个平衡点。当时还用 lua 做了个接口： https://alert.fun/traff_stat