J2EE性能调优

BEA WebLogic平台下J2EE调优攻略----第一章 应用程序调优 
1.1.1 通用代码调优 
1.1.2 减小没有必要的操作
　　对象的创建是个很昂贵的工作,所以我们应当尽量减少对象的创建,在需要的时候声明它,初始化它,不要重复初始化一个对象,尽量能做到再使用,而用完后置null有利于垃圾收集。让类实现Cloneable接口,同时采用工厂模式,将减少类的创建,每次都是通过clone()方法来获得对象。另外使用接口也能减少类的创建。对于成员变量的初始化也应尽量避免, 特别是在一个类派生另一个类时。
　　异常抛出对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为, fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，VM就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。
　　此外, 建议关闭Debug输出,尽量少用串行化、同步操作和耗时昂贵的服务(如Date())。
1.1.3 使用合适的类型
　　当原始类型不能满足我们要求时,使用复杂类型。String和StringBuffer的区别自不必说了,是我们使用最多的类型,在涉及到字符运算时,强烈建议使用StringBuffer。在做String匹配时使用intern()代替equal()。
　　带有final修饰符的类是不可派生的, 如果指定一个类为final，则该类所有的方法都是final。
　　Java编译器会寻找机会内联所有的final方法,这将能够使性能平均提高50%。类的属性和方式使用final或者static修饰符也是有好处的。
　　调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。所以尽量使用局部变量。
　　ArrayList和Vector,HashMap和Hashtable是我们经常用到的类,前者不支持同步,后者支持同步,前者性能更好,大多数情况下选择前者。
1.1.4 尽量使用pool,buffer和cache
　　使用pool、buffer和cache能大大提高系统的性能,这在J2EE的大部分技术中都是适用的。
　　在WebLogic中就大量使用了池:JDBC Connection Pool、Socket Pool、Object Pool和Thread Pool。I/O操作中,buffer是必须的,特别是对大文件的操作,不然容易造成内存溢出。字节操作最快,所以尽可能采用write(byte [])，Buffered FileOutputStream比Buffered FileWriter要快,因为FileWriter需要Unicode到Byte的转换。
　　而后面讲到的JDBC、JSP、EJB和JMS我们都非常建议使用buffer和cache。为HttpServletResponse设置buffersize,使用wl-cache,缓存在JNDI树上获取的对象等等。
　　此外,使用JDK 1.4的非阻塞I/O对性能也有很大提高。 
1.2 JDBC代码调优
1.2.1 严格资源使用
　　JDBC代码调优最大的原则就是使用WebLogic的连接池,而不是自己直连数据库。在我接触的很多自己实现连接池的项目中,大部分遇到死锁和连接泄漏的问题，最后得不得修改代码。而WebLogic提供了功能强大，性能良好的数据库连接池，我们要做的只是封装一个连接管理类，从JNDI树上获取数据源并缓存，得到连接，并提供一系列关闭数据库资源的方法。
　　对任何资源使用的原则是用完即关，不管是数据库资源、上下文环境，还是文件。数据库资源的泄漏极易造成内存泄漏，乃至系统崩溃。在使用完数据库资源后依次关闭ResultSet，Statement和Connection，而在一个数据库连接多次进行数据库操作时要特别注意ResultSet和 Statement依次关闭。
try{
　　//open connection
　　pstmt =conn.prepareStatement(strSql1);
　　pstmt.executeUpdate();
　　pstmt.close();
　　pstmt =conn.prepareStatement(strSql2);
　　rs=pstmt.executeQuery();
　　while (rs.next()){
　　//process
　}
rs.close();
pstmt.close();
　}catch(Exception e){
　　//close rs,psmt,con
}finally{
　　//close rs,psmt,con
}
1.2.2 实用技巧
　　在JDBC操作中还有一些小的技巧跟大家分享：由于获取连接时默认自动提交方式，使用connection.setAutoCommit (false)关闭自动提交，使用PreparedStatement,批量更新,业务复杂或者大数据量操作时使用存储过程，尽量使用RowSet，此外设置记录集读取缓存FetchSize和设置记录集读取方向FetchDirection对性能也有一定的提高。
1.2.3 优化SQL语句
　　SQL语句的优化牵涉到很多数据库的知识，需要与索引配合，因此需要DBA对代码中的SQL进行检查测试。常见的，select *不提倡使用，效率极差，建议显式获取列，即使是所有字段也应罗列，而取总数时使用count(*),为提高cache的命中率，尽量做到SQL重用。对于大数据量的查询，可以充分利用Oracle数据库的特性，每次取出m-n行的数据，实现分页查询。另外，提高性能的好选择可能就是把所有的字符数据都保存为Unicode，Java以Unicode形式处理所有数据，因此，数据库驱动程序不必再执行转换过程。
1.3 Web代码调优
1.3.1 HttpSession的使用
　　应用服务器保存很多会话时，容易造成内存不足，所以尽量减少session的使用，放置session
里的对象不应该是大对象，最好是简单小对象，实现串行化接口。当会话不再需要时，应当及时调用invalidate()方法清除会话。而当某个变量不需要时，及时调用removeAttribute()方法清除变量。请勿将EJB对象放置在session中。
1.3.2 JSP代码调优
　　目前，在JSP页面中引入外部资源的方法主要有两种：include指令，以及include动作。 include指令：例如<%@ include file="copyright.html" %>，该指令在编译时引入指定的资源。在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定，比运行时才确定资源更高效。
include动作：例如<jsp:include page="copyright.jsp" />。该动作引入指定页面执行后生成的结果。由于它在运行时完成，因此对输出结果的控制更加灵活。但是，只有当被引用的内容频繁地改变时，或者在对主页面的请求没有出现之前，被引用的页面无法确定时，使用include动作才合算。
　　对于那些无需跟踪会话状态的jsp，关闭自动创建的会话可以节省一些资源。使用如下page指令： <%@ page session="false"%> ;尽量不要将JSP页面定义为单线程，应设置为<%@page isThreadSafe=”true”%>;在JSP页面最好使用输出缓存功能，如: <%@page buffer="32kb"%>;尽量用wl:cache定制标记来缓存静态或相对静态的内容，缓存jsp:include操作的结果能显著提高应用程序的运行性能。
1.3.3 Servlet代码调优
　　Servlet代码调优比较简单：在Servlet之间跳转时，forward比sendRedirect更有效；设置 HttpServletResponse 缓冲区，如：response.setBufferSize(20000);在init()方法里缓存静态数据，而在destroy()中释放它；建议在 Servlet里使用ServletOutputStream输出图片等对象；避免在Servlet和Jsp中定界事务等。
1.4 JMS代码调优
1.4.1 注意必要的事项，避免使用不必要的特征
　　JMS提供了强有力的消息处理机制，但是为了最大限度的提高JMS系统的性能，应避免使用不需要使用的特征，同时也要注意必要的事项。比如：尽量使用接收程序能直接使用的最简单、最小的消息类型；消息选择器要尽可能简单(最好不使用)，尽量不要使用复杂的操作符，如like、in或者between 等,使用字符串数据类型的速度最慢;务必为特定的应用程序定义特定的JMS连接工厂，并且禁用默认的JMS连接工厂；不要在javax.*与 weblogic.*的名字空间中使用JNDI名称；尽量使用异步消费者，线程不必封锁以等待消息的到达;使用完JNDI树上的资源后注意关闭。
1.4.2 消息类型的选择
　　标准JMS提供了五种消息类型，而TextMessage应用最为普遍, 当发送的消息是几种原始数据类型的集合体时，最好使用MapMessage消息类型，而不要使用ObjectMessage，以便减少不同系统间的耦合。此外消息是否使用压缩要慎重考虑，压缩未必能减少消息大小。如果生产者、消费者和目的地并置在同一WebLogic Server内部，通常不使用压缩。WebLogic特有的XMLMessage能为运行于消息主体之上的消息选择器提供内嵌式支持，而且易于数据交换。因此，建议应用程序之间传送消息使用XML消息格式，而应用程序内部间传送消息使用二进制消息格式。
1.4.3 确认方式的选择和JMS事务
　　使用事务性会话时,尽量使用恰当的消息确认方式:如果需求允许,使用NO_ACKKNOWLEDGE;非持久的订阅者使用 DUPS_OK_ACKNOWLEDGE或者MULTICAST_NO_ACKNOWLEDGE。而使用JTA的UserTransaction，确认方式将被忽略。在使用JMS事务时，无效的消息会导致事务的回滚，以致消息重发这样的死循环。此时，可以将无效消息发送到错误消息队列，并提交JMS事务，这将确保消息不会再次传递。
1.5 EJB代码调优
1.5.1 有效使用设计模式
　　GoF 的《设计模式》为我们实现高性能、易扩展的J2EE应用提供理论保障和技术支持。而EJB作为J2EE的核心组件和技术，善用设计模式对系统性能影响很大。Service Locator 和Value Object 已为我们所熟悉，Floyd Marinescu的《EJB Design Patterns》中的Session Fa?ade、Message Fa?ade、EJB Command和Data Transfer Object等设计模式更是为我们提供设计典范：缓存对EJBHome的访问；使用门面模式，不暴露Entity Bean，用Session Bean封装Entity Bean；如果可以异步处理，则用MDB代替Session Bean；封装业务逻辑在轻量级JavaBean中；使用值对象等简单对象传递数据;不直接使用get/set方法操作Entity Bean。当然过度使用模式或者牵强套用模式也是不提倡的，总的原则就是减少网络流量，改进事务管理。
1.5.2 使用EJB和WebLogic的特性
　　使用EJB和WebLogic的新特性往往能提高性能。与EJB2.0特性相关的技巧有：一个Application中使用本地接口，对于 Entity Bean肯定使用本地接口，避免远程调用的开销；使用CMP管理关系，而不是BMP，EJB2.0中CMP的性能大大改善，性能和移植性都优于BMP；使用ejbSelect进行内部查询；使用home方法进行外部查询和批处理; 数据库驱动级联删除等。
　　与WebLogic特性相关的技巧有:使用自动生成主键,WebLogic为Oracle和Sqlserver两种数据库的CMP提供了自动生成主键功能,节约了Entity Bean产生主键的时间,同时设key-cache-size不小于100;WebLogic管理事务性能更好,使用容器管理,而不是Bean管理事务;WebLogic提供了为CMP动态查询和批量插入功能,对性能也有很大帮助。
1.5.3 缓存资源
　　对SLSB或者MDB来说,使用setMesssageDrivenContext()或者ejbCreate()方法缓存特定资源,在ejbRemove()方法里释放; 对SLSB或者MDB来说,使用setSessionContext()或者ejbCreate()方法缓存特定资源,在ejbRemove()方法里释放;对Entity Bean来说,使用setEntityContext ()方法缓存特定资源,在unSetEntityContext ()方法里释放。
1.5.4 如何选择和使用Entity Bean
　　1. 在设计EJB时，要适当考虑EJB的粒度, 细粒度的EJB在事务管理和资源管理的开销太大,尽量创建粗粒度的 EJB , 不要太粗，粗到能满足实际需求就可以;
　　2. Entity Bean不是唯一方式,如果只有一个很小的数据子集被经常改变，建议采用JDO;
　　3. 在操作大数据量的时候,直接采用JDBC比Entity Bean更有效;
　　4. 避免采用返回很大数据组的finder方法,如 FindAll() 方法，因为它的实现代价太大;
　　5. 考虑设置域组field groups,减少没有必要并昂贵的属性加载,如BLOB;
　　6. 对于EJB1.1或者BMP,可以设置is-modified-method-name属性,根据isModified()的值来判断是否调用ejbStore()等方法,减少没有必要运算;
　　7. 避免连接多个表创建BMP,可以使用视图,存储过程或者O/R Mapping等方式。
1.5.5 其他的一些小技巧
　　1. 考虑使用 javax.ejb.SessionSynchronization 接口,提供在Rollback之后恢复数据的方法: afterBegin(), beforeCompletion(), afterCompletion();
　　2. 使用完SFSB之后，调用remove()方法释放实例;
　　3. 假如你不需要EJB服务的时候,建议使用普通Java类;
　　4. 避免EJB之间相互调用;
　　5. 使用多读模式。


