软件测试


网站首页 | 软件测试论坛 | 软件测试培训 | 软件测试博客 | 软件测试杂志 | 软件测试沙龙 | 软件测试下载 | 软件测试顾问
业界新闻 | 软件测试人才 | 软件测试技术 | 软件测试工具 | 行业软件测试 | 软件测试管理 | 软件质量专栏 | 软件开发专栏
当前位置:首页>>软件测试技术>>性能测试>>正文
BEA WebLogic平台下J2EE调优攻略三
文章出处: 作者:zhouhg 发布时间:2007-03-06
第二章 应用服务器调优
2.1 JVM调优

2.1.1 垃圾收集和堆大小
  垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)是指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间。堆越大,GC频度低,速度慢。堆越小,GC频度高,速度快。所以GC和堆大小是一组矛盾。为了获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jdk: -Xloggc:)以打开详细的GC输出。分析GC的频度和时间,结合应用最大负载所需内存情况,得出堆的大小。
通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms=-Xmx。而为了防止内存溢出,建议在生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G以上是不可取的,在调整内存时可能需要调整核心参数进程的允许最大内存数。对于sun和hp的jvm,永久域太小(默认4M)也可能造成内存溢出,应增加参-XX:MaxPermSize=128m。建议设置临时域-Xmn的大小为-Xmx的1/4~1/3, SurvivorRatio为8。

  为了获得更好的性能,建议在启动文件设置WebLogic为产品模式,此时sun和hp jvm JIT引擎为-server,默认情况下打开JIT编译模式对性能也有帮助。调整Chunk Size和Chunk Pool Size也可能对系统的吞吐量有提高。此外还需关闭显示GC: -XX:+DisableExplicitGC。

  当然在Intel平台上使用jRockit(使用参数-jrockit)无疑大大提高WebLogic性能。

2.1.2 jRockit调优
  jRockit支持四种垃圾收集器:分代复制收集器、单空间并发收集器、分代并发收集器和并行收集器。默认状态下,JRockit使用分代并发收集器。要改变收集器,可使用-Xgc:,对应四个收集器分其他为gencopy, singlecom, gencon以及parallel。为得到更好的响应性能,应该使用并发垃圾回收器:-Xgc:gencon,可使用-Xms和-Xmx设置堆栈的初始大小和最大值,要设置护理域-Xns为-Xmx的10%。而如果要得到更好的性能,应该选用并行垃圾回收器:-Xgc: parallel,由于并行垃圾回收器不使用nursery,不必设置-Xns。

  如果你的线程大于100或者在linux平台下,可以尝试使用瘦线程模式:-Xthinthread,同时关闭Native IO:-Xallocationtype:global。

  jRockit 还提供了强大的图形化监控工具Jrockit Management Console。欲详细了解JRockit可访问:
http://edocs.bea.com/wljrockit/docs81/index.html


2.2 Server调优
  WebLogic Server的核心组件由监听线程,套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求的套接字复用器。然后套接字复用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。当有一个请求出现在执行队列中时,就会有一个空闲的执行线程从该队列中取走发来的该
请求,并返回应答,然后等待下一次请求。因此要提高WebLogic的性能,就必须从调整核心组件性能出发。

2.2.1 尽量使用本地I/O库
WebLogic Server有两套套接字复用器:Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出 java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置。


2.2.2 调整默认执行线程数
  理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。 WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多,花费在线程切换的时间也就越多,线程数越小,CPU可能无法得到充分利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整。当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000,则最好每个CPU小于50个线程, 以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threads Increase设置为0,同时不应改变优先级的大小。


2.2.3 调整连接参数
  WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小,默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。


2.2.4 创建新的执行队列
  创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级, 这里优先级不应设为9或者10。 定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后,用户需要为应用程序的J2EE组件配置分配策略,以便它可以找到新的队列。举个例子:要将 servlet或jsp捆绑到一个特定的执行队列,必须替换web.xml文件项,将wl-dispatch-policy初始化参数设置为自己的执行队列名。


servletname
/directoryname/deployment.jsp

wl-dispatch-policy
NewExecuteQueueName



  我们可以为一个jsp或者servlet乃至一个WEB应用设置自己的执行队列。同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MDB,建议使用自己的执行队列。


2.3 JDBC调优
2.3.1 调整连接池配置

  JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗,建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

  增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。

  尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

  最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准:
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html

2.4 WEB调优
2.4.1 调整WEB应用描述符

  WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。 同时生产环境下无需检查Jsp和servlet:JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSPKeep Generated 和JSPVerbose对性能也有帮助。此外,还可以对jsp进行预编译,有两种方法:激活precompile选项;使用weblogic.appc事先编译,建议采用后者。

