监控分析思路及简单举例

1、响应时间一般要求

1）一般页面响应时间要求

响应时间<2s  快

响应时间<5s  能接受  

响应时间>8s  慢

 

2）一般接口调用时间标准

响应时间<100ms  快

100ms<响应时间<300ms  能接受

响应时间>500ms  慢

 

2、监控分析思路

思考：出门发现钱包不在身上，疑是丢了，你该怎么办？

出门有没有带钱包-->没带，回家看是否在家-->没在家，回忆最后一次见钱包是什么时候

                -->带了，回忆在哪些地方会拿出钱包，这一路是否碰到小偷-->不确定，

再原路返回查找

联想：我们做性能监控分析也基本这个思路，首先要知道系统架构，然后才能知道请求流经哪些环节，根据问题，针对性的监控分析相应指标。

下面以最简单的架构来说明影响性能的因素，如下图

     

  如上，影响性能的因素有：负载机性能、网络、硬件（cpu、内存、磁盘）、web容器连接池、业务逻辑代码、gc、db连接池、sql执行时间

  附加，登录建立建立http连接伪代码：

uname = input(name)

pwd=input(pwd)

uid=select uid from user where name=uname and pswd=pwd;

if(uid = null){

    system.out.print('用户名密码错误')

}else{

    ...

}

 

3、监控分析步骤

登陆响应时间长，监控哪些，怎么监控？

1）了解系统架构图并画出

2）根据系统架构图，画出被测接口的数据流图，并列出可能存在问题的每个点

3）

a:要么从简单的开始排查（负载机-网络-硬件）-（容器连接池、db连接池）-sql执行效率--gc--代码逻辑；

b:要么通过系统日志打印出接口及sql或者web容器排队时间（非必须），然后根据时间去判断可能存在问题的点，缩小问题的范围；

 

4、开发打印时间，问题分析举例

1）时间说明

* 工具测试响应时间：client发起请求到client接收请求

* 接口响应时间：进入接口程序到跳出接口程序所用时间（硬件、代码业务逻辑、GC）

* sql执行时间：即，网络、建立tomcat连接、GC 、db连接、执行sql所用时间

 

2）问题分析事例

* 工具rt=10，开发日志打印，接口=2s,db=1s，慢在哪？

--可能原因：负载机、网络、连接池

--主要问题：都有可能

* 工具rt=10，开发日志打印，接口=9s,db=1s，慢在哪？

--主要矛盾点在接口，可能出问题地方：硬件、代码业务逻辑、GC

--主要问题：可能服务器（排队）

* 工具rt=10，开发日志打印，接口=9s,db=8s，慢在哪？

--主要矛盾主要矛盾db，可能出问题的地方：网络、db服务器硬件、建立数据连接）、sql执行效率、web容器连接

--主要问题可能：sql执行效率

 

5、负载机问题举例

①银行协议某协议，只允许以进程方式运行，测试时单机最大并发是50，tps=500，此时负载机、服务器cpu、内存、io、tcp/ip连接数、网络都没任何问题，单机并发>50时，tps小于500，负载机、服务器cpu、内存、io、tcp/ip连接数、网络都没任何问题，服务器cpu使用率还下降了一点，分析是什么原因？

原因：16核cpu,1个cpu同一时间只能处理1个请求，理论上处理16个进程最合适，实际是50个时能达到最大，大于50个进程数量大，导致cpu上下文切换

②分布式三机器作为负载时，tps只能达到800，分析什么原因？

分布式有性能损耗，但也不至于只有800，查看服务器64核cpu，基本打满，此时是cpu满导致TPS上不去。

附，负载机问题排查方法：负载机排查方法，1个负载机，50并发，rt8秒，2个负载机，每个25并发，rt5s,这就是负载机问题，若rt没啥变化，则不是负载机问题

更多内容欢迎关注微信公众号查看