没有合适的资源?快使用搜索试试~ 我知道了~
诊断应用数据库的性能瓶颈.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 159 浏览量
2021-10-02
11:39:27
上传
评论
收藏 357KB DOC 举报
温馨提示
试读
25页
诊断应用数据库的性能瓶颈.doc
资源推荐
资源详情
资源评论
.
诊断应用数据库的性能瓶颈
时间:2004-07-22
作者:Peter Chapman,Rini Gahir
浏览次数: 3137
本文关键字:JDBC, 性能 ,监控, E, 瓶颈, 数据库
文章工具
推荐给朋友
打印文章
J2EE 的崛起
J2EE 作为 Web 应用开发的标准企业计算平台面世,其实力越来越强大,日益普及。J2EE 支
持遗留应用程序和接口、多种操作系统、分布式和群集式环境,以及高量关键任务应用程序,同
时支持安全和管理与监控。
通过提供一种开发分布式、可伸缩应用程序的框架和蓝图,J2EE 使公司及其开发者能够集中
注意力去编写模块化的定制应用程序代码,并且不必担心安全、资源管理和可伸缩性的细节。
行业领先的应用程序服务器,例如 BEA WebLogic Server,能提供许多功能和服务。多个
WebLogic 服务器实例的群集和故障恢复功能提供了可靠性、可用性和可伸缩性。它们也提供诸
如安全和资源管理之类的其他服务,例如执行线程池、E 高速缓存和 JDBC 池。第三方所写的
Java 数据库连接(Java Database Connectivity,JDBC)驱动程序进一步抽象和简化不同数据
库管理系统(DBMS)间数据存取的编码。
这就是一个强大的平台,该平台能够大大简化并且抽象开发分布式、高量企业应用程序的低
层细节。
J2EE 性能的挑战
听上去没有什么会出问题,是吗?的确如此,除了应用程序不能达到最终用户或者服务级协
定所要求的性能标准之外。一个开发项目和商业创新是否成功要视其迅速检测、诊断和解决这些
性能问题的能力而定。
由于它们的复杂性日益增加,与早期的僵硬应用程序环境相比,在这些多层的、分布式 J2EE
应用程序中的性能瓶颈更难以诊断。J2EE 环境包含多层相互连接的软件和硬件组件,它们相互作
用,满足任何既定的最终用户请求。性能团队的成员——设计师、开发者、应用服务器管理员和
数据库专家——他们有自己对系统的见解,而且可能拥有他们自己的经验仓库或者“设备中心”的诊
断工具。但是这个团队的成员怎样一同工作将问题分离出来呢?如果没有对 J2EE 系统所有组件的
全面广泛的了解,如果他们不能相互交互,那么一位性能专家怎样找出哪台服务器速度慢?哪个
组件速度慢?哪种资源不足?数据库引擎是主要瓶颈,还仅仅是一个次要因素呢?
这种挑战可能会使无准备的人或装备不良的人畏缩不前。这种困惑可能使团队的成员焦头烂
额,或者更严重时,他们会任意指责过失。
“是应用程序,还是数据库?”
公司里最常见的挫折就是面对表现不佳的分布式 J2EE 应用程序感到困惑:“它是应用程序,
还是数据库?我们应该从哪里开始修理?”通常情况下,会有人斗胆作出一种推测,不再继续在浩
繁的代码寻找错误的或者低效率的算法,或者放弃彻底搜寻 SQL 语句和数据库表格的作法。换句
WORD.
.
话说,他们挑出应用程序或者数据库(或者在最坏情况下,两个都选),并努力将从谜团中分离
出来的片断最优化。
令人遗憾的是,这种解决问题的观点经常是过度简化的,这是因为应用程序、数据库、
WebLogic Server 都不是在孤立地运转。对这个问题的一种综合解决方法需要提高对这个相互联
系的系统内所有三个部分的能见度:WebLogic 资源利用和配置、应用程序架构以及数据库查询
的执行,而且包括基本的硬件基础设施性能。
有了对这些子系统相互作用的了解,性能团队的成员就能有效地分离有问题的组件,并将问
题交给正确的职能专家进行处理。
对相互之间关系的了解是关键
在此,了解和相互关系是两个关键词。没有这两个关键词,检测和根除的要求就使诊断极其
艰难。
我们需要了解 WebLogic 服务器运行时 JMX 的性能度量。我们需要了解 SQL 查询的计时和
结构,以及数据库引擎所运行的存储过程。而且最重要的是,我们需要了解最终用户发出的请求
在跨越整个分布式系统时的端到端计时,而且所有的组件要与 JDBC 连接池交互,DBMS 的调用
要以显式的基于单个请求的方式来制定。
我们不仅需要了解方法层级的应用程序计时,而且需要了解每个组件与其他组件相互作用形
成应用程序架构的方式。大多数 J2EE 性能监视工具所提供的分离度量方法和 JDBC 计时都脱离了
应用程序架构,所以几乎是没有用的。分离的 SQL 语句执行响应次数也是如此,脱离了该语句产
生的位置、被调用的次数或者与其最终用户请求的数据库的相互作用,几乎也是没有用的。
理想的工具解决方案对定制的 J2EE 应用程序与 WebLogic 服务器资源和 DBMS 相互作用的
方法提供深入的洞察,并提供对这些相互作用怎样影响每个最终用户事务的总响应时间的深入理
解。这些相互作用的高级表现概述如图 1。
WORD.
.
典型的应用数据库性能瓶颈
现在或许你正在想:“现在理论知识足够了,我怎样修复我的应用程序呢?”下面的章节将讨论
性能瓶颈的三个主要类型,它们是通过测量和分析许多现实世界的 J2EE 应用程序的性能后提炼出
来的,包括几个卓越的金融、电信、以及“财富 100 强”制造业公司的 J2EE 系统。这绝不意味着它
是一个毫无遗漏的列表,或者是一个可以用来调优任何应用程序的、一步一步遵循的“调试清单”。
由于分布式的本质和错综复杂的架构,每个 J2EE 应用程序都有它自己的独特的性能特点,但是也
有一些需要避免的共同的缺陷。
下面我将介绍应用数据库的三种性能,其中具体的示例是通过运行 BEA PetStore 示 X 应用
程序收集的,并且采用 Quest Software 的 PerformaSure 收集和分析性能数据。
过量的数据库调用
“客户”端数据处理和结果集的卷动
到目前为止,在 J2EE 数据库应用程序中最严重的性能瓶颈来自从用户应用程序对数据库引擎
的过量调用。这些不必要的额外调用不一定是 SQL 查询的 Execute()或 Update(),但几乎总是
跟与数据库的其他交互有关,例如 ResultSet 操作。一个常见的错误是指定了过于精确的查询条
件,然后使用 ResultSet.Next()详细地搜寻返回的数据,每次一行。这种作法会使应用程序的性
能由 DBMS 内的数据集来决定——对于大的表格来说,搜寻量可能是巨大的;我曾见过客户站点
的数据所执行的每个 SQL 查询都向 ResultSet.Next()发出了超过 50,000 个调用指令。
如果有些数据处理必须在应用程序代码内进行,应考虑从 DBMS 大批取得所要求的数据,避
免让应用程序反复回调数据库,从数据集里取回每一记录。
例 1:过量的结果集卷动
WORD.
.
图 2 显示:当 PetStore 应用程序内的“mitorder”HTTP 请求执行 servlet、JSP 和 E 代码,
并最终调用 DBMS 的 SQL 语句时,该请求的 PerformaSure 重建。右边彩色编码的标尺表明哪
个方法执行迅速(冷蓝色),以及哪个方法是昂贵的热点方法(火红色)。右边的工具提示提供
了请求的全部计时和调用数。显然,在右边的数据库节点是一个热点,并且需要更进一步的调查。
通过放大所识别的热点,我们能看出该事务执行的全部 JDBC 操作的详细计时和调用数,例
如打开一个 JDBC 连接、“SELECT”SQL 语句的创建和执行、ResultSet.Next()卷动以及最后还
有关闭连接。E 方法“GetItem”被调用了 7 次(对应于 7 个 mitorder HTTP 请求),快速运行的
SQL 语句被执行了 7 次,并且在 ResultSet 中移动了 672 次。与执行实际查询相比较,过度地与
DBMS 反复交互反而花费了更多的时间!这不是一种可伸缩的架构——随着 DBMS 中的数据集增
长,并且随着更多并发的最终用户执行事务,这类性能问题只能会恶化。
两个查询而不是一个查询
另一个经验法则是将 SQL 查询和更新的设计留给数据库专家,因为他们对各种各样的表格大
纲和索引非常熟悉。编写 E 的开发者往往对他(或者她)想从数据库引擎获取什么样的数据,或
者需要更新什么样的数据有自己的看法。困难在于怎样编写执行任务所必需的最少、最有效率的
查询和更新。学会只选择在应用程序中真正需要的数据是至关紧要的。这样,降低了 RDMS 必须
执行的处理数量,并且将查询和网络中发送数据的数量极小化。
任何基于集合的处理都以 DBMS 实现最有效,而不是通过网络获取并在 WebLogic 服务器 E
层的应用程序逻辑内执行处理最有效。封装应用查询和更新数据的规则及条件的“业务逻辑”保存在
WORD.
.
E 层,而实际的实施细节最好由数据库引擎来处理。低级的查询处理逻辑,例如为临时表选择初
始数据,并基于该数据进行进一步的查询,最好由 DBMS 以存储过程的形式进行处理。
数据库连接池问题(DC)
连接池泄漏
当用户应用程序内的一个组件(通常是一个 E)从一个连接池请求一个连接、查询或者更新
某些数据,最后释放连接失败时,就会发生连接池泄漏。虽然通过检查 WebLogic JMX 性能度量
(“连接数目”和“等待数目”)以及观察 DataSource.GetConnection()缓慢的反应时间,能够很
简单地检测到一个连接池迅速达到它的最##接数目,但是很难在应用程序代码本身内准确指出泄
漏的源头。如果存在多个最终用户请求(因此应用程序代码有多个部分),这些请求从同一个
JDBC 连接池分配连接,这时找出连接池泄漏更加困难:到底哪个请求没有释放连接呢?
为了解决这个问题,需要一个工具,它能够基于单个请求明确地映射应用程序与数据源的交
互。下面的例子展示了 PetStore 的“mitOrder”HTTP 请求分配和释放与数据源连接的过程。
例 2:连接池泄漏
图 4 显示了两个 WebLogic JDBC 度量指示连接池泄漏的证据。第一个图显示连接池的连接
数目迅速增加到了连接池的最大数目——400 个连接。在连接池达到最##接数目的同时,等待连
接的请求数量(等待空闲连接的请求数目)不断增加,这表明可能已经发生了连接泄漏。但是连
接泄漏发生在源代码的哪个部分呢?
图 5 显示了“产品”请求,并且标识了该请求中两个单独的应用程序代码片分配和释放 JDBC 池的连
接。通过对这些区域的快速分析提供了关于连接池是如何使用的详细信息。
WORD.
剩余24页未读,继续阅读
资源评论
yunxidzh
- 粉丝: 60
- 资源: 30万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功