BEA WebLogic平台下J2EE调优攻略----第二章 应用服务器调优 


2.1 JVM调优
2.1.1 垃圾收集和堆大小
　　垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)是指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间。堆越大,GC频度低,速度慢。堆越小,GC频度高,速度快。所以GC和堆大小是一组矛盾。为了获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jdk: -Xloggc:<file>)以打开详细的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:<gc-name>,对应四个收集器分其他为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初始化参数设置为自己的执行队列名。


<servlet>
<servlet-name>servletname</servlet-name>
<jsp-file>/directoryname/deployment.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>NewExecuteQueueName</param-value>
</init-param>
</servlet>


　　我们可以为一个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,避免事先加载子数据。




 
  
BEA WebLogic平台下J2EE调优攻略----第三章 数据库调优 




 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调优攻略----第五章 性能监控和性能分析 
第五章 性能监控和性能分析
5.1 性能瓶颈
　　最后,介绍一下实际分析J2EE应用性能的常用命令和工具。对于实现一个高性能的J2EE应用来说,掌握了J2EE调优的理论经验还是不够的。掌握性能监控,发现瓶颈和问题诊断才是保证J2EE系统持续高效运行的关键。
瓶颈指的是限值所有吞吐操作以及严重影响反应时间的系统内资源。在分布式系统内寻找并纠正瓶颈是非常困难的，需要有经验的团队来解决。瓶颈会发生在Web 服务器上，程序代码中，应用服务器上，数据库，操作系统或者网络，硬件上。经验表明，瓶颈很容易发生在如下地方：数据库连接与队列中；应用服务器的程序代码中；应用服务器和Web服务器硬件上；网络和TCP配置中。实际中可以着力对这些环节进行监控。


