性能瓶颈
最后,介绍一下实际分析J2EE应用性能的常用命令和工具。对于实现一个高性能的J2EE应用来说,掌握了J2EE调优的理论经验还是不够的。掌握性能监控,发现瓶颈和问题诊断才是保证J2EE系统持续高效运行的关键。
瓶颈指的是限值所有吞吐操作以及严重影响反应时间的系统内资源。在分布式系统内寻找并纠正瓶颈是非常困难的，需要有经验的团队来解决。瓶颈会发生在服务器上，程序代码中，应用服务器上，，或者网络，硬件上。经验表明，瓶颈很容易发生在如下地方：数据库连接与队列中；应用服务器的程序代码中；应用服务器和web服务器硬件上；网络和TCP配置中。实际中可以着力对这些环节进行监控。
操作系统监控
操作系统层面的性能监控主要是对内存、CPU、I/O和交换区的使用情况进行监控分析。windows平台可以通过任务管理器和perfmon工具查看。如果是unix系统可以使用stat系列命令(vmstat, mpstat, iostat)监控内存、CPU和I/O的即时变化,使用swap命令查看交换区的使用情况。如果操作系统安装了top、topas、glance等使用工具,则使用top、topas、glance将能更为方便地看到webLogic进程对操作系统的内存,CPU和I/O资源使用的即时变化情况。
而网络方面的性能可以通过ping和netstat等命令来监控,主要几个关键的网络统计值,如数据包再发送、重复数据包和数据包侦听丢失。
说明:本文提到的unix命令并非适用所有操作系统,仅供参考。
数据库监控
数据库层面的监控这里为9i为例来说明,可以采用oracle自带的工具Oracle
Interprise Manager Console来监控session和sql的执行情况。还有专业的数据库监控工具可以使用,比如QUEST的spotlight()可以非常形象和直观地对Oracle数据库的CPU、内存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等参数进行即时监控,并自动对不正常的参数以红色显示。
webLogic监控
JVM监控
采用参数-verbose:gc 来分析JVM的GC非常繁琐，而且不直观。使用-Xloggc:gc.log 参数将GC日志写入文件,采用GC 工具HPjtune ()进行分析,可以轻松看出当前jvm参数配置是否合理。
严格意义上来说HPjtune是一个分析工具,不是监控工具。这里不得不提及jRocket,Intel平台上最快的JVM, 在webLogic启动命令中增加-Xmanagement参数,就可以执行beajrockit81sp3_142_04 in下console命令监控webLogic的内存使用和CPU负载情况。设置Tools/Preferences菜单中的Mode of operation属性为developer, jRocket将提供Method Profiler工具，她能够将所有在JRockit java虚拟机上执行的成员方法的调用次数、执行的总时间和每次调用的执行时间都统计出来，进行代码级调优，这是jRockit的又一大优势。
Console监控
webLogic Console除了管理配置功能之外,提供了丰富的监控功能。通过webLogic Console，首先我们可以查看服务器的运行情况。
Server监控
通过使用服务器的Performance Monitoring选项卡，可以查看到请求吞吐量，执行队列积压情况以及JVM栈利用情况。而通过点击Performance Genaral选项卡中” Monitor all Active Queues...”可以查看所以执行线程的当前统计数据。此外Monitoring选项卡还可以监控JTA和JMS等Service的情况。
JDBC监控
在连接池Monitoring选项卡中，webLogic Console为每一个数据库连接池提供了实时统计信息。其中有三个重要参数可以反应webLogic Server的健康状况：Connections High、Wait Second High和Waiters High。Connection High表示从服务器启动开始后到达池的最大连接数量，如果大于池的最大数量，则需要调整Maxium Capacity。Waiters High表示在没有可用连接的情况下，应用程序等待连接的最大个数。我们可以根据Waiters High的大小调整连接池容量。更多的参数可以通过Customize this view链接添加,参数含义参考:。
5.4.2.3 web监控
web Application Monitoring选项卡可以监控web应用的Session个数,以及Servlet的响应情况,激活Session Monitoring Enabled可以获取所有session的统计情况。更多信息请参考:
。
5.4.2.4 JMS监控
Welogic Console JMS监控功能比较多,不仅在Server JMS Monitoring选项卡可以监控Active JMS Connections, Pooled JMS Connections和Active JMS Servers的连接和使用情况。还可以监控JMS Session Pool、Active JMS Destinations和Durable Subscribers的消费和生产情况。比如,我们可以监控到JMS Queue的接收和消费消息的数量和字节数。有关JMS监控的详细情况可参见:。
5.4.2.5 EJB监控
EJB监控包括对SLSB,SFSB,Entity Bean,MDB四种EJB的监控。本人认为EJB监控提供了非常丰富的运行时统计信息(),非常有利于我们对EJB进行性能调优。
SLSB选项卡为用户提供实例池的运行时统计信息。Pool Miss Ratio 表示实例池的Miss率,Pool Waiter Total Count 表示线程等待bean 实例的累计时间,Pool Timeout Total Count表示超时的线程数。当Pool Miss Ratio较大时,可以增加max-beans-free-pool。
SFSB可以关注Cache Miss Ratio和Activation Count。Cache Miss Ratio过大时,调大max-bean-in-cache未必有帮助,需要尝试不用的max-bean-in-cache以获得最低的Cache Miss Ratio。激活将严重减慢应用程序的速度,如果某一个bean的Activation Count的值过高，那么需要考虑增加max-bean-in-cache的大小。
Entity Bean结合了SLSB的free pool和SFSB的cache。可以结合上面的策略进行监控。
而MDB仅比SLSB多一个参数JMSConnection Alive,报告EJB是否成功连接到JMS目的地。
更多Console监控信息可参见。
5.4.3 实用工具分析
webLogic除了提供Console进行应用监控之外,用户还可以编写JMX程序或者通过SNMP协议进行监控。而QUEST Spotlight for webLogic Server提供了类似webLogic Console类似的监控功能,并对异常情况显红。
这里不得不提到实战中经常用来分析性能瓶颈的工具THREAD DUMP,统一的命令是使用 weblogic.Admin 命令 THREAD_DUMP。而在 windows上还可以使用+ 来创建诊断问题所需的线程转储Thread Dump,而在unix上使用kill -3 命令。我们从中可以看到webLogic后台线程的运行情况,通常需要每隔10秒左右持续执行几次以助诊断问题。更多信息可以参考BEA实战集锦。
5.5 应用程序分析
应用程序分析除了凭借程序员丰富的经验和敏锐的洞察力去人工检查代码之外,使用厂家的工具也是节省时间的不错选择。目前市场上有Borland Optimizeit Enterprise Suite和QUEST Jprobe两个产品可以用来分析性能瓶颈,垃圾收集,内存泄漏,线程死锁和代码复盖等。Hpjmeter是一个免费的工具,也具有以上类似的性能分析功能。
而Borland Optimizeit Server Trace,HP OpenViewTransactionAnalyzer和MercuryJ2EE breakdown都可以用来分解J2EE应用从客户端访问到最终数据库操作每一层次花费的时间,甚至精确到每一个方法的执行时间。Server Trace还具有检查内存泄漏，连接泄漏和错误警告等功能,一般在环境中使用。而HP OTVA的优势在于运行时监控,LoadRunner优势在于。
总结(目录)
J2EE调优是一门实践和经验科学，是一个复杂而往复的过程。其原则是：合理。合理,看似简单,细细品味,意味深长。本文所述的调优策略并不是一成不变的，只是为了给大家一个参考建议，让大家少走弯路，关键是根据实际环境调优。欢迎有兴趣的朋友在论坛上积极讨论和批评指正。 |
