简单一招竟把nginx服务器性能提升50倍

京东云开发者
• 阅读 201

需求背景

接到重点业务需求要分轮次展示数据,预估最高承接 9w 的 QPS,作为后端工程师下意识的就是把接口写好,分级缓存、机器扩容、线程拉满等等一系列连招准备,再因为数据更新频次两只手都数得过来,我们采取了最稳妥的处理方式,直接生成静态文件拿 CDN 抗量

架构流程大致如下所示:

简单一招竟把nginx服务器性能提升50倍

数据更新后会重新生成新一轮次的文件,刷新 CDN 的时候会触发大量回源请求,应用服务器极端情况得 hold 住这 9w 的 QPS

第一次压测

双机房一共 40 台 4C 的机器,25KB 数据文件,5w 的 QPS 直接把 CPU 打到 90%

这明显不符合业务需求啊,咋办?先无脑加机器试试呗

就在这时测试同学反馈压测的数据不对,最后一轮文件最大会有 125KB,雪上加霜

于是乎文件替换,机器数量整体翻一倍扩到 80 台,服务端 CPU 依然是瓶颈,QPS 加不上去了

简单一招竟把nginx服务器性能提升50倍

到底是哪里在消耗 CPU 资源呢,整体架构已经简单到不能再简单了

这时候我们注意到为了节省网络带宽 nginx 开启了 gzip 压缩,是不是这小子搞的鬼

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服务器性能提升50倍

nginx 作为家喻户晓的 web 服务器,以高性能高并发著称,区区一个静态数据文件就把应用服务器压的这么高,一定是哪里不对

第三次压测

明确了 gzip 在耗 CPU 之后我们潜下心来查阅了相关资料,发现了一丝进展

html/css/js 等静态文件通常包含大量空格、标签等重复字符,重复出现的部分使用「距离加长度」表达可以减少字符数,进而大幅降低带宽,这就是 gzip 无损压缩的基本原理

作为一种端到端的压缩技术,gzip 约定文件在服务端压缩完成,传输中保持不变,直到抵达客户端。这不妥妥的理论依据嘛~

nginx 中的 gzip 压缩分为动态压缩和静态压缩两种

•动态压缩

服务器给客户端返回响应时,消耗自身的资源进行实时压缩,保证客户端拿到 gzip 格式的文件

这个模块是默认编译的,详情可以查看 https://nginx.org/en/docs/http/ngx_http_gzip_module.html

•静态压缩

直接将预先压缩过的 .gz 文件返回给客户端,不再实时压缩文件,如果找不到 .gz 文件,会使用对应的原始文件

这个模块需要单独编译,详情可以查看 https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html

如果开启了 gzip_static always,而且客户端不支持 gzip,还可以在服务端加装 gunzip 来帮助客户端解压,这里我们就不需要了

查了一下 jdos 自带的 nginx 已经编译了 ngx_http_gzip_static_module,省去了重新编译的麻烦事

简单一招竟把nginx服务器性能提升50倍

接下来通过 GZIPOutputStream 在本地额外生成一个 .gz 的文件,nginx 配置上静态压缩再来一次

gzip_static on;

简单一招竟把nginx服务器性能提升50倍

面对 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 被打起来的原因就是出现了大量数据计算,在高并发请求前,任何一个环节都可能产生性能问题

作者:京东零售 闫创

来源:京东云开发者社区 转载请注明来源

点赞
收藏
评论区
推荐文章
liam liam
2年前
用上这个 Mock 神器,让你的开发爽上天!
前端的痛苦作为前端,最痛苦的是什么时候?每个迭代,需求文档跟设计稿都出来了,静态页面唰唰两天就做完了。可是做前端又不是简单地把后端吐出来的数据放到页面上就完了,还有各种前端处理逻辑啊。后端接口还没出来,我就得边写代码边测前端效果,又没有真实数据。有人建议用Mock工具,可是每个接口都要自己写Mock规则,这得浪费多少时间呀。等到后端好不容易把接口写出
liam liam
2年前
前端mcok原来可以如此丝滑
前端的痛苦作为前端,最痛苦的是什么时候?每个迭代,需求文档跟设计稿都出来了,静态页面唰唰两天就做完了。可是做前端又不是简单地把后端吐出来的数据放到页面上就完了,还有各种前端处理逻辑啊。后端接口还没出来,我就得边写代码边测前端效果,又没有真实数据。有人建议用Mock工具,可是每个接口都要自己写Mock规则,这得浪费多少时间呀。等到后端好不容易把接口写出
浅谈 HTTP 缓存与 CDN 缓存的那点事
HTTP缓存与CDN缓存一直是提升web性能的两大利器,合理的缓存配置可以降低带宽成本、减轻服务器压力、提升用户的体验。而不合理的缓存配置会导致资源界面无法及时更新,从而引发一系列的衍生问题。本文将分别将从HTTP缓存与cdn缓存的规则、流程、配置
Easter79 Easter79
3年前
springboot2之优雅处理返回值
前言最近项目组有个老项目要进行前后端分离改造,应前端同学的要求,其后端提供的返回值格式需形如{"status":0,"message":"success","data":{}}方便前端数据处理。要实现前端同学这个需求,其实也挺简单的,
Wesley13 Wesley13
3年前
UI2CODE再进化!结合Redux的框架升级!
背景UI2CODE的目标是通过分析视觉稿得到对应的代码,让AI提高开发效率。然而过去静态化页面的产出,不能得到业务场景的需求。针对于此,我们以UI2CODE自动化开发为基底,结合Redux的消息机制,将自动化生成的维度提升到页面的处理。透过框架,可自动化生成页面代码,并且具有数据驱动展示、消息派送等动态性能力。期望在复杂的业务场景下,简化开发的
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
Wesley13 Wesley13
3年前
5000多张数据表,如何用SQL迁移到数据仓库?
点击关注上方“SQL数据库开发”,设为“置顶或星标”,第一时间送达干货需求背景最近公司打算集中梳理几大业务系统的数据,希望将各个业务系统中的数据集中到数据仓库中。总共有5000多张数据表,但是好在业务数据量没有像电商那么庞大,也就几十个G。需求分析其实这个需求很简单,就是把这50
服务端应用多级缓存架构方案 | 京东云技术团队
20w的QPS的场景下,服务端架构应如何设计?常规解决方案可使用分布式缓存来抗,比如redis集群,6主6从,主提供读写,从作为备,不提供读写服务。1台平均抗3w并发,还可以抗住,如果QPS达到100w,通过增加redis集群中的机器数量,可以扩展缓存的容量和并发读写能力。同时,缓存数据对于应用来讲都是共享的,主从架构,实现高可用。
京东云开发者 京东云开发者
9个月前
系统存储架构升级分享
一、业务背景系统业务功能:系统内部进行数据处理及整合,对外部系统提供结果数据的初始化(写)及查询数据结果服务。系统网络架构:部署架构对切量上线的影响\内部管理系统上线对其他系统的读业务无影响分布式缓存可进行单独扩容,与存储及查询功能升级无关通过缓存层的隔离
京东云开发者 京东云开发者
9个月前
系统存储架构升级分享
一、业务背景系统业务功能:系统内部进行数据处理及整合,对外部系统提供结果数据的初始化(写)及查询数据结果服务。系统网络架构:•部署架构对切量上线的影响\内部管理系统上线对其他系统的读业务无影响•分布式缓存可进行单独扩容,与存储及查询功能升级无关•通过缓存层