5.2 操作系统监控
　　操作系统层面的性能监控主要是对内存、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命令并非适用所有操作系统,仅供参考。


5.3 数据库监控
　　数据库层面的监控这里为oracle9i为例来说明,可以采用oracle自带的工具Oracle
Interprise Manager Console来监控session和sql的执行情况。还有其他专业的数据库监控工具可以使用,比如QUEST的spotlight(http://www.quest.com/spotlight-portal/)可以非常形象和直观地对Oracle数据库的CPU、内存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等参数进行即时监控,并自动对不正常的参数以红色显示。


5.4 WebLogic监控
5.4.1 JVM监控
　　采用java参数-verbose:gc 来分析JVM的GC非常繁琐，而且不直观。使用-Xloggc:gc.log 参数将GC日志写入文件,采用GC 工具HPjtune (http://www.javaperformancetuning.com/tools/hpjtune/index.shtml)进行分析,可以轻松看出当前jvm参数配置是否合理。


　　严格意义上来说HPjtune是一个分析工具,不是监控工具。这里不得不提及jRocket,Intel平台上最快的JVM, 在WebLogic启动命令中增加-Xmanagement参数,就可以执行beajrockit81sp3_142_04in下console命令监控WebLogic的内存使用和CPU负载情况。设置Tools/Preferences菜单中的Mode of operation属性为developer, jRocket将提供Method Profiler工具，她能够将所有在JRockit Java虚拟机上执行的成员方法的调用次数、执行的总时间和每次调用的执行时间都统计出来，进行代码级调优，这是jRockit的又一大优势。 


 




5.4.2 Console监控
　　WebLogic Console除了管理配置功能之外,提供了丰富的监控功能。通过WebLogic Console，首先我们可以查看服务器的运行情况。


5.4.2.1 Server监控
　　通过使用服务器的Performance Monitoring选项卡，可以查看到请求吞吐量，执行队列积压情况以及JVM栈利用情况。而通过点击Performance Genaral选项卡中” Monitor all Active Queues...”可以查看所以执行线程的当前统计数据。此外Monitoring选项卡还可以监控JTA和JMS等Service的情况。 


 




5.4.2.2 JDBC监控
　　在连接池Monitoring选项卡中，WebLogic Console为每一个数据库连接池提供了实时统计信息。其中有三个重要参数可以反应WebLogic Server的健康状况：Connections High、Wait Second High和Waiters High。Connection High表示从服务器启动开始后到达池的最大连接数量，如果大于池的最大数量，则需要调整Maxium Capacity。Waiters High表示在没有可用连接的情况下，应用程序等待连接的最大个数。我们可以根据Waiters High的大小调整连接池容量。更多的参数可以通过Customize this view链接添加,参数含义参考:http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_monitor.html#1104829。


5.4.2.3 WEB监控
　　Web Application Monitoring选项卡可以监控WEB应用的Session个数,以及Servlet的响应情况,激活Session Monitoring Enabled可以获取所有session的统计情况。更多信息请参考:
http://e-docs.bea.com/wls/docs81/ConsoleHelp/web_applications.html#1106723。


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监控的详细情况可参见:http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_monitor.html。


5.4.2.5 EJB监控
　　EJB监控包括对SLSB,SFSB,Entity Bean,MDB四种EJB的监控。本人认为EJB监控提供了非常丰富的运行时统计信息(http://e-docs.bea.com/wls/docs81/ConsoleHelp/ejb.html#1105036),非常有利于我们对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监控信息可参见http://edocs.bea.com/wls/docs81/ConsoleHelp/index.html。


5.4.3 实用工具分析
　　WebLogic除了提供Console进行应用监控之外,用户还可以编写JMX程序或者通过SNMP协议进行监控。而QUEST Spotlight for WebLogic Server提供了类似WebLogic Console类似的监控功能,并对异常情况显红。
这里不得不提到实战中经常用来分析性能瓶颈的工具THREAD DUMP,统一的命令是使用 weblogic.Admin 命令 THREAD_DUMP。而在 windows上还可以使用<Ctrl>+<Break> 来创建诊断问题所需的线程转储Thread Dump,而在unix上使用kill -3 <wlspid>命令。我们从中可以看到WebLogic后台线程的运行情况,通常需要每隔10秒左右持续执行几次以助诊断问题。更多信息可以参考BEA实战集锦。


5.5 应用程序分析
　　应用程序分析除了凭借程序员丰富的经验和敏锐的洞察力去人工检查代码之外,使用厂家的工具也是节省时间的不错选择。目前市场上有Borland Optimizeit Enterprise Suite和QUEST Jprobe两个产品可以用来分析性能瓶颈,垃圾收集,内存泄漏,线程死锁和代码复盖等。Hpjmeter是一个免费的工具,也具有以上类似的性能分析功能。


　　而Borland Optimizeit Server Trace,HP OpenView Transaction Analyzer和Mercury LoadRunner J2EE breakdown都可以用来分解J2EE应用从客户端访问到最终数据库操作每一层次花费的时间,甚至精确到每一个方法的执行时间。Server Trace还具有检查内存泄漏，连接泄漏和错误警告等功能,一般在测试环境中使用。而HP OTVA的优势在于运行时监控,LoadRunner优势在于压力测试。








 **********************************************************************************************************************
AIX性能监控 
aix的常用监视工具
常用命令 软件包
vmstat,iostat,sar bos.acct
topas,svmon,filemon,fileplace bos.perf.tools
vmtune,schedtune bos.adt.samples
netstat bos.net.tcp.client


vmstat报告CPU与内存信息
如下例所示:
kthr memory page faults cpu 
----- -------------- ------------------------- ------------ ----------- 
r b avm fre re pi po fr sr cy in sy cs us sy id wa 
2 11 1116402 0 0 19 24 583 1328 0 1514 10956 6379 17 4 45 34 
0 35 1117232 0 0 15 75 1908 4207 0 2675 9350 18901 10 8 0 82 
1 45 1118296 0 0 51 108 1873 3580 0 2298 8699 15324 9 8 0 83 
0 22 1116890 0 0 78 19 830 1577 0 1836 8530 3891 7 6 0 87 
13 29 1117030 0 0 5 26 1304 2737 0 1924 7619 9908 7 7 0 86 
内核线程
r表示内核中运行的线程数，如果其数超过系统的CPU个数，则说明等待进程越多
b表示内核中等待的线程数，由于挂起或IO等待


内存列
pi列表示每秒钟从Paging Space置换到内存的页数。 
po列表示每秒钟从内存置换到Paging Space的页数。 
如果这两列持续大于5，则系统的性能瓶颈很可能是内存不足，而导致交换频繁。
fr列表示每秒钟页面置换算法释放的页数。 
sr列表示每秒钟页面置换算法检查的页数。 


故障列
in 设备中断次数
sy 系统调用次数
cs 内核线程上下文交换，即时间片用完后，再轮到时的上下文计算，如果太高，则要仔细观察


内存信息
avm与free两项分别表示了物理内存的活动页数与可用页数(每页4096bytes)，其大小可用其值/256获得MB数。
其中free数如果持续为0或很低则预示内存不足，此时可能会导致大量的页面交换，而在CPU中显示为wa很高，此值的多少也与vmtune中的-f -p设置有关


CPU信息
在以上信息中，关于CPU是的后四列：
id高表示系统空闲，us、sy分别表示用户和系统进程CPU占用,wa表示IO等待时间
如果us与sy之和持续超过90%时，CPU出现了瓶颈。
如果wa长期很高>50，则表示IO太忙，具体看是应用IO多，还是交换分页多，如果是后者，则显示内存不足,
如果是前者，则应关注应用的IO性能状况，优化应用与磁盘设备








sar命令优势
sar可以针对SMP系统来分别查看CPU使用情况
sar -P ALL 3 2
AIX testhost 1 5 0050C33A4C00 06/28/05


17:30:02 cpu %usr %sys %wio %idle
17:30:05 0 38 4 43 15
1 32 3 49 16
2 51 3 44 2
3 53 3 42 2
- 44 3 44 9
17:30:08 0 35 1 46 18
1 18 3 70 9
2 24 2 60 14
3 16 1 81 3
- 23 2 64 11


Average 0 36 2 45 16
1 25 3 59 13
2 38 3 52 8
3 34 2 62 2
- 33 3 54 10
以上显示了一个单CPU系统的显示，


sar也可以查看系统调用情况
sar -c 3 2 
AIX test 1 5 0050C33A4C00 06/28/05


17:31:00 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s
17:31:03 5738 484 439 0.00 0.00 952729 1073997
17:31:06 3365 149 266 0.00 0.00 11620 930150


Average 4553 317 352 0.00 0.00 482957 1002193


svmon使用
svmon可以查看内存的详细使用情况，含分页
svmon -G  -i 5 2
               size      inuse       free        pin    virtual
memory      2097136    2096903        233     107570    1622941
pg space    1507328    1400132


               work       pers       clnt      lpage
pin          107324        246          0          0
in use      1236897     860006          0          0
               size      inuse       free        pin    virtual
memory      2097136    2096212        924     107570    1623787
pg space    1507328    1400135


               work       pers       clnt      lpage
pin          107324        246          0          0
in use      1237139     859073          0          0
其中memory行显示了内存总量，使用量，钉入量和虚拟总量
pg space行显示了分面空间的使用量
pin行显示了正在用的钉入量，永久钉入量和客户量
in use显示了总内存的工作页面量，永久页面量，客户端页面量
如想将oracle进行lock_sga设置，可以查看PIN值来确认是否生效
要使pin生效必需vmtune -S 1


svmon -U oracle可以查看oracle用户的用量
svmon -U oracle
===============================================================================
User                                 Inuse      Pin     Pgsp  Virtual  LPageCap
oracle                             1897660     3007  1210399  1459736         N
计算出其大小为         7412M 11M 4728M  5702M
...............................................................................
SYSTEM segments                      Inuse      Pin     Pgsp  Virtual
                                      3236     2089     1935     4889
                                      13M      8M        8M     
...............................................................................
EXCLUSIVE segments                   Inuse      Pin     Pgsp  Virtual
                                   1893883      918  1208317  1453304
                                      7398      4M
SHARED segments                      Inuse      Pin     Pgsp  Virtual
                                       541        0      147     1543
                                       2M
在以上表中SYSTEM是所有系统共用段，EXCLUSIVE是此用户专用段，SHARED段是共享段


svmon -C oracletest
可以统计oracletest命令的所有内存使用情况
在其中也分为SYSTEM,EXCLUSIVE,SHARED三段，在其中将会发现SHARED段很大，那是因为其与其它oracle进程共用的结果
在整个输出中，其类型分为
work 表示进程和内存共享段的区域
perm 表示文件，目录,日志，大文件等使用段,其代表了文件操作所用内存的值
clie 表示NFS，CDROM等文件系统使用段


svmon -P
可以查看所有进程的内存使用情况，加上PID可以查看单个进程的内存使用情况
能过此种方式，可以标识所用命令
通过上述命令获得的命令名，再通过svmon -C来查看其专用内存段，进行对比，可以区分出不同命令所用内存多少，对oracle不同进程之间的分析有用


磁盘IO
iostat 可以查看时间段内的CPU状况和磁盘状况
tty:      tin         tout   avg-cpu:  % user    % sys     % idle    % iowait
          0.0         55.3              11.6      2.0       20.4      66.0     


Disks:        % tm_act     Kbps      tps    Kb_read   Kb_wrtn
hdisk0          24.9     153.0      38.3       1236       296
hdisk1          31.3     193.8      48.7       1656       284
dac0             0.0     2969.1     179.1      11564     18164
hdisk2         100.0     2969.1     179.1      11564     18164
cd0              0.0       0.0       0.0          0         0
其中% tm_act是指活动时间,kbps是在统计时间内所有Kb_read与Kb_wrtn之和除以时间的值，即每秒传输的字节数
如果% tm_act常过70%却只有很低的Kbps，系统可能是有比较多的LV碎片或文件碎片，当都高时则系统正常。
tps表示每秒的IO数，不同的磁盘系统其可承受的IO数不同。


sar -d 10 2也可以查看IO情况
12:11:16     device    %busy    avque    r+w/s   blks/s   avwait   avserv


12:11:26     hdisk0     34      1.0       50      201      0.0      0.0
             hdisk1     41      0.0       64      259      0.0      0.0
               dac0      0      0.0      331     4197      0.0      0.0
             hdisk2     99      5.0      331     4197      0.0      0.0
                cd0      0      0.0        0        0      0.0      0.0
其中的%busy对应的% tm_act
avque表示等待IO对列数，其值很高则预示着磁盘有较大瓶颈
r+w/s对应tps,blks/s是按0.5Kbytes/s计算的传输速度
sar -d 最大好处是可以对较长时间的值会有一个总体平均值




vmtune使用
/usr/samples/kernel/vmtune 会得出当前设置数据
vmtune:  current values:
  -p       -P        -r          -R         -f       -F       -N        -W
minperm  maxperm  minpgahead maxpgahead  minfree  maxfree  pd_npages maxrandwrt
 400921  1603684       2          8        120      128      65536        0


  -M      -w      -k      -c        -b         -B           -u        -l    -d
maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps
1677709   47104   11776       1     186        224          9      131072     1


        -s              -n         -S         -L          -g           -h
sync_release_ilock  nokilluid  v_pinshm  lgpg_regions  lgpg_size  strict_maxperm
        0               0           0           0            0        0


    -t           -j              -J               -z
maxclient  j2_nPagesPer j2_maxRandomWrite  j2_nRandomCluster
1603684           32            0                  0


    -Z                  -q                    -Q                -y
j2_nBufferPer  j2_minPageReadAhead  j2_maxPageReadAhead   memory_affinity
      512              2                    8                 0


    -V                  -i
num_spec_dataseg  spec_dataseg_int
      0                512


PTA balance threshold percentage = 50.0%


number of valid memory pages = 2097136  maxperm=80.0% of real memory
maximum pinable=80.0% of real memory    minperm=20.0% of real memory
number of file memory pages = 847042    numperm=42.2% of real memory
number of compressed memory pages = 0   compressed=0.0% of real memory
number of client memory pages = 0       numclient=0.0% of real memory
# of remote pgs sched-pageout = 0       maxclient=80.0% of real memory


其中的minfree限制了当系统的分页数少于此值时就要交换出此页数，并在达到maxfree时停止
其中maxfree必须>minfree+maxpgahead
./vmtune -F maxfree_pages -f minfree_pages 用于进行以上设置


minperm,maxperm对文件分页的控制
MINPERM与MAXPERM的意义
当内存中的文件缓存页在MINPERM以下时，内存页交换算法同时交换文件缓存页和程序页(computational pages) 
当内存中的文件缓存页在MAXPERM以上时，内存页交换算法只交换文件缓存页。 
当内存中的文件缓存页在MINPERM和MAXPERM之间时，内存页交换算法通常只交换文件缓存页，但如果文件缓存页的交换率大于程序页时，程序页也同样被交换。 
MINPERM和MAXPERM参数的缺省值为20%与80%
即vmtune -p 20 -P 80
可以用以下命令将MINPERM设为5%的内存页，而MAXPERM设为20%的内存页。
# vmtune -p 5 -P 20
在vmtune的输出中，有一个numperm的值，其对我们调整很有参考意义


在Oracle数据库应用的环境下，可以将MINPERM和MAXPERM分别设为5%和20%甚至更小，从而使内存更多地被用于Oracle的SGA而不是系统的文件缓存。
但此时也要考虑系统的dbrw量的多少，用lock_sga方法可以更好的控制sga的是否交换(在lock_sga前，应该先vmtune -S 1 启用pinshm以支持应用的内存pin)


 
 **************************************************************************************************************************************
Oracle SQL 性能优化技巧 
1.选用适合的ORACLE优化器
     ORACLE的优化器共有3种 
     A、RULE (基于规则) b、COST (基于成本) c、CHOOSE (选择性) 
     设置缺省的优化器，可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。 你当然也在SQL句级或是会话(session)级对其进行覆盖。 
     为了使用基于成本的优化器(CBO， Cost-Based Optimizer) ， 你必须经常运行analyze 命令，以增加数据库中的对象统计信息(object statistics)的准确性。 
     如果数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过analyze命令有关。 如果table已经被analyze过， 优化器模式将自动成为CBO ， 反之，数据库将采用RULE形式的优化器。 
在缺省情况下，ORACLE采用CHOOSE优化器， 为了避免那些不必要的全表扫描(full table scan) ， 你必须尽量避免使用CHOOSE优化器，而直接采用基于规则或者基于成本的优化器。 


2.访问Table的方式
     ORACLE 采用两种访问表中记录的方式： 
     A、 全表扫描 
          全表扫描就是顺序地访问表中每条记录。ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。 
     B、 通过ROWID访问表 
          你可以采用基于ROWID的访问方式情况，提高访问表的效率， ROWID包含了表中记录的物理位置信息。ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。 


3.共享SQL语句
     为了不重复解析相同的SQL语句，在第一次解析之后，ORACLE将SQL语句存放在内存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享。 因此，当你执行一个SQL语句(有时被称为一个游标)时，如果它和之前的执行过的语句完全相同， ORACLE就能很快获得已经被解析的语句以及最好的执行路径。ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用。 
     可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering)，这个功能并不适用于多表连接查询。 
     数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。 
     当你向ORACLE提交一个SQL语句，ORACLE会首先在这块内存中查找相同的语句。这里需要注明的是，ORACLE对两者采取的是一种严格匹配，要达成共享，SQL语句必须完全相同(包括空格，换行等)。 
     数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。 
     共享的语句必须满足三个条件： 
     A、 字符级的比较： 当前被执行的语句和共享池中的语句必须完全相同。 
     B、 两个语句所指的对象必须完全相同： 
     C、 两个SQL语句中必须使用相同的名字的绑定变量(bind variables)。 


4.选择最有效率的表名顺序(只在基于规则的优化器中有效)
     ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表 driving table)将被最先处理。在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表。当ORACLE处理多个表时， 会运用排序及合并的方式连接它们。首先，扫描第一个表(FROM子句中最后的那个表)并对记录进行派序，然后扫描第二个表(FROM子句中最后第二个表)，最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。 
     如果有3个以上的表连接查询， 那就需要选择交叉表(intersection table)作为基础表， 交叉表是指那个被其他表所引用的表。 


5.WHERE子句中的连接顺序
     ORACLE采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的连接必须写在其他WHERE条件之前， 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。 


6.SELECT子句中避免使用 ' * '
     当你想在SELECT子句中列出所有的COLUMN时，使用动态SQL列引用 '*' 是一个方便的方法。不幸的是，这是一个非常低效的方法。实际上，ORACLE在解析的过程中， 会将'*' 依次转换成所有的列名， 这个工作是通过查询数据字典完成的， 这意味着将耗费更多的时间。 


7.减少访问数据库的次数
     当执行每条SQL语句时，ORACLE在内部执行了许多工作：解析SQL语句，估算索引的利用率，绑定变量，读数据块等等。由此可见，减少访问数据库的次数，就能实际上减少ORACLE的工作量。 


8.使用DECODE函数来减少处理时间
     使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表。 


9.整合简单，无关联的数据库访问
     如果你有几个简单的数据库查询语句，你可以把它们整合到一个查询中(即使它们之间没有关系) 


10.删除重复记录
11.用TRUNCATE替代DELETE
     当删除表中的记录时，在通常情况下， 回滚段(rollback segments ) 用来存放可以被恢复的信息。 如果你没有COMMIT事务，ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况)。 
     而当运用TRUNCATE时， 回滚段不再存放任何可被恢复的信息。当命令运行后，数据不能被恢复。因此很少的资源被调用，执行时间也会很短。 


