zoukankan      html  css  js  c++  java
  • 利用Oracle RUEI+EM12c进行应用的“端到端”性能诊断

     

    概述

    我们知道,影响一个B/S应用性能的因素,粗略地说,有以下几个大的环节:

    1. 客户端环节

    2. 网络环节(可能包括WAN和LAN)

    3. 应用及中间层环节

    4. 数据库层环节

    能够对各个环节的问题进行“贯穿“的诊断,才能算是”端到端“的诊断。

    能够进行这种类型的诊断的工具很多,我们后面会分别介绍,今天只是给大家看看利用Oracle的工具软件进行从最前端到最后端的应用性能诊断的例子。

    涉及的Oracle软件产品有以下几个:

    1. RUEI(真是的客户体验洞察)
    2. EM12c 基础框架
    3. weblogic监控模块
    4. JVMD(java虚拟机诊断)
    5. Oracle数据库监控相关模块

    上面列出的产品其实都是Oracle Enterprise Manager产品的组件,我们先简单介绍一下不是那么普及的软件:

    RUEI介绍

    RUEI(Real User Experience Insight)是从客户体验角度,量化地衡量一个应用的性能工具。利用传统方式,我们只能从后端,从资源消耗的角度;或者,从前端,从用户的感性评价角度去衡量一个应用的性能。比如,我们可以从后端看主机的CPU消耗,看数据库的等待事件等等,或者利用调查问卷,调查用户的实际使用感想,但是往往得到的都是,诸如“太慢“,”容易死机“,等等非常感性的评价,最终用户从来不会准确地告诉你量化的评价,比如:页面到底花多长时间才载入完成?

    而RUEI可以告诉这些信息,RUEI利用网络嗅探技术,抓取B/S应用客户端和服务器端之间的数据包,分析其中的时间戳,通过相应的算法,得到应用用户访问应用的量化的性能数据。

    RUEI的基本原理图是这样的:

    clip_image001

    JVMD介绍

    JVMD最早叫AD4J,Application Diagnostic for Java,是单独的产品,后来慢慢被Oracle整合进EM12c,它是安装在J2EE应用服务器上的诊断工具,利用采样算法(Oracle宣称不是BCI方式--字节码注入方式),分析得到应用模块的性能信息。JVMD可以进行live thread分析,同时可以还原 应用的SQL调用,对从中间层跨越到数据库层进行诊断帮助很大。

    因为涉及的产品很多,如果讲具体的配置方法,文章会很长,所以今天只看案例,具体的方法,如果大家有兴趣,后续可以在其他文中继续介绍,也可以参考海天几位专家编写的《Oracle云管理平台:企业管理器12c实战指南》,书里有详细的配置方法。(也算小小做个广告,哈哈)

    案例

    某省机关新上应用,存在一些性能问题,希望我们帮忙进行诊断和优化。客户的应用是B/S架构,结构相对简单,客户端访问apache http server,由apache负责处理静态页面,动态页面转发给后端的weblogic服务器集群,后台数据库是Oracle。

    在部署了RUEI和EM12c(weblogic监控,JVMD,Oracle数据库监控),以后,利用工具进行诊断:

    (为了便于大家理解,每个环节我都只用尽量少的信息来说明问题,实际情况可能复杂得多。)

    首先利用RUEI看总体情况:

    clip_image004

    绿色代表客户满意的访问量(2秒内页面返回),黄色代表正常的访问量(2~4秒页面返回),红色代表用户“愤怒“的访问量,4秒以上返回。(页面满意度的时间可以由客户自己设置)

    总体来看,情况似乎可接受。

    再看从RUEI角度看,客户端,网络,服务器三个环节的性能信息:

    clip_image008

    除了个别的页面会有浏览器忙时间(比如浏览器执行JS这样的动作耗时)有非常少量的耗时之外,大量的页面浏览器耗时非常少,少到软件认为可以忽略的程度(显示为0毫秒)

    从这张图上还可以区分出是网络慢(每次点击传输时间),还是服务器慢(每次点击的服务器时间)。

    显然,服务器时间是占“大头“的。

    下面再进一步分析,到底是哪些页面请求消耗服务器时间较长:

    clip_image012

    找到耗时长的页面,如果在http端或weblogic端启用了ECID(运行上下文ID),我们就可以直接从RUEI里面下钻到JVMD,进行下一步的诊断。我们这个案例里面,客户没有启用ECID,所以我们只能进行手动的“下钻“。

    从RUEI中得到的最耗时的页面: XXXXXFrame.do,在JVMD中用此request,最为条件,作为JVM Thread 信息的过滤条件:

    clip_image015

    得到执行或这个request的thread的具体信息:

    clip_image017

    点击上图中绿色显示的等待,得到单一thread具体的分析信息,其中会有thread等待的SQL的信息:

    clip_image023

    在进一步点击SQL ID,就进入到数据库的SQL信息页面:

    clip_image027

    其实一旦找到SQL语句,对于DBA来讲,问题就简单了。篇幅有限,就不再贴图了。

    这个案例重要的不是结果,而是过程,如果我们没有这样的工具,我们可能会面临几个问题:

    1. 无量化的客户体验诊断
    2. 无法区分各环节具体耗时(客户端、网络、服务器)
    3. 在服务器端的诊断效率很差
    4. 需要人工进行页面请求和SQL的关联,效率很低,甚至有时,没有开发商的帮助,是不可能完成的任务

    现在,利用Oracle的这些工具,可以大幅提高诊断的准确率和效率,同时还能给客户看到量化的客户体验数据。

  • 相关阅读:
    大小端判断
    引用计数
    STL_ALGORITHM_H
    书单一览
    GIT版本控制系统(二)
    JS随机数生成算法
    STL学习笔记--临时对象的产生与运用
    乱序优化与GCC的bug
    你的灯亮着吗?
    交换机和路由器
  • 原文地址:https://www.cnblogs.com/raobing/p/6177820.html
Copyright © 2011-2022 走看看