2.5 JMS调优
  1. 增加-Dweblogic.JMSThreadPoolSize=n(至少为5),以提高处理JMS的线程数,在jRockit上增加-XXenablefatspin以减少加锁冲突;
  2. 采用文件存储策略,将同步写策略设置为Direct-Write,同时在windows平台上启用磁盘写入缓存;
  3. 使用分布式目的地时,激活连接工厂Load Balancing Enabled ,Server Affinity Enabled;
  4. 为减少服务器不必要的JMS请求路由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的 WebLogic实例上,集群环境下,则最好将连接工厂部署到集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置;
  5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置, 激活Messages Paging Enabled和Bytes Paging Enabled,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;
  6. 在运行WebLogic Server进程之外的生产者务必使用流控制, 并增大Send Timeout;
  7. 将JMS Server Expiration Scan Interval设很大的值,能禁止主动扫描过期消息;
  8. 使用FIFO或者LIFO方式处理目的地消息;
  9. MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。


2.6 EJB调优
2.6.1 调整pool和cache

  initial-beans-in-free-pool定义SLSB启动时实例的个数,默认为0,可以调大到正常并发数的大小,以减少初始响应时间。 max-beans-in-free-pool为最大个数,默认1000对SLSB来说,在频繁创建和删除实例的情况下很有帮助,一般不用调整,至少设为默认线程数,过大容易造成内存溢出。而对Entity Bean来说,由于是匿名的,所以当频繁使用finder、home和create方法时可以调大。

  对SFSB来说,尽量将max-beans-in-cache参数设置得足够的大,以满足Bean实例对最大并发用户数的要求,可以避免有状态会话 Bean过多的钝化行为。而idle-timeout-seconds尽量设置小,如果SFSB不用于存储Web应用会话状态可以设置为0。

  对于Entity Bean来说, max-beans-in-cache同样可以首先采用默认值1000,监控实例缓存和钝化的情况,再做适当调整。

  并行策略concurrency-strategy定义了实体Bean如何管理锁,有四种策略: Exclusive、Databse、ReadOnly、Optimistic。效率依次提高,可靠性依次降低,尽量避免使用互斥策略,如果Bean无需更新操作,使用只读策略,更甚的是,如果Bean的内容不会改变,可设置read-timeout-seconds为0,乐观并行策略时采用事务间缓存策略,在entity-cache描述符中将cache-between-transactions元素设为true。


2.6.2 优化事务隔离级别和事务属性
  对EJB组件来说,有四种事务隔离水平:

  • TRANSACTION-SERIALIZABLE:在处理完成之前拒绝其他处理的读入、可扩展性或插入数据操作;
  • TRANSACTION-REPEATABLE-READ:防止处理修改正在被其他处理调用的数据;
  • TRANSACTOIN-READ-COMMITTED:防止对正在被其他处理修改的数据执行写锁定;
  • TRANSACTION-READ-UNCOMMITTED:允许处理读入未受权的数据以及允许在向结果中添加记录时可以忽略处理。

   以上隔离水平依次降低,效率和性能依次提高。因此,建议选用满足在业务数据完整性要求前提下水平最低的隔离级别。

  对于事务属性的设置也是如此,对于删除、修改和插入操作设置为Required,而对于只读操作设置为Supports或者NotSupports。


2.6.3 其他一些小技巧
  1. 利用finders-load-bean的默认值true,既可以避免“n+1”的查询问题,又可以提高系统的性能;
  2. 使用delay-updates-until-end-of-tx参数的默认值true,除非应用程序对某些变化有特别的要求;
  3. 应用程序在每个业务方法调用后不需要进行存在性检查,将check-exists-on-method设定为false,以提高程序的性能;
  4. 同一应用内, 将enable-call-by-reference设置为 true;
  5. reentrant设置为false,避免事先加载子数据。


第三章 数据库调优
3.1.1 Oracle性能优化
  Oracle9i的性能优化除了调整kernal之外就是主要对Oracle启动文件的调整,即调整SGA的参数。注意,不同操作系统不同位数的机器最优的参数不是一样的,这里主要有windows和unix之分,32位和64位之分。
首先需要调大进程数和游标数,一般默认的值对实际应用来说都比较小,比如说,进程数可以调到300,游标数可以调到500。

  其次,看一个经验公式: OS 使用内存+ SGA + session*(sort_area_size + hash_area_size +2M)<0.7RAM,通常认为此时的SGA比较合理。这里sort_area_size为64k, hash_area_size为128k(当排序多的时候需要增大sort_area_size,按调整后的值计算),session表示最大并发进程数,假设100个。假如1G内存的机器,OS占用200M,PGA占用200M左右,那么SGA可以设为400-500M,如果2G内存可以1G给 SGA,8G可以5G给SGA。不过对于32位数据库来说,通常最多只能使用1.7G内存。

  然后,SGA内参数设置的基本原则是:data buffer 通常可以尽可能的大,shared_pool_size 要适度,log_buffer 通常大到几百K到1M就差不多。具体的:data buffer 1G内存可以设置500M,2G设为1.2G,8G可设为5G 。shared_pool_size不易过大,通常应该控制在200M--300M,如果使用了大量的存储过程,可以根据SGA的值增大到500M,如果增大后命中率得不到提高,则增加是无益的。具体的:1G内存可以设置100M,2G设为150M,8G可设为300M。如不使用Java, java_pool_size 10-20M即可。large_pool_size如果不设置MTS,在20M -30M 即可,假如设置 MTS,可以考虑为 session * (sort_area_size + 2M)。

  最后,关于内存的设置可根据statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch 等view信息来考虑微调。


