HP OpenView on the WebLogic Platform帮您在J2EE和.Net应用程序中隔离应用程序性能问题。
您可能每天都面对着一些开发挑战。您需要时刻紧跟各种新兴技术，承受客户要求提前交货的压力，并希望构建可伸缩的健壮架构。人人都知道优良性能对于应用程序成功的重要性。我们进行着各种努力来设计和构建应用程序，以确保这些应用程序是可伸缩的健壮应用程序。在开发期间，我们可能还要做一些测试，以确保应用程序能够尽显其能。但性能管理往往成为一种马后炮，并且直到客户在使用该应用程序的过程中遇到问题，性能管理才被看成一个关键问题。
在客户发现问题时，如果有一个简单的应用程序，那么诊断该问题可能不是很困难。然而，您很可能正在使用集群应用服务器、Web service、Java消息服务（JMS）、企业JavaBeans（EJB）和其他分布技术。当收到一个支持请求时，如“the application response time is too slow”，您可能要花上几个小时甚至几天的时间来查明问题，而您往往没有足够的信息来确定问题发生的原因。这会使您进退两难：若想花更多时间来学习某一新技术，或者只想多编写一些代码，那么您必须在这些愿望和支持该应用程序的业务需要之间进行权衡。那么现在该如何处理这些性能问题呢？
我们先来了解一下处理紧急性能问题的传统方法。我们都很熟悉用于测量方法调用时间的可靠的System.out.println方法。除了必须将各个方法的执行时间与终端用户的体验关联起来这种情况以外，这项技术在其他情况下都非常有用。电子表格和计算器在此可能会帮上忙，但它们很费时间。
Time Eater
或许还要使用各种操作系统工具（如top、vmstat和netstat）来帮助您诊断问题。如果该应用程序使机器的CPU利用率达到了100%，那么可以使用HP OpenView Glance系统监控器之类的工具来仔细分析问题。如果出现线程争用或Java内存问题，则可使用特定的Java虚拟机（JVM）分析工具来识别瓶颈。通常，这些工具的级别太低，难以让您了解哪个应用程序层或组件在影响终端用户的体验。
或许您已有幸使用过一些应用程序管理工具。或许您正在利用WebLogic管理控制台来获取某些应用服务器统计信息。您可能已经在应用程序中使用了Log4J、ARM或JMX，以便更好地了解其内部工作情况。即使在这些情况下，您所使用的工具通常也只是提供部分答案，您还必须把疑点综合在一起来解决问题。
简而言之，许多诊断性能问题的时间性可能非常强。第一或第二线的操作支持小组通常对技术了解得不够多，对棘手问题不能提供很多帮助，因此会将问题留给您自己去追踪。或许问题没有涉及到应用程序代码，它可能只是一个环境问题（如网络问题）或数据库问题，但是在发现该事实的过程中，您可能浪费了三天时间来支持该应用程序，而不是使其增强。
诊断性能问题 （续）
为了解决这些难题，一些管理供应商创建了应用程序性能管理（APM）产品，如HP OpenView Transaction Analyzer（OVTA）。在J2EE和.NET应用程序中，OVTA可以帮助您隔离应用程序性能问题，而不是花费大量的时间来添加一些System.out.println()语句，试图精确地识别性能瓶颈发生在哪里。现在您就可以使用一个提供有关应用程序性能的详细信息的工具。
OVTA可以捕获端到端用户事务信息，OVTA会通知您用户事务是否已顺利通过了不同的应用程序层，其中包括客户端浏览器、Web服务器层、应用服务器层和数据库层 （参见图 1）。它将在一个一直通向最小的J2EE组件的给定事务中展示性能瓶颈的位置。
捕获端到端用户事务信息之后，OVTA会通知您用户事务是否已顺利通过不同的应用程序层，其中包括客户端浏览器层、Web服务器层、应用服务器层和数据库层。
现在，我们可以在代码中制造错误，特别是在我们快速进行代码分析和代码组合的时候。一旦完成开发代码的工作，该如何确定它是否存在内存泄漏或线程锁争用问题呢？通过使用OVTA Java Diagnostics（OVTA-JD）工具（一个OVTA组件），可以快速确定应用程序是否存在内存泄露，并查找所有代码级的性能瓶颈的位置所在。
OVTA的好处是无需对源代码进行任何修改就可以收集这些信息片段。而不是花费一整天时间单步调试代码的各个方面来寻找瓶颈，您可以使用OVTA快速诊断应用程序中的性能瓶颈。
性能管理
展示OVTA价值的最好方法是通过一个场景来演示如何识别和解决应用程序性能问题。在本例中，我们假定某个操作人员正在监控应用程序。他们可能使用HP OpenView Internet Services （OVIS）来探测各种HTTP服务，以确定应用程序的总体可用性和性能。
假定一个操作人员完成了问题根本原因的分析，并发现应用程序没有按照规定的服务级别执行。该操作人员请求您查看该问题，但是，除应用程序的响应时间频率是可接受频率的一半以外，他没有告诉您其他任何信息。让我们来看看如何使用OVTA解决这个问题。
首先，让我们了解对使用OVAT的J2EE活动的一个概括（参见图 2）。使用Navigation面板，打开HTTP文件夹并单击对应于应用程序的URL。在本例中，我们将监视运行在WebLogic上的一个应用程序，而且可以在右边的面板中看到对Java Page Flow（JPF）的调用。
使用OVTA 中的Navigation面板打开HTTP文件夹，并单击对应于应用程序的URL，以监视运行在WebLogic上的一个应用程序。
Summary视图显示了应用程序的活动，如事务的总数和OVAT探测到的违规行为的总数。违规行为指的是响应时间超过配置的阈值的行为。在Violations框中我们看到，在请求casedetailscontroller.jpf的880个请求中，有653个请求违反了响应阈值。
可以单击该链接来深入研究并获取有关特定事务的具体分析信息（参见图 3）。服务器响应率通过Tier部分突出显示了消耗在这个页面流的各个层中的时间。OVTA通过网络层、应用层和数据库层对事务进行分类。因为这是一种以可视方式在J2EE应用程序的不同部分中隔离问题的简便方法，所以这种分类特别重要。我们还得到了针对该页面的所有调用的基线图，以及一个有用的数据柱状图。从图中可以看出，服务器的响应时间太长，因此有大量针对该事务发生的违规行为。
服务器响应率通过Tier部分突出显示了消耗在这个页面流的各个层中的时间。OVTA 通过网络层、应用层和数据库层对事务进行分类，提供了一种以可视方式在J2EE应用程序的不同部分中隔离问题的简便方法。
从该视图中可以看出，是应用程序导致这个问题，所以让我们进一步深入研究，以获得一些补充细节。可以配置OVTA来提供一些级别的追踪信息，在需要搜索应用程序的瓶颈时，这些信息非常有用。我们可以观察Trace视图，仔细查看这个事务中使用的J2EE组件。（参见图 4）。
观察Trace视图，仔细查看事务中使用的J2EE组件。
该视图可以帮助我们确定应用程序中瓶颈所在的位置，以及损坏了的J2EE 组件的位置所在。我们可以看到一个事务概括，这些事务是根据网络层、应用层和数据库层进行分类的。我们还可以看到，大约一半的响应时间都花费在了应用程序上，此外，我们展开了Application文件夹，并确定Query.executeStored()操作将失败。
深入研究
该问题开始的时候看起来更像是一个数据库问题。如果展开Database文件夹，就可以看到，当我们试图使用DataSource.getConnection ()连接到数据库时，我们失败了。蓝条指出了特定组件的专有时间，所以看起来我们好像已经隔离了数据库层性能问题。
什么可能导致连接失败呢？我们可以通过查看应用服务器的整体健康状况来进一步诊断这个问题。OVTA使用JMX工具从BEA WebLogic Server中自动收集了许多应用程序度量标准。比如，等待执行的请求数量、等待JDBC连接的请求数量或等待EJB的请求数量。
如果查看应用程序的视图，就会立刻看到存在JDBC连接等待问题，该问题已经用红线画出来（参见图 5）。在深入分析后，可以确定该问题不是一个代码问题，事实上它是一个关于JDBC池大小的配置问题。通过WebLogic Administrator控制台，可以查看当前JDBC连接池的大小，并确定是否可以增加这个大小，或是否要对该部署进行更复杂的更改。
红线画出了一些JDBC连接等待问题。
从这个视图中可以看到，我们还可以监控JVM内存的使用情况来确定内存使用是否超出。因为我们对在这里看到的模式是否正常还不是很清楚，所以需要进一步进行Java诊断。通过使用OVTA Java Diagnostics（OVTA-JD），可以得到了一个以JVM为中心的应用程序视图，该视图提供了JVM实例状态的更深入的信息。OVTA-JD为监控和分析CPU热点、内存泄露和线程争用问题提供了工具。
因为已确定可能存在一个内存问题，所以我们可以更深入地查看垃圾收集活动（参见图 6）。该工具既能识别重量级垃圾收集，又能识别轻量级垃圾收集。我们想要寻找所有消耗更多时间的额外的重量级垃圾收集，这可能意味着需要调整JVM堆的大小。我们还可以查看花费在垃圾收集活动上的时间的百分比，这特别重要，因为许多性能问题都归因于垃圾收集。
OVTA-JD工具既能标识重量级垃圾收集，又能识别轻量级垃圾收集，使您能更深入地查看垃圾收集活动。
我们已经了解了APM工具如何帮助您快而轻松地诊断应用程序中的性能问题。基于我们使用OVTA的经验，在任何可能需要评估的APM解决方案中，显然都存在一些您想寻找的重要要求。其中的一项要求是，该工具不能要求通过修改源代码来实现问题诊断。您不用担心会在应用程序中添加额外的指令代码来收集性能数据。对工具而言，提供一个应用程序性能的端到端视图很重要。如果您不能将数据与终端用户的体验关联，那么低级的J2EE分析工具几乎不起什么作用。端到端的、面向事务的工具可以将诊断时间缩短为仅仅几分钟的时间，这样您可以快速确定导致瓶颈的是应用程序，还是其他外界因素。
到团队中去
支持团队经常听到的最大的抱怨之一是：“我们无法再现这个问题。”必须以某种既能在预生产测试环境中操作又能在生产环境中操作的方式来开发一个APM解决方案。这个解决方案需要一个低开销的工具，该工具应该能够足够灵活地只收集分析应用程序所需的追踪数据。另外，当您想独立工作的时候，不能忽视操作人员的需要。该工具必须与现有的企业管理系统集成在一起，生成一个更加集成的解决方案，该解决方案可以支持针对需求情况的监控、报告和报警。
这里的一个特点是，操作人员和开发人员必须有效地协同工作来诊断性能瓶颈、内存泄露和其他源代码性能问题（参见图 7）。这种协同工作需要一个自上而下的工具（如 OVTA）和一个JVM级分析工具，如 OVTA-JD，在运行Java和J2EE应用程序时，此工具能够执行应用程序级别的分析。
操作人员和开发人员必须有效地协同工作来诊断性能瓶颈、内存泄露和其他源代码性能问题。
最后，任何解决方案都必须承认的一个事实是，应用程序变得更加分散并且种类更多。今天的应用程序常常包括一些能同时运行在J2EE和.NET上的组件。完整的APM解决方案必须提供能够跨越这些应用层来查看应用程序性能的单独视图。该工具还必须利用开放标准和管理应用程序平台的技术。这些技术（如 JMX）有助于监控和评估BEA WebLogic和其他J2EE应用服务器的整体健康状况。其他度量标准（例如，JVM内存利用率）可用于把服务器的健康状况和应用程序的性能关联起来。
使用这些准则，您可以选择正确的工具来帮助您标识性能问题，并且有希望在这些问题出现在生产过程中之前标识出它们。然而，这就是构建一个更易于管理的、可维护的应用程序的全部吗？
我们不想给您留下这样的印象：解决生产过程中出现的应用程序性能问题一直是开发人员的职责。在理想情况下，开发人员要在部署应用程序之前对其进行充分测试，并使用诸如OVTA之类的工具来寻找瓶颈。不过，当问题确实发生在生产过程中时，人们通常会对开发人员有一种依赖，因为可用的信息不足以使他们解决应用程序问题。作为一名架构师，您的目标是设法使您的应用程序更易于管理，从而最大限度地减少需要您提供的IT支持。
设计应用程序时就考虑到可管理性会给您的组织带来一些显而易见的好处。通过正确设置应用程序公开的管理界面，操作人员可以确保获得更高的应用程序可用性。而且还可以使可管理的应用程序在生产过程中更具灵活性和适应性。例如，在我们的场景中，可用的WebLogic JMX MBean公开的管理界面允许我们改变JDBC连接池的大小，而且不需要重新启动应用程序。
超越性能管理
做什么才能使应用程序更具可管理性呢？幸运的是，许多应用程序平台提供了一些开箱即用的管理特性。例如，BEA WebLogic Platform公开了JMX界面，一些管理系统（如HP OpenView）可以使用该界面。不过，在许多情况下，平台级管理对于有效管理生产中的应用程序而言是不够的。在设计应用程序之前，需要使用其他设备来公开应用程序级管理界面。
如果您是一位开发人员或架构师，您会不停地问自己：“为了使我的应用程序在生产中更易于管理，我能做些什么呢？”您可以执行下列步骤：
- 在应用程序设计之前，确定针对可管理性的具体需求。
- 了解可用于可管理性的技术，以及什么时候将每项技术应用到给定的管理问题中。
- 为构造可管理应用程序做出正确的设计选择。目的是将管理层与应用层隔离开来，在适当的地方充分利用设计模式。
可以在隔离环境下开发应用程序，但不可能在隔离的环境中运行它。应用程序对应用服务器、数据库和其他IT基础架构组件产生了依赖。这个更大的管理生态系统要求在所有层次上都有正确的可管理性级别，并要求开发人员在此扮演重要角色。
这个管理生态系统的一个重要组成部分是应用程序所有者所扮演的角色，他们负责确保自己所拥有的应用程序的可用性和性能。完整的应用程序管理解决方案应该允许应用程序所有者全面监控、管理和控制其应用程序环境。应用程序拥有者必须能够像他们的顾客那样查看应用程序，了解底层基础架构所产生的影响，从而快速离析导致问题的根本原因。（参见图8）。
完整的应用程序管理解决方案允许应用程序所有者监控、管理和控制该应用程序环境。拥有者应该能像他们的顾客那样查看应用程序，以了解底层基础架构所产生的影响，并能快速离析导致问题的根本原因。
OVTA提供查看应用程序的能力只是该解决方案的一个方面。在诊断问题之前，必须知道确实存在这个问题。完整的管理解决方案还应当提供一个顾客体验视图，允许对应用程序的可用性进行监控，这也正是HP OVIS发挥其作用的地方。
应用程序管理还涉及了解IT基础架构所产生的影响。通过HP OpenView Operations，操作人员可以轻松地映射底层基础架构和主动监控底层基础架构，这些基础设施支持您在WebLogic Platform上部署应用程序。通过使用用于WebLogic Server和WebLogic Integration的WebLogic Smart Plug-In（SPI），操作人员可以主动监控其Web应用程序和业务流程。面向开发人员的工具JMX Metric Builder有助于将所有JMX界面映射到OpenView环境中。
BEA和HP共同协作为您提供了一些管理解决方案，以确保在WebLogic平台上获得较高的稳定性、有效性和灵活性。通过OpenView Smart Plug-In和其他技术，如OVTA，HP OpenView早已开始支持WebLogic Server、WebLogic Integration和WebLogic Portal。作为BEA首选和优先选择的管理伙伴，HP一直在为进一步增强这些管理解决方案、使更多健壮并独特的管理功能更加强大而做出贡献。
未来展望
下面一些重要步骤可以使您对应用程序管理解决方案有更多的了解：
- 从http://openview.hp.com/downloads下载OVTA的评估版。大概需要几分钟的时间，您就可以安装并配置该工具来监控运行在BEA平台上的J2EE应用程序。
- 可以在HP Dev Resource Central（http://devresource.hp.com）上了解有关应用程序可管理性的更多信息。该站点提供了各种白皮书、代码示例和JMX开发人员教程。
最后，若想了解关于HP OpenView和BEA应用程序管理解决方案的更多信息，请访问http://openview.hp.com/bea/。您会发现，BEA和HP的OpenView共同为您提供了更多的控制和灵活性，为您带来更大的竞争优势。
|
