跟我学调优------浅谈瓶颈定位

  搜遍大部分论坛 关于结果分析 都是IT163那点文章，或者是 段老师 那副经典的图 ，但是结果分析里面能显示什么，通过分析能给项目的开发（调优）提供多少帮助，怎么优化用户体验，这个问题能深入多细

 领导要的是 给研发写一份有指导意义的调优报告。。。里面要包含 系统问题，服务器资源使用问题，越细越好

结合段老师那张图 ，就是 LR测试结果里面 事务的响应时间包括了 网络时间和服务器时间 可以肯定的告诉你们，这个是可以实现的

目前我的理解就是  firstbuffertime里面的网络时间 就是 段老师图里面的网络时间，服务器响应时间与之对应就是A1+A2+A3（+N1+N2），

为什么我要强调 段老师的图，当我们区分出来了各个时间，就马上 知道系统目前的瓶颈在那里。。。。

而怎么去实现 每个具体的时间点 综合了N多好友的意见，主要在以下几点

结果分析中 ，我们要关注 页面下载时间细分图---（pagedownloadbreakdown）从这里 很清除的关注 2个时间

firstbuffertime 和receivetime

针对firstbuffertime 和receivetime我里面有文章详细介绍 这里就不啰嗦了

分析 : 1.fristbuffertime占页面时间比较长，receivetime却很少 ，经常遇到这个情况 这时候 打开第一次缓冲细分图，查看里面的网络时间和 服务器时间  ，一般都是服务器时间较长，如果网络时间长，直接定位网络问题

服务器时间长，也就是 A1+A2+A3比较长，初步判定服务器有问题 ，然后细化，查看页面组件大小图-----细分你关注的事务

此时查看页面组件大小，针对组件，很容易知道 静态组件和数据组件，页面组件比较大，考虑页面压缩，数据组件比较大，继续返回查看该数据组件的下载时间细分，如果接收时间比较短 ，就可以初步定位问题不是在数据库服务器，而是在应用服务器处理上 。

而如果数据组件的下载时间比较大该情况目前没有遇到----******不做分析

2.firstbuffertime 占页面比较少 ，receivetime比较大， 有2种可能，一种是返回的数据量比较大（一般都是这样），另外一种网络问题。这种问题也最好定位，通过页面细分图一般就能快速找到

3。关于A2， 这个我问过ZEE，他说可以监控，并且给了我关于orancle的监控SQL

但是我们用的MS SQL, 我使用的是 profile，别人说有相关计数器（偶不知道，你要知道告诉我 ） 测试结果分析

是重新跟踪对应的功能，获取 A2

******************今天就到这。。