12.尽量多使用COMMIT
     只要有可能，在程序中尽量多使用COMMIT，这样程序的性能得到提高，需求也会因为COMMIT所释放的资源而减少 
     COMMIT所释放的资源： 
     A、 回滚段上用于恢复数据的信息。 
     B、被程序语句获得的锁。 
     C、 redo log buffer 中的空间。 
     D、ORACLE为管理上述3种资源中的内部花费。 


13.计算记录条数
     和一般的观点相反，count(*) 比count(1)稍快，当然如果可以通过索引检索，对索引列的计数仍旧是最快的。例如 COUNT(EMPNO) 


14.用Where子句替换HAVING子句
     避免使用HAVING子句，HAVING 只会在检索出所有记录之后才对结果集进行过滤。 这个处理需要排序，总计等操作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。 


15.减少对表的查询
     在含有子查询的SQL语句中，要特别注意减少对表的查询。 


16.通过内部函数提高SQL效率。
17.使用表的别名(Alias)
     当在SQL语句中连接多个表时， 请使用表的别名并把别名前缀于每个Column上。这样一来，就可以减少解析的时间并减少那些由Column歧义引起的语法错误。 


18.用EXISTS替代IN
     在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接。在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率。 


19.用NOT EXISTS替代NOT IN
     在子查询中，NOT IN子句将执行一个内部的排序和合并。 无论在哪种情况下，NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历)。为了避免使用NOT IN ，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS。 


