近期的产品性能问题及解决方案

yjs

2015-03-23

1
2
3
4
5
6
7
主要问题有两个：
1.首页请求没有缓存，用户过来的请求是动态地址，而首页又比较大，造成很大的流量
2.定时刷新的请求，把所有的数据都返回了

解决：
1.首页开启GZIP
2.将定时刷新的请求进行拆分

2015-03-25

1
2
3
4
5
6
7
8
9
通过分析日志，查找规律后发现：
1.每天有大量无权限的首页请求
2.流量异常的请求，有很大一部分是没有权限的请求
3.流量从3.20日开始剧增
然后查看程序，发现3.20并未有代码修改，不过权限验证的代码存在问题，发现用户无权限后，通过header跳转试用页面，并未exit退出，header之后的程序仍然会执行，造成流量浪费。

解决方案：
1.排查无权限请求的来源
2.修改权限验证插件，验证失败后，中断程序

2015-03-27

1
2
3
4
5
经过和产品沟通，发现云计算客户端相对其他收费客户端，有个特点，就是免费用户也能登录。
而短线宝去年推出了一些试用活动，有的用户在试用结束后，仍然继续在使用云计算客户端。
另外也有些用户自己去官网下载，采用免费账号登陆的。
查询了CBAS中云计算版本客户端每日登录数，发现IP有8K-10K个，而实际收费用户每日登录数在4K-5K左右。
这就是为什么有这么多无权限请求的原因。

优化效果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
3.16：
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "16\/Mar"|awk '($7~/dxb\/index\/index/){x+=$10}END{print x}'
3989687736    26159次请求
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "16\/Mar"|awk '($7~/dxb\/index\/todaybroadcast/){x+##$10}END{print x}'
1701692320    36964次请求

3.19(开启了gzip，发现首页请求量有所减少，但是效果很小)：
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "19\/Mar"|awk '($7~/dxb\/index\/index/){x+=$10}END{print x}'
3011273964   27718次请求
(json请求则因为json格式的字符本身就压缩得比较小了，所以gzip效果也不明显)
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "19\/Mar"|awk '($7~/dxb\/index\/todaybroadcast/){x+##$10}END{print x}'
1288525810    34215次请求

3.20：
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "20\/Mar"|awk '($7~/dxb\/index\/index/){x+=$10}END{print x}'
3623189788   21991次请求
(拆分了json请求的数据，效果比较明显，减小了近三分之一，不过今天请求量要少一些，总体来看还是有效果的)
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "20\/Mar"|awk '($7~/dxb\/index\/todaybroadcast/){x+=$10}END{print x}'
880236261    28381次请求

3.27(前一天将资讯拆分和无权限中断程序的代码同步上去了，下面的统计数据截止17:30)：
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "27\/Mar"|awk '($7~/dxb\/index\/index/){x+##$10}END{print x}'
449214804    23075次请求
[root@zycs ~]# cat /usr/local/nginx/logs/yjs.access.log|grep "27\/Mar"|awk '($7~/dxb\/index\/todaybroadcast/){x+=$10}END{print x}'
681234353    30151次请求
可以看到，效果非常明显，特别是首页请求

poi

1
2
3
4
5
6
7
主要问题有：
1.统计类请求频繁更改数据库记录，导致后续的数据库操作都受到了影响
2.程序中有个脚本存在问题，导致冗余数据未及时清理，表记录数变大后影响查询效率

解决：
1.统计类请求，用memcache做了个队列机制，通过后端脚本批量更新
2.修正程序中的BUG

activity

1
2
3
4
5
6
主要问题有：
1.一推活动，请求量就会很大，一些页面会直接查询数据库

解决：
1.做数据缓存
2.考虑到活动的数据结构都很简单，可以尝试其他的key-value存储方案

cso

1
2
3
4
5
6
7
主要问题有：
1.查询联表很多
2.后端脚本存在冗余的外部http接口请求

解决：
1.将应用数据整理出来，单独存一张表
2.合并后端脚本，清理掉冗余的请求

zx

1
2
3
4
5
主要问题有：
1.请求量比较大，有的请求是动态地址，没有利用好缓存

解决：
1.做url伪静态处理