除了应用的执行事务分析，J2EE健康检查也包括了系统配置检查。 PerformaSure从J2EE系统的不同部分搜集数据，如操作系统、JAVA虚拟机、应用服务器，应用事务。当分析J2EE系统时，快速地和容易地 从各层关联不同的度量值很重要。通常一个地方的资源竞争将很快引起另一个地方或更多地方的故障。

    以下度量值只是这些度量值的样本，如果经常检查核对，能够保证你的J2EE站点更加稳定和更好运行。

应用服务器执行队列状态

    通过使用线程池处理每个请求的方式，应用服务器管理在容器中执行的众多事务。在应用服务器中有一些预先定义好数量的线程，用于处理每个请求。

请 求进入应用服务器容器，容器就指派一个线程处理该请求。当处理完后，执行该请求的线程就为空闲状态并返还给池，供其它请求使用。如果有大量的可用线程并且 系统没有饱和，你将看到一些闲置的线程并且执行等待队列是空的；如果请求数超出系统能处理的数量很多，你将看不到闲置线程，并且执行队列中显示有一些请求 在等待可用线程。这个等待表现为响应最终用户的时间增加了。对于系统使用高峰时，这短时间的等待是可接受的，你应该确保等待执行线程的时间绝不能超过系统 使用的瞬时突发时间长度。

    你能够通 过分析应用服务器中闲置线程的数量，特别是通过执行队列长度，快速地判断出系统的健康情况。如果执行线程池大小设置合理，在系统达到使用高峰突发期间，你 应该看不到闲置的线程，并且当执行队列长度不断上升时，执行队列长度仍然可以管理；一旦过了高峰期，执行队列长度就立刻下降到0。

    在这种情况下，我们能够看到应用已经经历了一个高负载的突发。闲置线程数在短时间内减少为0（这是我们所希望在这些短时突发时间内应该发生的）并且执行队列增加，但很快降了下来。从这里可以看出执行队列池大小是近似最佳值。

有状态EJB池分析：钝化

    在 应用服务器中存储状态数据的一个方法是使用有状态会话EJB。当用户登录到应用时，这些EJB保存用户的状态数据。WebLogic设置这些bean池用 于给登录的用户分发bean。用户进入应用并且登录后，他们从池中获得一个有状态的会话bean。当他们退出应用则bean中的数据被清空并且归还给池。

    如 果用户没有手工地退出应用，这时他们的状态会话bean将变成非活动状态，但还不能归还到池中供其它进来的用户使用，直到该状态会话bean超时（默认情 况下超时时间为30分钟）自动退出。如果在任何时候含有闲置bean的池为空，当新的用户要登录应用时，就得使用一个称为钝化的处理方法以确保得到有状态 会话bean。当发生钝化时，当前已被使用的，最早处于非活动状态的bean中的数据将被保存在物理硬件驱动盘上；这时该bean中的数据将被清空并返回 到池中供新的用户使用。这个bean超时后，那些保存在物理硬件驱动器上的数据将被清除掉。

     虽然钝化确保了每个进来的用户都能得到有状态的会话bean，但也给性能带来了极大的危害。因为应用服务器为了给每个新用户一个状态会话bean，需要完成一些额外的工作。

     Chart 7显示了Shopping Client Controller Stateful Session EJB被钝化的数量。Chart 8显示了Category请求类型的响应时间，该请求使用了图7中的有状态bean。

    在这种情况下我们能够看到应用服务器钝化了一些在Category用例中使用的有状态会话bean。这就引起响应时间越来越慢，直到变成不可接受的平均每请求10秒。

     可以考虑以下措施：

     1) 增加有状态会话bean池中的bean数量。在这之前，你应该确认JVM中有足够的空闲内存。增加bean池的大小将导致更多的潜在对象存活在堆中，这就 需要很多的内存。如果平均JVM堆使用率超过70%，这时应该考虑增加JVM堆大小的最大值（假设有足够的物理内存，通过－Xmx参数传递更大的值）或者 采取以下措施。

     2) 缩短有状态会话bean的超时时间。尽管如此，确保超时时间至少是请求返回时间的三倍，这个返回时间是你所期望的最长时间。例如，如果系统处理用户请求返 回结果的最长时间是2分钟，则最小的超时时间设置为6分钟。大部分情况下，开始时把超时时间设为最长请求返回时间的5到8倍，然后从这点开始慢慢调整。