J2EE健康检查示例
内容
第一部分：执行概要
第二部分：分析过程
- 事务分析
- Verify Sign In事务：详细分析
- 度量值分析
- 应用服务器执行队列状态分析
- 有状态EJB池分析：钝化
J2EE健康检查报告
最近，我们使用Quest Software公司产品对贵公司的J2EE应用实施了一次健康检查。这次健康检查具有两个目的：第一，针对应用中可能需要改进的地方进行一次补充评估；第二，向贵公司介绍我们的解决方案是如何改进您的关键业务应用的，这些解决方案可以提供卓越的可视化能力，实时地监测J2EE系统。
作为健康检查的一部分，我们的专家将帮助你的团队部署Quest Software的PerformaSure，它是J2EE应用管理软件包中的一个组件。通过使用这个解决方案，就能够立即对系统的配置和性能作出评估。这个报告包括易于理解的事务分析和最终用户体验；也包括用于帮助确定资源竞争问题的系统配置分析，这些资源竞争问题可以影响应用的性能和可用性。基于搜集的数据，我们可以提供专家分析和建议，用于最大化J2EE系统的性能和可用性。
实现以下改变将显著提高应用的性能和可测量性，改善用户体验：
应用负载平衡分析：
业务影响：高
解决难易程度：容易
描述：贵公司的应用有严重的集群不平衡迹象。当应用负载达到高峰时，这极大地影响了系统能够处理的最大用户数的期望值。WebLogic管理者为了找到成本最低的最佳解决方案，通常去检查机器的影响。具体的信息将在后文描述。
Verify Sign In事务分析：
业务影响：高
解决难易程度：容易
描述：用于核对用户档案与已存储记录是否一致的Verify Sign In事务对每个用户的响应非常慢，每用户的大多数响应时间为5秒。这个超过了内部性能SLA（服务等级协议） 3秒多，导致了每小时超过10个用户被抛弃。
具体诊断信息参见后文。
用户请求的容量分析：
业务影响：N/A: 运行良好
解决难易程度：不需要
描述：该应用服务器配置得当，在WebLogic中已经配置了足够多的执行线程，在负载高峰时可以处理预期的所有用户负载。因此，一旦解决了概要中第一点提到的集群不平衡问题，该服务将具有充足的容量能力。尽管如此，当用户负载可能快速增加并且未发出警告时，系统管理员应该继续监测在生产环境中的执行线程情况。
更多的详细信息在以下报告中。
用户处理性能分析：
业务影响：中－高
解决难易程度：非常容易
描述：这是因为当前在EJB层没有足够的资源用于处理用户请求。这将导致用户在使用购买产品或服务等功能时，等待时间过长。因为这个问题与系统的负载有关，一旦该问题被触发，将急剧恶化以至失去控制，最终导致应用不可用。
通过增加资源和有效的资源分配，这个问题可以很容易的解决。具体的解决方案建议在后面给出。
分析过程
整个J2EE应用管理解决方案搜集的信息对于IT团队的各级成员都是有价值的，它包括向IT经理提交的报告，也包括向应用管理员和数据库管理员提交的诊断和调整建议。这个报告集中描述了该解决方案中强大的J2EE诊断能力。看到这个报告，及其所提供的数据质量和分析质量后，我们相信你将能够在报告中找到更多的信息，帮助你监测，管理和诊断关键的J2EE，打包的应用和数据库系统。
在诊断J2EE系统时，主要有两种问题：事务问题和环境配置问题。这些事务问题的根本原因是应用代码中的错误。在J2EE健康检查报告中，我们把分析过程分为两部分：事务分析和配置分析。
事务分析
通常事务问题表现为响应时间过长。这可以通过监测软件发现，如Quest's Foglight，或者通过最终用户反映比较慢的事务。对其中任何一种情况，重要的是分析者都能够快速地找到问题的根源，因为响应时间太长会对业务产生严重的影响：用户可能因此放弃这个商业网站而转向其对手；陈旧的数据可能危害业务的执行能力；合作伙伴可能不能按时完成订单；一系列的事务可能不得不回滚，给用户造成不便或者由于反复的批处理运行导致资源浪费。
要避免像以上概括的高成本问题，首先要为应用设置服务等级协议或者性能目标。为了达到这些目标，我们的顾问将同应用团队一起工作，根据业务特有的需求确定响应慢的事务都是哪些。
下表显示JAVA应用中响应最慢的前三个事务。
正如你看到的，Verify Sign In事务是消耗时间最多的，它的运行响应时间为平均每请求4.8秒。其中主要在WebLogic Application Server层消耗时间，大约消耗了事务总响应时间的73%。
通过观察按机器分解的数据，我们能够看到应用还存在一个严重的负载平衡问题（如下图所示）。
通过上表和屏幕截图的上部分，我们能够发现XX1节点只贡献了总时间的9.4%，而XX2几乎贡献了总时间的45%。向系统组咨询后，可能是由于WebLogic的软件负载平衡器配置不当。
Verify Sign In事务分析：
继续分析应用的Verify SignIn事务。要找到引起请求慢的性能瓶颈根源，我们需要使用PerformaSure Tree View。
在这种情况下，主要的瓶颈是以下方法：ShoppingClientControllerEJB.getProfileMgr()。知道方法级瓶颈的位置将使开发人员很容易快速地调整该方法，提高应用响应时间。
PerformaSure也允许你发送这个问题的配置文件给使用JProbe的开发者，使用JProbe的Profiler能够得到代码行级性能和对象分配数据，更快和更容易解决问题。
度量值分析
除了应用的执行事务分析，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倍，然后从这点开始慢慢调整。
（北京铸锐数码科技有限公司 www.InnovateDigital.com）
|
