利用Oracle RUEI+EM12c进行应用的“端到端”性能诊断

共计 2167 个字符，预计需要花费 6 分钟才能阅读完成。

概述

我们知道，影响一个 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 的基本原理图是这样的：

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 看总体情况：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-12/138471.htm