20.用表连接替换EXISTS
     通常来说 ， 采用表连接的方式比EXISTS更有效率 


21.用EXISTS替换DISTINCT
     当提交一个包含一对多表信息(比如部门表和雇员表)的查询时，避免在SELECT子句中使用DISTINCT。 一般可以考虑用EXIST替换


  
 以上信息为本人工作遇到难题时，收集到众多IT朋友的一些工作经验，仅供参考。在这感谢他们对其他朋友的的支持和帮助，也希望每个经过的朋友对他们致敬
 
 -----------------------------------------------------------------------------------------------------------------------------------------------------
 weblogic性能调优JAVA优化性能 
注：在下面做的介绍都是以Weblogic8.1为例的，其它版本的Weblogic可能会有些许不同。


1) 设置JAVA参数；
a) 编辑Weblogic Server启动脚本文件；
BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix)  
BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix) --这个是做集群的时候用的
b) 编辑set JAVA_OPTIONS命令，如：set JAVA_OPTIONS=-Xms256m –Xmx256m；
（在UNIX下把MEM_ARGS="-Xms1024m -Xmx1024m -Xmn128m"加到上述两个.sh文件中即可）
c) 保存，重启即可。
注：在WebLogic中，为了获得更好的性能，BEA公司推荐最小Java堆等于最大Java堆。
（这个偶们的设置都是1024M的，反正偶们内存大大的4G呢）


