WebLogic Server中CMP实体bean的性能调优[9]

　　WebLogic Server中CMP实体bean的性能调优[9]    软件测试

　　应用程序级缓存

　　如果您的应用程序使用了很多实体bean，那么分析和配置各个bean的缓存会很麻烦。估计从“master-detail”关系的“detail”端返回的bean实例数尤为困难——比如，如果您的应用程序在“订单”表上执行一个finder操作，每个订单都有一个“项目”数可变的集合。另一个问题是由于每个实体bean都有一个单独的缓存，内存没有得到最有效的利用。认识到“每个bean一个缓存”模型的限制，WebLogic Server(从版本7开始)开始支持实体bean的应用程序级缓存。这使得同一个J2EE应用程序中的多个实体bean共享一个运行时缓存。

　　应用程序级缓存提供了下列好处：它减少了实体bean缓存的数目，从而减少了配置缓存的工作量。 它充分利用了内存和堆空间，因为减少了分段。比如，如果某一特定EJB经历了一次突发活动，它可以使用联合缓存中可用的所有内存，而使用该缓存的其他EJB都被换出。如果两个EJB使用不同的缓存，当一个bean的缓存满时，容器就不能将EJB换出到另一个bean的缓存中，导致了内存浪费。 它简化了管理;联合缓存使系统管理员只需调整单个缓存，而不是很多个缓存。 它提供了更好的可伸缩性。

　　为了定义应用程序级缓存，首先配置weblogic-application.xml中的entity-cache元素。然后在weblogic-ejb-jar.xml中引用entity-descriptor元素中entity-cache-ref元素中的应用程序级缓存。您可以定义一个缓存，然会将其用于应用程序中的所有实体bean，或者为bean组定义不同的缓存。也可以将应用程序级缓存与每个bean一个缓存混合使用，这样您就有很大的试验空间。我建议首先从被所有实体bean共享的应用程序级缓存开始，除非您有某些特殊需求。

　　使用应用程序级缓存是为每个bean指定一个缓存的可行的替代方法。可引用单个缓存的不同实体bean的数目或者已定义缓存的数目没有限制。可根据bean实例数(与每个bean一个缓存类似的方法)或者最大内存空间来指定缓存大小。从管理角度来看，使用内存的大小很有吸引力，但是要知道WebLogic Server不计算缓存中bean消耗的实际内存数(这可能是一项代价很高的操作);它只是根据weblogic-ejb-jar.xml部署描述符中规定的bean平均大小来分割内存。如果没有指定大小，则假定每个bean平均有100字节。我认为根据bean实例数指定缓存大小会更透明。

　　选择哪项策略?

　　本文已经讨论了很多内容，但是还未提及可应用于CMP bean的优化技术。比如，CMR缓存和字段组在某些环境下也很有用。选择最佳并发策略并充分利用长期缓存会给您的应用程序带来直接的性能提升。由于现在各个WebLogic Server版本中可用的选项有诸多不同(对于其他J2EE服务器也是如此)，所以有时候很难在某一具体情况下做出选择，尤其是如果开发人员没有调整这些参数的经验的话。如果根本没有指定并发策略和缓存参数，WebLogic Server使用的默认设置从数据一致性方面考虑当然是不错的选择，但是从CMP bean的性能方面来看却不是最佳选择。没有放之四海皆准的东西，所以如果您不确定的话，应该分析您的用例，然后利用不同的并发设置进行测试，然后再作出最佳选择。接着，我会讨论一些基本用例以及它们的推荐设置。

　　静态只读数据

　　最可能的场景是，当数据库是静态(不随时间变化)、准静态(变化不频繁)，或者从应用程序的角度来看可当作静态或准静态，并且您的应用程序不修改这些数据时。比如，数据可能被外部进程频繁更新，但是如果您的应用程序只是每分钟/小时/天看到这些更新，那么就没问题。这种情况下，使用带有适当read-timeout-seconds值的只读并发策略是合乎逻辑的。如果您的应用程序需要按照某种预定时间间隔看到更新，或者有一个批处理过程来加载数据，而你需要马上看到新数据，那么就可以像前面描述的那样，显式地禁用缓存。比如，您可以在应用程序的正面暴露一个“CMP缓存失效服务”，然后在批处理的最后或者从调度程序中调用。这种情况下缓存大小很容易计算，因为需要该缓存的所有事务共享同一个CMP实例，所以不需要考虑多版本及其对缓存大小的影响。要根据表大小、单个对象大小以及可用内存选择合理的缓存大小。

原文转自：http://www.ltesting.net