需求背景
接到重点业务需求要分轮次展示数据，预估最高承接 9w 的 QPS，作为后端工程师下意识的就是把接口写好，分级缓存、机器扩容、线程拉满等等一系列连招准备，再因为数据更新频次两只手都数得过来，我们采取了最稳妥的处理方式，直接生成静态文件拿 CDN 抗量
架构流程大致如下所示：
数据更新后会重新生成新一轮次的文件，刷新 CDN 的时候会触发大量回源请求，应用服务器极端情况得 hold 住这 9w 的 QPS
第一次压测
双机房一共 40 台 4C 的机器，25KB 数据文件，5w 的 QPS 直接把 CPU 打到 90%
这明显不符合业务需求啊，咋办？先无脑加机器试试呗
就在这时测试同学反馈压测的数据不对，最后一轮文件最大会有 125KB，雪上加霜
于是乎文件替换，机器数量整体翻一倍扩到 80 台，服务端 CPU 依然是瓶颈，QPS 加不上去了
到底是哪里在消耗 CPU 资源呢，整体架构已经简单到不能再简单了
这时候我们注意到为了节省网络带宽 nginx 开启了 gzip 压缩，是不是这小子搞的鬼
ini
server
{
listen 80;
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain application/css text/css application/xml text/javascript application/javascript application/x-javascript;
......
}第二次压测
为了验证这个猜想，我们把 nginx 中的 gzip 压缩率从 6 调成 2，以减少 CPU 的计算量
gzip_comp_level 2;
这轮压下来 CPU 还是很快被打满，但 QPS 勉强能达到 9w，坐实了确实是 gzip 在耗 CPU
nginx 作为家喻户晓的 web 服务器，以高性能高并发著称，区区一个静态数据文件就把应用服务器压的这么高，一定是哪里不对
第三次压测
明确了 gzip 在耗 CPU 之后我们潜下心来查阅了相关资料，发现了一丝进展
html/css/js 等静态文件通常包含大量空格、标签等重复字符，重复出现的部分使用「距离加长度」表达可以减少字符数，进而大幅降低带宽，这就是 gzip 无损压缩的基本原理
作为一种端到端的压缩技术，gzip 约定文件在服务端压缩完成，传输中保持不变，直到抵达客户端。这不妥妥的理论依据嘛～
nginx 中的 gzip 压缩分为动态压缩和静态压缩两种
•动态压缩
服务器给客户端返回响应时，消耗自身的资源进行实时压缩，保证客户端拿到 gzip 格式的文件
这个模块是默认编译的，详情可以查看 nginx.org/en/docs/htt...
•静态压缩
直接将预先压缩过的 .gz 文件返回给客户端，不再实时压缩文件，如果找不到 .gz 文件，会使用对应的原始文件
这个模块需要单独编译，详情可以查看 nginx.org/en/docs/htt...
如果开启了 gzip_static always，而且客户端不支持 gzip，还可以在服务端加装 gunzip 来帮助客户端解压，这里我们就不需要了
查了一下 jdos 自带的 nginx 已经编译了 ngx_http_gzip_static_module，省去了重新编译的麻烦事
接下来通过 GZIPOutputStream 在本地额外生成一个 .gz 的文件，nginx 配置上静态压缩再来一次
gzip_static on;
面对 9w 的QPS，40 台机器只用了 7% 的 CPU 使用率完美扛下
为了探底继续加压，应用服务器 CPU 增长缓慢，直到网络流出速率被拉到了 89MB/s，担心影响宿主机其他容器停止压力，此时 QPS 已经来到 27w
qps 5w->27w 提升 5 倍，CPU 90%->7% 降低 10 倍，整体性能翻了 50 倍不止，这回舒服了～
写在最后
经过一连串的分析实践，似乎静态压缩存在"压倒性"优势，那什么场景适合动态压缩，什么场景适合静态压缩呢？一番探讨后得出以下结论
纯静态不会变化的文件适合静态压缩，提前使用gzip压缩好避免CPU和带宽的浪费。动态压缩适合API接口返回给前端数据这种动态的场景，数据会发生变化，这时候就需要nginx根据返回内容动态压缩，以节省服务器带宽
作为一名后端工程师，nginx 是我们的老相识了，抬头不见低头见。日常工作中配一配转发规则，查一查 header 设置，基本都是把 nginx 作为反向代理使用。这次是直接访问静态资源，调整过程的一系列优化加深了我们对 gzip 的动态压缩和静态压缩的基本认识，这在 NG 老炮儿眼里显得微不足道，但对于我们来说却是一次难得的技能拓展机会
在之前的职业生涯里，我们一直聚焦于业务架构设计与开发，对性能的优化似乎已经形成思维惯性。面对大数据量长事务请求，减少循环变批量，增大并发，增加缓存，实在不行走异步任务解决，一般瓶颈都出现在 I/O 层面，毕竟磁盘慢嘛，减少与数据库的交互次数往往就有效果，其他大概率不是问题。这回有点儿不一样，CPU 被打起来的原因就是出现了大量数据计算，在高并发请求前，任何一个环节都可能产生性能问题。
作者：京东零售广告研发 闫创
来源：京东零售技术 转载请注明来源