9月16日晚，小王正美滋滋地等着周董的《说好不哭》上线，但是公司的oncall电话进来，说是现在公司活动页面加载越来越慢。接完电话，小王立马打开了电脑排查问题，不然自己真的要哭了。
小王利索地登上了公司的线上监控平台，发现慢请求越来越多。机智的小王立马想到，系统响应突然变慢，无外乎CPU占用过高或者Full GC次数过多这些原因。可是通过监控查看了当前的CPU和系统内存后，发现一切正常。
这下可把小王难住了，这到底是为什么呢？
还好小王机智，从监控大盘上看到，当前的下行带宽基本被打满了，或许这就是问题所在了。
通过监控日志，首先梳理了当前访问频次top 10的请求和返回体大小top 10的请求，通过对比这两个结果集，小王意外发现，有多个请求重合。小王立马拿出了纸，记下来了重合的请求，并将请求按发送方区分为由native或h5发出的请求。小王又在监控平台上对比了上周同时段这些请求的访问频次，发现当前频次大大地增加了，大约增加了几倍，再加上这些请求返回体大小较大，小王便怀疑是这些请求占满了带宽。
小王立马着手计算这些请求所占的带宽，计算方式如下：
1、拿到这些请求一分钟内的请求数量N。
2、将N除以60得到每秒请求数M。
3、将M乘以该请求的返回体大小(a kb)再除以1024得到每秒该请求的所占的大小b (兆)
4、将b乘以8得到该请求所占的实际带宽。
N/60*a/1024*8
通过以上算法，计算出这几个请求所占带宽并求和，发现已经占了总带宽的60%，问题应该就出在这里了。
小王第一反应就是看下这些请求是否是有人恶意刷单，但是排查后没有发现异常，那就无法通过限流拦截的方式降低频次。
那只能选择减少返回体大小了。常用的方法有两个，一个是请求走cdn，另一个是对返回体压缩。因为native发版需要提交应用市场，不能及时生效，这种方式只能排除，只能走以下两个方法了。
1、将H5页面静态化，请求走CDN
2、在nginx层开启gzip，对这几个特定的请求的返回体进行压缩
小王立马拿起手机联系了前端H5负责人，确认了相关接口的H5页面可以静态化，并请求对方立即响应发版。H5接口的问题解决了，剩下就是native发出的接口了。
小王接着研究了Nginx的配置。ngnix自身有如下参数：
开启和关闭gzip模式 gzip on|off; gizp压缩起点，文件大于1k才进行压缩 gzip_min_length 1k; gzip 压缩级别，1-9，数字越大压缩的越好，也越占用CPU时间 gzip_comp_level 1; 进行压缩的文件类型。 gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript ; nginx对于静态文件的处理模块，开启后会寻找以.gz结尾的文件，直接返回，不会占用cpu进行压缩，如果找不到则不进行压缩 gzip_static on|off 是否在http header中添加Vary: Accept-Encoding，建议开启 gzip_vary on; 设置压缩所需要的缓冲区大小，以4k为单位，如果文件为7k则申请2*4k的缓冲区 gzip_buffers 2 4k; 设置gzip压缩针对的HTTP协议版本 gzip_http_version 1.1;
通过gzip的开关，压缩文件的类型、gzip的压缩起点，再配合nginx的location使用，就可以达到对指定请求的指定返回体大小进行压缩了。
小王立马又打电话给了运维小马，小马立马按照对应的要求进行了ngnix的配置。
配置完一会儿以后，小王从监控上看到，带宽逐渐回落，在H5发布上线后，下行带宽回到了正常水平，而且相关页面加载也恢复正常了。小王长舒了一口气，擡头一看，正好赶上了周董的新歌上线。
但是想花3块钱怎么这么难呢？某播放平台进不去了……
更多文章，请关注公众号测试架构师养成记