2) 开发模式 vs. 产品模式；
开发模式和产品模式的一些参数的默认值不同，可能会对性能造成影响，下面是对性能有影响的参数列表：




参数 开发模式默认值 产品模式默认值 
Execute Queue: Thread Count 15 threads 25 threads 
JDBC Connection Pool: MaxCapacity 15 connnections 25 connections 


通过启动管理控制台，在域（如：mydomain）> 配置 > 常规选择产品模式。
（这个在创建weblogic的domain的时候是有选择的，选择“产品”模式就可以了，如果后期需要修改，可以按照上面的方法修改）


3) 尽量开启本地I/O；
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 配置 > 调整选择启用本地I/O。
注：此值也可通过手动的修改config.xml配置文件。
（这个没有试验过，不晓得有什么效果和好处，知道的告诉偶下下。）


4) 调优执行队列线程；
a) 修改默认执行线程数
在这里，执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好，应该恰到好处的去设置它，太小了，执行队列中将会积累很多待处理的任务，太大了，则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。
（点：一般来说，其上限是每个CPU对应50个线程，其按照CPU个数线性增长.）


为了设置理想的执行队列的线程数，我们可以启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数，据此确定理想的数值。
理想的默认执行线程数是由多方面的因素决定的，比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。在测试中，可以以25*CPU个数为基准进行调整。当空闲线程较少，CPU利用率较低时，可以适当增加线程数的大小（每五个递增）。对于PC Server和Windows 2000，则最好每个CPU小于50个线程，以CPU利用率为90%左右为最佳。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。


