WebLogicServer性能及调优-调优WebLogicServerEJB.doc

WebLogic Server 性能及调整 -调整 WebLogic Server EJB下列部分描述如何调整 WebLogic Server EJB 以满足应用程序需要： 常规 EJB 调整提示 调整 EJB 缓存 调整 EJB 缓冲池 CMP 实体 Bean 调整 根据监视统计信息调整 常规 EJB 调整提示 部署描述符基于 Schema。此版本 WebLogic Server 中的新增描述符不是以基于 DTD 的描述符的形式提供的。 避免使用 RequiresNew 事务参数。如果使用 RequiresNew，则会导致 EJB 容器在挂起当前事务后启动新事务。这意味着需要分配其他资源（包括单独的数据库连接）。 使用 local-interfaces 或将 call-by-reference 设置为 true，可以在一个 EJB 调用另一个 EJB 或同一应用程序中的 Servlet/JSP 调用 EJB 时避免序列化的开销。请注意以下事项： 在 WebLogic Server 8.1 之前的版本中，默认情况下 call-by-reference 处于打开状态。对于 WebLogic Server 8.1 及更高版本，默认情况下 call-by-reference 处于关闭状态。对于要迁移到 WebLogic Server 8.1 及更高版本中的未明确启用 call-by-reference 的旧应用程序，其性能可能会下降。 此优化不适用于不同应用程序间的调用。 只要有可能就要对有状态会话 Bean 使用无状态会话 Bean。与有状态会话 Bean 相比，无状态会话 Bean 的可伸缩性更高，因为不用维护状态信息。 对于驻留在 WebLogic Server 群集中的 EJB，WebLogic Server 在事务性能方面具有更多优点。单项事务使用多个 EJB 时，WebLogic Server 会尝试使用单个 WebLogic Server 实例中的 EJB 实例，而不会尝试使用不同服务器中的 EJB。这种方法可以将事务的网络流量降到最低程度。在某些情况下，一项事务可以使用驻留在群集内多个 WebLogic Server 实例中的 EJB。异构群集中会发生这种情况，其中的所有 EJB 未被部署到所有 WebLogic Server 实例中。在上述情况下，WebLogic Server 使用多层连接而不是多个直接连接访问数据存储。这种方法使用的资源更少，因此会提高事务性能。但为了得到最佳性能，群集应该是同构的，即所有 EJB 都应该驻留在所有可用 WebLogic Server 实例中。 调整 EJB 缓存下列部分提供有关如何调整 EJB 缓存的信息： 调整有状态会话 Bean 缓存 调整实体 Bean 缓存 调整查询缓存调整有状态会话 Bean 缓存EJB 容器在内存中可以缓存有状态会话 Bean 的最大数目为由 weblogic-ejb-jar.xml 中指定的 max-beans-in-cache 参数指定的数目。应将此参数设置为等于并发用户数。这样可确保对磁盘以及从磁盘进行的后续激活的有状态会话 Bean 的钝化降到最低程度，这也会提高性能。调整实体 Bean 缓存EJB 容器在以下两个级别上缓存实体 Bean： 事务级别缓存 在事务之间缓存事务级别缓存从数据库中加载实体 Bean 之后，每当使用 findByPrimaryKey 请求该实体 Bean，或从该事务内的缓存引用中调用该实体 Bean 时，始终都会从缓存中检索该实体 Bean。请注意，如果使用非主键 Finder 方法获取实体 Bean，则始终会从数据库中检索实体 Bean 的持久性状态。在事务之间缓存也可在事务之间缓存实体 Bean 实例。但在默认情况下，不会在事务之间缓存实体 Bean 的持久性状态。要启用在事务之间进行缓存，请将 cache-between-transactions 参数的值设置为 true。缓存状态是否安全？这取决于该 Bean 的并发策略。实体 Bean 缓存仅在可将 cache-between-transactions 安全地设置为 true 时才真正有用。在 ejbActivate() 和 ejbPassivate() 回调开销过大的情况下，确保实体缓存大小足够大则仍然是一个好办法。即使对每项事务可至少重新加载持久性状态一次，缓存中的 Bean 仍会处于已激活状态。缓存大小的值是由部署描述符参数 max-beans-in-cache 设置的，应设置为保证缓存访问次数可达到最大值。在大多数情况下，该值无须大于与实体 Bean 相关联的表中的行数和预计并发访问该 Bean 的线程数的乘积。调整查询缓存查询缓存是 WebLogic Server 9.0 中的新功能，只读 CMP 实体 Bean 通过该功能可以缓存任意 Finder 方法的结果。除 prepared-query Finder 方法之外，查询缓存支持所有 Finder 方法。查询缓存可分为应用程序级别缓存和 Bean 级别缓存。缓存的大小受 weblogic-ejb-jar.xml 参数 max-queries-in-cache 限制。weblogic-cmp-rdbms 描述符文件中的 finder-level 标志 enable-query-caching 用于指定是否要缓存该 Finder 方法的结果。将与其同名的标志应用于 weblogic-relationship-role 元素时，该标志的用途与内部关系 Finder 方法相同。在下列情况中会从查询缓存中清除查询： 查询的使用日期最早，并且 query-cache 已达到其大小限制。 从实体 Bean 缓存中至少清除了一个满足查询条件的 EJB（无论何原因）。 查询与已启用 eager-relationship-caching 的 Finder 方法相对应，并且从相关 Bean 查询缓存中清除了相关联的内部关系 Finder 方法的查询。可使用实体 Bean 缓存的大小限制查询缓存的大小，方法是将 max-queries-in-cache 参数设置为 0，因为在清除相应 EJB 时会从缓存中清除查询。这样可以避免在查询缓存中出现锁定冲突，但性能的提高可能并不明显。 调整 EJB 缓冲池以下部分提供有关如何调整 EJB 缓冲池的信息： 调整无状态会话 Bean 缓冲池 调整 MDB 缓冲池 调整实体 Bean 缓冲池调整无状态会话 Bean 缓冲池EJB 容器可以为无状态会话 Bean 维护一个缓冲池，以避免创建和破坏实例。虽然这种缓冲池用途广泛，但在 ejbCreate() 和 setSessionContext() 方法的开销过大时，这种缓冲池对于性能来说就更加重要。该缓冲池有上下限。上限是两者中较重要的限制。 上限是由 max-beans-in-free-pool 参数指定的。应将其设置为等于预计并发调用 EJB 的线程数。采用的值太小会影响并发。 下限是由 initial-beans-in-free-pool 参数指定的。如果增加 initial-beans-in-free-pool 的值，则会增加部署包含 EJB 的应用程序所耗费的时间，也会增加服务器的启动时间。其益处是不必在运行时因创建 EJB 实例而增加开销。将此值设置得太高会浪费内存。调整 MDB 缓冲池MDB 的生命周期与无状态会话 Bean 的非常相似。MDB 缓冲池的调整参数与无状态会话 Bean 的调整参数相同，调整这些参数时要考虑的因素也相同。一般而言，大多数用户都会觉得默认值适用于大多数应用程序。请参阅调整消息驱动 Bean。调整实体 Bean 缓冲池实体 Bean 缓冲池有两种用途： 用作通过反射调用 Finder 方法的目标对象。 如果容器在缓存中找不到特定主键的实例，则用作可供容器使用的 Bean 实例的缓冲池。实体缓冲池包含匿名实例（无主键的实例）。虽然已经设置 EJB 上下文，但这些 Bean 尚未处于活动状态（即尚未对其调用 ejbActivate()）。从实体缓存中清除的实体 Bean 实例将被钝化，并存入缓冲池中。initial-beans-in-free-pool 和 max-beans-in-free-pool 是可调整的参数。与无状态会话 Bean 和 MDB 不同，max-beans-in-free-pool 与线程数无关。如果实体 Bean 构造方法或 setEnityContext() 方法的开销过大，则应增加 max-beans-in-free-pool 的值。 CMP 实体 Bean 调整通过使用缓存将与数据库之间的交互次数减到最少，可以将实体 Bean 性能提高到最佳程度。但在大多数情况下，缓存事务范围之外的实体 Bean 并不现实。下列部分提供有关 WebLogic Server EJB 容器功能的信息，可对其中的大多数功能进行配置，将其用于安全地把数据库交互次数减到最少： 使用紧密关系缓存 使用 JDBC 批处理操作 经过调整的更新 使用字段组 include-updates call-by-reference Bean 级别悲观锁定 并发策略使用紧密关系缓存EJB 容器通过使用紧密关系缓存可用一个 SQL Join 语句加载相关实体 Bean。仅可在同一事务访问相关 Bean 时使用。请参阅关系缓存。使用 JDBC 批处理操作在 EJB 容器中，默认情况下已启用 JDBC 批处理操作。EJB 容器会自动重新排序并执行单个批处理中的类似数据库操作，这会由于减少数据库往返次数而提高性能。BEA 建议使用批处理操作。经过调整的更新更新实体 EJB 时，EJB 容器仅会自动更新数据库中实际上已更改的字段。因此更新语句将更为简单，如果未修改某个 Bean，则不会执行数据库调用。因为不同的事务会修改不同的字段集，所以可用于将 Bean 存储在数据库中的更新语句的形式不止一种。在设置 JDBC 连接缓冲池中的预处理语句缓存大小时，要考虑可能使用的更新语句的类型，这很重要。请参阅缓存预处理语句和可调用语句。使用字段组用户通过字段组可将常用字段划分到一组中。如果应用程序 /Bean 代码访问组中的某一字段，则可使用一个 SQL 语句加载整个组。也可将此组与 Finder 方法相关联。调用 Finder 方法并且 finders-load-bean 为 true 时，仅会加载数据库中包含在此字段组中的那些字段。这意味着如果大多数事务都不使用加载起来很慢的特定字段，如 BLOB，则可将其从字段组中排除。同样，如果实体 Bean 有大量字段，但事务仅使用其中少数字段，则可排除不用的字段。注意：一定要确保未将同一事务访问的字段配置到不同的字段组中。否则，将会发生多个数据库调用加载同一 Bean 的情况，但使用一个数据库调用就足够了。include-updates此标志会使 EJB 容器在执行 Finder 方法之前将所有经过修改的实体 Bean 刷新到数据库中。如果应用程序对同一实体 Bean 进行的修改不止一次，并且在执行同一事务期间执行非主键 Finder，则会对数据库发送多项更新。默认情况下会启用此标志，以符合 EJB 规范。如果应用程序事务中对同一或不同 Finder 方法的两次调用可能会返回同一 Bean 实例，并且可能会在两次 Finder 方法调用之间修改该 Bean 实例，则应保持 include-updates 的启用状态。否则，可将此标志安全地禁用。如果在执行第二个 Finder 方法后又修改了该 Bean，则这样就无须向数据库进行不必要的刷新。此标志是为 cmp-rdbms 描述符中的每个 Finder 方法指定的。call-by-reference将其禁用后，送往 EJB 的方法参数是通过值传递的，这会涉及到序列化。对于易变的复杂类型，序列化的开销会相当大。请考虑在下列情况中用其提高性能： 应用程序不需要 call-by-value 语义的情况，例如，不由 EJB 修改方法参数。 或 如果由 EJB 进行修改，则无须对方法调用者隐藏所做的更改。此标志适用于所有 EJB 而不是仅适用于实体 EJB。该标志还适用于同一应用程序中 Servlet/JSP 和 EJB 之间的 EJB 调用。默认情况下会禁用此标志，以符合 EJB 规范。此标志是于 Bean 级别上在 WebLogic 特定的部署描述符中指定的。Bean 级别悲观锁定Bean 级别悲观锁定是在 EJB 容器中实现的，方法是在加载 Bean 时获取数据库锁定。实现这种锁定之后，每次仅可由单个服务器中的一项事务访问每个实体 Bean。所有其他事务都将被阻止，等待正在进行访问的事务结束。对于使用较高的数据库隔离级别（在 RDBMS 级别上开销太大），这是一种有用的备选方案。此标志是于 Bean 级别上在 cmp-rdbms 部署描述符中指定的。注意：如果锁定不是独占锁定，则可能会出现死锁情况。如果数据库锁定是共享锁定，则在使用该 RDBMS 时可能会出现死锁。并发策略concurrency-strategy 部署描述符可以向 EJB 容器表明如何处理同一服务实例中的多个线程对同一实体 Bean 的并发访问。可将此参数的值设置为下列四个值之一： Exclusive- 对于给定的主键，EJB 容器可以确保只有一个 EJB 实例，在可以通过容器序列化访问该实例的服务器中，所有并发事务共享该实例。除非不常使用 EJB 并且出现并发访问的可能性很小，否则一般无法通过这种并发设置得到良好的性能。 Database- 这是默认值，也是最常用的并发策略。EJB 容器会推迟并发控制，由数据库来执行。对于给定的主键，EJB 容器维护多个 EJB 实例，每项事务都有专用实例。如果结合此策略使用，则在确定是否应允许对持久性状态进行并发访问时，数据库隔离级别和 Bean 级别悲观锁定可以起主要作用。请注意，只要无须转到数据库（cache-between-transactions 的值为 true 时会发生这种情况），多项事务就可以并发访问 Bean。但将 cache-between-transactions 的值设置为 true 并不安全，建议不要与 Dababase 并发策略一同设置。 Optimistic- 乐观并发策略的目的在于将数据库中的锁定减到最少，同时仍然保持数据的一致性。其基本前提是 EJB 的持久性状态极少更改。容器会尝试加载嵌套事务中的 Bean，以防外层事务的隔离级别设置使得可在数据库中进行锁定。在提交时，如果 Bean 已被修改，则会用基于修改的更新确保某些其他事务不会更改其持久性状态。如果情况如此，则会引发 OptimisticConcurrencyException，应用程序必须处理该异常。 由于可以使用此并发策略的 EJB 极少受到修改，因此启用 cache-between-transactions 可以显著提高性能。通过此策略还可在提交时对已读取但未更改的 Bean 进行验证。这是通过将 cmp-rdbms 描述符中的 verify-rows 参数设置为 Read 实现的。这会使数据的一致性非常高，同时还会将数据库中的锁定减到最少。但这确实会使性能略微降低。建议使用版本列执行优化验证：因为其速度更快，可通过时间戳进行紧密的跟踪，还更不易受到修改和读取。如果将 verify-rows 设置为 Read，则经过修改的值不适用。如果在属于群集的服务器中修改乐观并发 Bean，则该服务器会在整个群集内尝试使该 Bean 的所有实例失效，以期防止引发 OptimisticConcurrencyExceptions。在某些情况下，更经济的方法可能是简单地让其他服务器出现 OptimisticConcurrencyException。在这种情况下，通过在 cmp-rdbms 描述符中设置 cluster-invalidation-disabled 标志，禁用群集范围的失效。 ReadOnly- ReadOnly 值的性能提高效果最显著。将其选中后，容器会认为 EJB 是非事务性的，还会自动启用 cache-between-transactions。以可配置的周期性间隔或在已将 Bean 以编程方式失效时从数据库中更新 Bean 状态。更新间隔会使 Bean 的持久性状态失效。这是可使用 query-caching 的唯一 concurrency-strategy。请参阅在事务之间缓存。 根据监视统计信息调整WebLogic Server 管理控制台可以报告多种 EJB 运行时监视统计信息，其中的许多信息可用于调整 EJB。本部分讨论如何使用其中的某些统计信息来帮助调整 EJB 性能。要在管理控制台中显示统计信息，请参阅“管理控制台联机帮助”中的监视 EJB。如果更愿意编写自定义监视应用程序，则可使用 JMX 或 WLST 访问监视统计信息，方法是访问相关运行时 MBean。请参阅“WebLogic Server MBean Reference”中的 Runtime MBeans。缓存丢失比率缓存丢失比率是容器无法在缓存中找到（缓存丢失）Bean 的次数与其在缓存中查找 Bean（缓存访问）的尝试次数的比率。Cache Miss Ratio = (Cache Total Miss Count / Cache Total Access Count) * 100高缓存丢失比率表明缓存大小不当。如果应用程序对 Bean 的某一子集使用（读取主键）频率高于对其他 Bean 的使用频率，则最好将缓存大小设置得足够大，以便将常用 Bean 保留在缓存中，同时按需要将不常用的 Bean 反复读入缓存或从中清除。如果应用程序具有这种性质，则也许能通过提高缓存的大小上限来显著降低缓存丢失比率。如果应用程序对 Bean 的子集使用频率未必高于对其他 Bean 的使用频率，则提高缓存大小上限可能不会影响缓存丢失比率。我们建议使用不同的缓存大小上限测试应用程序，以确定可使缓存丢失比率变得最低的缓存大小上限。服务器的内存量有限，因此总要兼顾增加缓存大小和使用内存的情况，谨记这一点也很重要。锁定等待程序比率采用独占并发策略时，锁定等待程序比率是线程锁定 Bean 时必须等待的次数与发出的锁定请求总数的比率：Lock Waiter Ratio =（Current Waiter Count / Current Lock Entry Count) * 100高锁定等待程序比率表明 Bean 的并发策略欠佳。如果适用于您的应用程序，则可通过数据库或乐观并发策略使并发数量多于独占策略，还不需要在 EJB 容器级别上进行锁定。因为锁定的持续时间一般与事务的持续时间相同，所以缩短事务的持续时间将更快地释放 Bean，也会有助于降低锁定等待程序比率。为了缩短事务持续时间，除非绝对需要，否则要避免将大量工作划分到一项事务中。锁定超时比率使用独占并发策略时，锁定超时比率是超时次数与锁定管理器访问次数的比率：Lock Timeout Ratio =(Lock Manager Timeout Total Count / Lock Manager Total Access Count) * 100锁定超时比率与锁定等待程序比率的关系密切。如果关注 Bean 的锁定超时比率，请先查看锁定等待程序比率及降低该比率的建议（还可能要更改并发策略）。如果可以减少线程锁定 Bean 时必须等待的次数或避免等待，则还可以减少等待时发生的超时数或避免超时。高锁定超时比率还表明事务超时值不当。线程进行锁定时等待的最长时间等于当前事务超时值。如果将事务超时值设置得太小，则线程的等待时间就不足以访问 Bean，会提前超时。如果情况如此，则增加 Bean 的 trans-timeout-seconds 值可有助于降低锁定超时比率。但增加 trans-timeout-seconds 的值时要谨慎，因为此举会延长线程等待 Bean 的时间，线程也是宝贵的服务器资源。此外，此举还会增加请求时间，因为请求要等待更长时间才能超时。缓冲池丢失比率缓冲池丢失比率是使请求在无 Bean 可用时从缓冲池中获取 Bean 的次数，与向缓冲池请求 Bean 的总次数的比率：Pool Miss Ratio = (Pool Total Miss Count / Pool Total Access Count) * 100如果缓冲池丢失比率很高，则必须确定 Bean 实例会发生的情况。Bean 会发生以下三种情况。 已被占用。 已被破坏。 已被删除。请在诊断问题时按下列步骤操作：1 检查已破坏的 Bean 比率，以验证该 Bean 是否已被破坏。 调查其原因，然后尝试解决问题。1 检查对 EJB 的需求（也许要检查一段时间内的需求）。 进行此检查的一种方法是通过查看显示在管理控制台中的“Use Current Count”和“Idle Beans Count”。如果对 EJB 的需求在某一时段内达到峰值，则会出现大量缓冲池丢失情况，因为缓冲池已空，无法满足其他请求。随着对 EJB 需求的下降以及将 Bean 返回缓冲池中，可能无法将许多为满足请求而创建的 Bean 存储在缓冲池中，还会因此将这些 Bean 删除。如果情况如此，则也许能够通过提高空闲缓冲池的大小上限来减少缓冲池丢失数量。可以借此将为满足高峰期期间需求而创建的 Bean 保留在缓冲池中，以便在需求又升高时再次使用这些 Bean。已破坏 Bean 比率已破坏 Bean 比率是已破坏的 Bean 数与对 Bean 的请求总数的比率。Destroyed Bean Ratio = (Total Destroyed Count / Total Access Count) * 100为了减少已破坏的 Bean 数，BEA 建议除了要破坏 Bean 实例的情况，否则不要从 Bean 代码中引发非应用程序异常。非应用程序异常是指 java.rmi.RemoteException 异常（包括从 RemoteException 继承的异常）或者未在 EJB 的 Home 接口或组件接口方法的 throws 子句中定义的异常。一般而言，应该调查导致 Bean 被破坏的异常，因为这些异常可能会降低性能，还可能表明 EJB 或