WebLogic Server 性能调优（一）

任何在市场上成功的产品都拥有良好的性能。虽然成为象WebLogic Server这样广泛使用的产品需要具备很多特性，但性能绝对是必不可少的。
　 　良好的编程习惯在帮助应用运行方面起了很大的作用，但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植，必须具备通用性以便处理 范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因，通过调整这些“按钮”，能够使服务器更适合运行环境以及应用程序。

　　本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。

　　性能监控及瓶颈发现

　　性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。

　　WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情 况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台 提供的性能监控的选项之一。

　　代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如:Wily Introscope, Jprobe, Optimizelt。

　　EJB 容器

　　EJB容器中最昂贵的操作当然是数据库调用?D?D装载和存储实体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进行访问。这虽然在容器内提供了很 好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行 性。