b) 设定执行队列的溢出条件；
    Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。
    通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面几项：
●队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。
●队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。
●线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。
●最大线程数：为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。
在实际的应用场景中，应根据具体情况适当的调整以上参数。


c) 设定执行队列监测行为
Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置下面几项：
●阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。
●阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为 600 秒。


5) 调优TCP连接缓存数；
WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。
Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置“接受预备连接”。


6) 改变Java编译器；
标准的Java编译器是javac，但编译JSP servlets速度太慢，为了提高编译速度，可以使用sj或jikes编译器取代javac编译器。下面说说更改Java编译器：
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 常规下改变Java 编译器，默认为javac。输入完整路径，如：c:\visualcafe31\bin\sj.exe。然后打开高级选项，在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项，如：BEA_HOME\jdk141_02\jre\lib\rt.jar。


7) 使用Webogic Server集群提高性能；
具体关于如何配置Weblogic集群，我就不细说了。详情可参考：Introduction to WebLogic Server Clustering。


8) Weblogic EJB调优
由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧！


9) JDBC应用调优
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。


10) JSP调优
设置jsp-param pageCheckSeconds=-1；
设置serlet-reload-check=-1或ServletReloadCheckSecs=-1；
设置jsp-param precompile=true，关闭JSP预编译选项。 


weblogic, java, 性能调优






