标签：
声明
本文为Gleasy原创文章，转载请指明引自Gleasy团队博客
问题初级定位方法： 一感三看
一感，凭个人感觉，操作不流畅，有挫折感肯定有问题。
三看：
一看ajax请求的执行时间，网络条件好的情况下，超过400MS的肯定有问题；
二看静态内容(html，图片,js，css）等是否cache，没有cache肯定有问题；
三看同一个ajax请求的数量，如果连续有N个（N>3)以上同一个AJAX请求，肯定有问题；
问题深入定位方法
方法一：使用stopwatch，在程序中植入log记录执行时间，通过查看执行时间以定位出问题的代码段；
方法二：间隔重复可疑操作，观察记录CPU变化情况。用以观察是否有死循环或者大规模遍历。
方法三：恶意快速重复点击同一个功能按键20次，观察是否会重复发起后端请求20次，如果是，那么，也是有问题的。
方法四：使用SQL监控(druid)来观察每一个SQL执行次数，执行时间，从而发现热点问题
应用技巧
NO1. 弱化数据库
1.将数据库弱化为“存储”，避免使用数据库查询能力，尽量使用主键或唯一键进行精确读取动作，数据量不太大的表可以使用普通索引进行精确读取，避免使用范围查询(> < != between in)，禁止使用like，禁止使用子查询，联合查询，exists查询；
2.范围查询和like查询，一律使用索引平台CloudIndex替代；
3.子查询，联合查询，exists查询：一律在应用层进行逻辑拼装（如果数据量太大，可以使用Map-Reduce进行多线程计算，如果再大可以使用cloudjob进行分布式调度)
NO2. 善用缓存
1.提高缓存命中率为终极目标；
2.容易忽视的缓存问题：大量访问己被删除数据，由于数据不存在，缓存肯定不命中，导致频频访问数据库；解决方法是对己删除的数据做特殊缓存标记；
3.对写入性能要求极为苛刻的场景可以使用redis缓存-存储切换的方式进行异步写入：写入redis（标记为存储)，立刻返回，另起独立线程将写入数据同步至数据库，同步成功之后，将redis中相应数据标记为缓存。
NO3. 用好中间件
1. 对于写入性能要求苛刻（或写入并发量特别大的）且允许写入延迟的情况，使用CloudMQ中间件；比如发邮件，发微博，发留言等；
2. 定时任务（比如定时发送邮件，定时提醒），特别适合使用CloudJob中间件；
3. 对于消耗性任务（比如执行时间长且任务量大，消耗CPU资源），可以使用CloudJob进行分布式任务调度，将众多大任务放到N台后台机器上执行；
NO4. 批量操作(从前端到后端）
1. 前端批量，针对大量重复调用某一接口的情况，由于AJAX的异步性，可以将N个请求合并成一个请求，串行执行AJAX,策略如下(伪代码）：
| 01 |
var getDepartmentLinkByUid = function(uid,callback){ |
| 02 |
if(loading){cache.push({uid:uid,callbackup:callback}); return;} |
| 07 |
var realGet = function(){ |
| 08 |
var tmp = cache.splice(0); |
| 12 |
for(var i=0;i<tmp.length;i++){ |
| 15 |
tmp[i].callback(rdata); |
| 17 |
if(cache.length>0) realGet(); |
2. 缓存批量(承接上面的例子）
| 2 |
notcached = new ArrayList(); |
| 4 |
if(objects 不包含uid) notcached.add(uid); |
3. 数据库批量查询(承接上面的例子），批量更新缓存
| 1 |
notcachedData = select * from department where uid in (notcached列表); |
| 2 |
mset(notcachedData 生成的 map); |
大型WEB应用性能调优总结
标签：
原文地址：http://my.oschina.net/yygh/blog/516806