3.1.2 Oracle的其他调整
  为了Oracle高效率的运行,除了上面提到的内存因素之外,还有就是需要良好的数据库设计:表、视图、索引和日志的合理规划和建立。I/O的性能也是重要因素,应尽量减少页交换和页分配。此外,就是改善检查点的效率。

上一页 下一页


站内搜索
相关文章
◎BEA WebLogic平台下J2EE调优攻略二
◎BEA WebLogic平台下J2EE调优攻略一
◎性能测试分析报告评审规范
◎性能测试类型之我见
◎X银行营销服务系统性能测试小记续
◎X银行营销服务系统性能测试小记
◎性能测试VS负载测试VS压力测试
◎Web服务器日志分析工具点评
◎压力测试和性能测试的区别
◎性能测试(并发负载压力)测试分析-简要篇
◎Oracle Pro*C/C++游标和存储过程性能测试报告
◎如何测一个门户网站是否支持10万用户同时在线-转自51testing上的讨论
◎性能测试之场景设计思想
◎软件性能测试中常注意的事项
◎常用性能计数器说明
◎性能测试常见误区
◎LoadRunner的Apache的监控
◎什么是可伸缩性测试
◎如何调整压力测试工具
◎Oracle SQL 性能优化技巧
◎优化ERP应用
◎性能测试的容量评估
◎跟踪数据库性能变化
◎性能测试的准备
◎测试您的DB2数据库:用JMeter测量性能
◎Java性能
◎刨根问底 微软Vista操作系统详尽测试
◎WTC性能测试报告
◎怎样提高性能测试的效率和质量
◎关注10大E-mail邮箱性能
◎性能比较:事务处理控件
◎性能测试之协议分析
◎性能和容量规划(3)
◎性能和容量规划(2)
◎性能和容量规划(1)
◎性能测试基础知识-处理器调度程序性能
◎实际项目中可使用的性能需求
◎AIX 性能调优-内存、CPU篇
◎性能测试基础知识-性能的规划与实现
◎如何进行系统的容量规划管理
◎WebLogic Server 性能调优(三)
◎WebLogic Server 性能调优(二)
◎WebLogic Server 性能调优(一)
◎文件系统性能调优
◎系统性能测试方案
◎性能计数器解释
◎Windows DNA应用程序数据访问组件的强度测试
◎cdma2000 1xEVDO网络性能测试
◎对你的ASP程序作负载测试
◎一个大型集中项目的性能测试实例
热门文章
◎性能测试方法
◎压力测试计划实例
◎系统性能测试方案
◎性能测试指标介绍
◎带宽大小我心知 专业带宽评测工具
◎Oracle SQL 性能优化技巧
◎性能测试的准备
◎一个大型集中项目的性能测试实例
◎性能测试基础知识-性能的规划与实现
◎关注性能:压力负载
◎性能:软件测试的重中之重
◎性能测试及性能调整概述
◎怎样提高性能测试的效率和质量
◎AIX 性能调优-内存、CPU篇
◎性能测试(并发负载压力)测试分析-简要篇
◎性能测试
◎性能计数器解释
◎如何调整压力测试工具
◎WebLogic Server 性能调优(一)
◎性能测试之协议分析
◎性能测试常见误区
◎性能测试的容量评估
◎性能测试基础知识-处理器调度程序性能
◎性能和容量规划(1)
◎LoadRunner的Apache的监控
◎有效的用例编写规则
◎如何测一个门户网站是否支持10万用户同时在线-转自51testing上的讨论
◎Java性能
◎WebLogic Server 性能调优(三)
◎软件性能测试中常注意的事项
◎性能测试之场景设计思想
◎跟踪数据库性能变化
◎实际项目中可使用的性能需求
◎什么是可伸缩性测试
◎WTC性能测试报告
◎压力测试和性能测试的区别
◎测试您的DB2数据库:用JMeter测量性能
◎性能测试VS负载测试VS压力测试
◎调整压力测试工具
◎关注10大E-mail邮箱性能
◎对 Linux 内核进行压力测试
◎刨根问底 微软Vista操作系统详尽测试
◎WebLogic Server 性能调优(二)
◎路由器性能指标详解
◎对你的ASP程序作负载测试
◎NET Framework部署的性能调整
◎文件系统性能调优
◎Ad Hoc网络性能测试关键技术研究
◎性能和容量规划(2)
◎Java性能

Google提供的广告