系统的线程池配置考虑以下因素： 
1，  机器的计算能力； 
2，  子系统每个线程的计算复杂性； 
3，  整个系统的均衡性。 


因此，建议设定一个标准范围，例如（举例说明，具体数值根据情况斟酌）： 
机型：DL380G4/2*3G/4G，线程池大小范围：80－120（无特殊情况一般设为100）； 
机型：DL380G5/2*2G/4G，线程池大小范围：100－120（无特殊情况一般设为110）； 
机型：BL460C/2*3G/4G，线程池大小范围：100－120（无特殊情况一般设为110）；


#1






Log中有“too many open files”的错误 
表示达到了系统对一个进程能同时打开的文件数的限制 
ulimit –a –H 可以查看当前限制 
ulimit –n number可以来更改当前环境的设置，建议至少设到4096 
Solaris上可以通过/usr/proc/bin/pfiles pid来查看指定进程的限制和当前使用的file descriptor数目 
Solaris上root用户可以通过/usr/proc/bin/plimit -n soft,hard pid 来动态更改进程的文件描述符的限制
Post by iceskysl on 2007, September 18, 11:55 AM  #2




JVM的heap区大小 
通过java命令行中的-Xms,-Xmx指定，建议最小值和最大值设成一样 
可以通过weblogic console上server/monitor/performance来观察其使用情况 
建议生产系统最少256M，一般情况下可以设置为系统剩余物理内存的80％
Post by iceskysl on 2007, September 18, 11:57 AM  #3






Post by iceskysl on 2007, September 18, 4:37 PM  #4




1、修改/etc/security/limits.conf，需要root权限 
vi /etc/security/limits.conf 
# 确认包含下面的内容： 
*                soft    nofile          8192 
*                hard    nofile          8192 
修改后，su到目标用户，用ulimit –Hn和ulimit –Sn确认修改已生效 




echo 
echo "-----------------------------------------------" 
echo "Begin to check the file descriptor limit" 
fd=`ulimit -n` 
if [ $fd -lt 8192 ]; 
   then 
   echo "Fatal Error!" 
   echo "The file descriptor limit is only '"$fd"'!" 
   echo "Please make it more than 8192!" 
   exit 
fi 
echo "OK, the file descriptor limit is" $fd 
echo "-----------------------------------------------" 
echo 
echo
Post by iceskysl on 2007, September 18, 5:26 PM  #5




/usr/sbin/lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
Post by iceskysl on 2007, September 20, 10:53 AM  #6




1）SQL语句运行时线程阻塞 
2）out.println语句运行时线程阻塞 




这里需要注意：数据库的不同版本可能需要相应版本的数据库驱动。SQL语句不能正常运行，通常都是由驱动引起的。 






http://bbs.sinoweb.com.cn/archiver/tid-405.html
Post by iceskysl on 2007, September 23, 2:13 AM  #8


http://www.cntesting.com/portal/html/testing-technique/load-test/20070509/178.html
Post by iceskysl on 2007, September 23, 2:25 AM  #9




####<2007-7-2 下午04时07分20秒 CST> <Error> <WebLogicServer> <gis> <portalServer> <weblogic.health.CoreHealthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '5' for queue: 'default' has been busy for "1,165" seconds working on the request "Http Request: /tzzmWeb/saye/regie/census/customertoMtn/custcheckout.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.> 




可以通过以下几种方法解决： 
1）修改StuckThreadMaxTime参数，将默认的600s改成1200s，或者其它适合的值。 
2）增大线程数，防止线程阻塞问题。 
3）优化程序，减少处理时间。