虽然现在Weblogic的版本已经升级到10.3，并被包装为Oracle funsion middleware 11g，但是新资料还是比较少，这里分享一篇Weblogic经典版本8.1的性能调优文章。
-------------------------------------------------------------------------------------------------------------------
任何在市场上成功的产品都拥有良好的性能。虽然成为象WebLogic Server这样广泛使用的产品需要具备很多特性，但性能绝对是必不可少的。
良好的编程习惯在帮助应用运行方面起了很大的作用，但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植，必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因，通过调整这些“按钮”，能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分――网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。
WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如：Wily Introscope, Jprobe, Optimizelt。
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用――装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样，除非是在特殊情况下，否则在每个bean的每次交易中，至少都得有一次装载操作和一次存储操作。这些特殊情况是：
1． Bean是只读的。此时，bean只需在第一次访问时装载一次，从来不需要存储操作。当然，如果超出参数read-timeout-seconds的设置，bean将被再次装载。
2． Bean 有专门的或积极的并发策略，且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3． Bean在交易中未被修改过，此时，容器会将存储操作优化掉。
如果不属于上述任何一种情况，则code path中的每个实体bean在每次交易时，至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销，如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等,其中的某些特征是WebLogic Server 7.0新增的。
高速缓存：实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。
域分组：域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域（比方说，一幅图像）相联系，且很少被访问，则可以定义一个将此域排除在外的域组，该域组与一个查找方法相关联，这样查找时，BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。
并发策略：在WebLogic Server 7.0中，容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施，它的主要目的是确保实体bean所表示的数据的一致性，该一致性由bean的部署器所强制要求。无论如何，某些控制机制使得容器处理请求的速度比其它的要快一些，但这种快速是以牺牲数据的一致性为代价的。
最严格的并发策略是独占式，利用特殊主键对bean的访问是经过系列化的，因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行性。
数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。
积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。 本特征也只对EJB 2.0 适用。
只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载。
紧密关联缓存： 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。
除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。
缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean（SLSB），消息驱动bean（MDB）以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数（事实上，要求比此数要小）。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连（没有主键）。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。
高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。
EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作：传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活（activation）。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活（activation）。
