一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第12天，点击查看活动详情
前段时间遇到个问题，业务人员反应某个接口无数据返回，然后测试就和我提了个bug，于是我就去线上扒日志，发现并没有报错信息，这说明接口是正常的，并没有发生异常，于是我初步认为是不是执行时间太慢导致超时，在本地debug发现接口执行时间并没有超过超时阈值并且返回结果正常，我内心直接十万个为什么？？？what ？why ？什么情况啊！
排查思路，在确定不是借口问题后我首先想到的就是会不会是Nginx网关有问题，于是我就和运维反映，向其说明这边某些条件下数据量返回较大，会不会影响到前端展示，运维就将proxy_buffer_size以及proxy_buffers增大到5m，但是我这边的数据量是最大可达到10m，甚至更多的，我就提出能不能将数据压缩，一番查阅后发现Nginx有gzip的功能，如果开启会将数据压缩成二进制，再由客户端的浏览器来解压，但是代价就是服务器的CPU资源，相对带宽来说用CPU资源换取还能接受。 压缩后如下图：
将近10倍的压缩了。
工作中Nginx的gzip压缩相关参数：
- gzip on/off: 开启/关闭压缩，Nginx默认是关闭的，需要手动打开。
- gzip_comp_level lenvel：压缩等级（1到9）等级越高压缩能力越强，与此同时消耗的CPU资源越多，所以一般都是设置3~5，具体还是得根据服务器CPU使用情况来决定（ps:可以使用CPU监控观察CPU的使用率，如果使用率不高可以适当增加，否则应该设置较小）。
对应上面这个问题我还特意和前端探讨了下，如果有的图片很多像那种高清、超清的大图片，那页面不是很卡吗，但是为什么我打开页面没发现有卡顿的现象，你是做了压缩吗？前端的回答是的，他也是有使用Nginx的图片压缩的，于是我就去官网查阅一番，发现了图片压缩的配置，如下图：
传送门：具体可以参考nginx官网
工作中图片压缩相关参数
- gzip_types： image/jpeg image/gif image/png（图片类型）;
- 图片压缩方式，一般都是使用动态压缩或者等比压缩，固定压缩基本不用。
如下配置可以参考：
location ~* /(.+)\.(jpg|jpeg|gif|png)!(\d+)$ { image_filter resize $3 -; image_filter_buffer 10M; try_files /$1.$2 /default.png; root html; }
