| 结合第三方工具工具对Weblogic进行调优 |
|
| Servlet/JSP | ||||||||||||||||
| 作者是 Administrator | ||||||||||||||||
| 2007-12-02 03:10:25 | ||||||||||||||||
|
随着客户对系统性能的要求越来越高,对于任何系统来讲,如何保证系统的性能并且能够在出现性能问题之前可以预测和定位到问题,成了关键。系统上线之前的系统测试和上线之后对整个系统各个环节的性能监控是确保系统以优异性能运行的方法。 去年的年末写了篇关于如何简单使用JPROBE发现和定位J2EE应用中的性能瓶颈,JPROBE是QUEST公司的一个针对开发过程中应用程序的性能优化工具,但这不能满足上面提出的对于系统全面的性能监控和管理要求。针对这种要求,结合目前市场上的性能分析,调优和管理工具,比如IBM Tivoli、HP Openview等,这类工具的主要功能是对整个系统进行管理;另外一些,比如Wily,Veritas i3等,这类工具也具备一定的管理和对整个系统进行监控的能力,同时对某一技术层次拥有非常出色的调优和监控能力;其他的工具如Quest JProbe就如上面介绍的一样主要是针对开发过程中程序级别的性能优化。 本文将结合WILY和WEBLOGIC,以目前流行的应用架构来描述如何使用WILY这个工具对分布式系统进行全方位的性能监控和管理。以往针对J2EE的调优很多都是依靠开发人员或者是厂商技术人员根据经验来对问题进行定位和调优,不能做到对系统全方位的了解。借助于WILY之后,可以从客户体验出发到具体的一个SQL语句进行深入细致的分析,来完成对系统的性能的监控和管理。 Wily公司成立于1998年,其第一个投资方是BEA,对WEBLOGIC有很好的支持。 Wily的核心产品是InterScope,包括IntroScopeEnterprise Manager, IntroScope Agent, IntroScopeWorkStation.通过IntroScope可以明确的显示出在J2EE应用程序的什么为止出现了什么问题,比如在应用性能下降时,查明J2EE应用系统的什么位置导致问题是一个非常麻烦的工作,借助IntroScope将会变的非常简单。 Wily Introscope的系统架构如下图
Wily IntroScope特点
通过IntroScope的结构图可以看到,核心部分为IntroScope的Enterprise Manager,通过部署在应用中的各种不同AGENT来收集系统运行中的各项性能指标数据,汇总到EM进行分析,并能利用对历史数据的分析对系统未来的性能表现进行评估;分析的结构可以具体的定位到什么位置除了什么问题,并将问题进行分类反馈到相应的系统维护人员,比如网络,系统硬件维护人员,或者是开发和测试人员,对出现的问题进行调整。 Wily与Weblogic的集成
可以看到包括系统资源在内的各种性能指标,和J2EE应用中各种组件的性能指标,通过配置可以跟踪到某一个具体的JSP或者是SERVLET的性能情况,并且可以配置在某一性能指标达到指定的阀值后进行报警操作。 通过提供的Transaction Trace功能来分析超过指定时间的某一具体Transaction的内部情况。
通过树状结构可以看到事务内部的调用情况并且快速的定位到某一有问题的操作,通过该技术可实时跟踪生产系统中的某个具体事务问题,提供事务的执行路径和组件响应时间的详细信息,如上图。并能及时修正事务的性能问题。
除此之外该PowerPack包还提供了针对WEBLOGIC系统运行的一个性能查看控制台,通过该控制台可以直观的监控系统的那一部分出了问题,并且通过控制台可以方便的定制所关心的各种性能指标,定制后能通过浏览器的方式查看整个系统的运行情况。
配置启动步骤
安装步骤,只需解压缩PowerPack包到BEA的安装目录内即可(其他目录也可以,在配置的时候进行指定即可);
配置启动完成后,通过设置相应的监控性能项,在控制台中可以通过各种不同类型的图表来观察系统的运行状态。 如何发现系统性能问题? 模拟运行步骤
压力模式设置
可能出现的性能问题和观察到的性能指标特征描述
10个并发系统的线程使用情况,通过WILY获取
PendingRequestCurrentCount=0,WaitingConnectionCurrentCount=0,表明没有等待的request,系统响应很快。 10个并发系统的JDBC使用情况,通过WILY获取
Concurrent Invocations 最大值为8,并且平均查询的时间曲线表现也比较平稳。 20个并发系统的线程使用情况,通过WILY获取
ExecuteThreadCurrentIdleCount=0,PendingRequestCurrentCount开始有变化,对比10个并发用户的线程使用情况,很明显可以看出在20个并发的压力下,系统的线程资源开始不足。 20个并发系统的JDBC使用情况,通过WILY获取
平均查询时间有比较大的起伏,运行一段时间后可以看到该值为0,Connection Count的值也保持不变,基本不响应获取连接请求。这个时候访问系统页面,无法进入。 结论 |
||||||||||||||||
| 最近更新 ( 2007-12-02 03:10:25 ) | ||||||||||||||||












