简介

　　即使是经验丰富的 Java Web 开发人员也会惊讶于开发门户这一如此巨大的飞跃。最终用户看到的那个简单漂亮的界面的背后是像BEA WebLogic Portal 这样的商业产品提供的强大功能和复杂性。当门户应用程序处于生产阶段时，诊断性能问题就会显得格外的困难。

　　本文讨论了 WebLogic Portal 在性能管理方面存在的一些挑战，并为在门户应用程序内进行性能瓶颈调优提供了一个很好的起点。本文假设您对WebLogic Portal的功能和术语已经十分熟悉。

　　一个公司的门户能让公司更有效地利用其技术和人力资产，而同时又能为其员工、合作伙伴和客户提供一流的Web体验。由于这个原因，门户应用程序现在对业务来说十分关键，并且要能提供可靠的性能和可扩展性。BEA WebLogic Portal 是一种领先的基于Java EE 的门户服务器，可提供部署和运行门户应用程序的健壮的解决方案。

WebLogic Portal 架构

　　BEA WebLogic Portal 在一个完整的Web门户开发和交付平台中综合了统一的运行时框架、业务服务和生命周期管理技术。它可针对数千最终用户扩展并支持连续更改。

　　图1 显示了 WebLogic Portal 架构。在门户被实例化时，它会生成门户资源的分类或层次，即所谓的WebLogic Portal 控件树。控件树包括desktop、book和portlet。如您所见，控件树对于理解门户应用程序中的性能问题至关重要。

　　图1. WebLogic Portal的层次化架构

　　门户的基本构建块是portlet，portlet是小的门户应用程序，在Web页内通常描述为小盒子。它们是可重用组件，可提供到应用程序、基于Web的内容和其他资源的访问，并且可以访问和显示Web页、Web服务、应用程序和连锁内容提要。

　　Portlet 相互独立开发、部署、管理和显示。管理员和最终用户通过选择和安排portlet可以创建个性化的门户页，这样一来， Web 页就可针对个人、团队、部门或组织量身打造。Portlet 依赖于门户基础架构来访问用户配置文件信息、参与窗口和动作事件、与其他portlet 通信、访问远端内容、查找凭证和存储永久数据。

　　由于portlet 也是servlet，所以它们共享类似的重入和性能关注点。单一的 portlet 实例（即portlet 的 Java 类的单一实例）由所有请求者共享。由于处理portlet和 servlet 的线程数量有限，所以每个 portlet 要能尽快地完成其作业，以便整个页的响应时间能够得到优化，这一点非常重要。

理解控件树

　　WebLogic Portal 控件树代表门户内的所有结构元素，可充当构建新门户页所需的基础架构。在实例化门户时，新控件树在控件树处理期间创建（或从缓存清除，如果控件树已经存在）。门户性能的一个巨大阻碍就是门户内的控件的数量。门户控件越多（页、portlet、按钮等），控件树就越大，呈现所有组件所需的时间越长。

　　图 2 显示了一个为典型的门户所生成的控件树。由desktop 和 shell 创建一个主 book 和6个子book，而每个子book各包含2个页。每个页包含2个 portlet。所以，整个门户共包含至少42个控件。

　　图2.一个门户实例的典型控件树

　　一旦控件树构建完毕且实例变量也设置成功，在门户被完全呈现之前，此树必须在整个生命周期针对每个控件运行。生命周期方法被顺序调用。即，调用每个控件的 init() 方法，然后是每个控件的loadState() 方法，等等，调用的顺序由每个控件在门户分类图中的位置决定。

　　在生命周期运行每个控件需要一些开销处理时间，如果门户有数千个控件，这一时间就有可能会按指数级增长。因此可见，门户控件树越大，对性能的影响就越严重。

在 WebLogic Portal 中监视性能

　　门户的性能主要表现在当用户单击对象向门户servlet发送请求时，实际呈现该门户及其所有组成部分所需的时间。

　　面临的第一个困难是如何监视和测量门户的整体性能。内置的管理功能并不能充分满足整个系统，特别是各个门户组件（包括portlet 以及由WebLogic Portal容器运行的其他代码）、到任意或所有数据库的连接、事务服务器、主机系统和其他终端系统。

　　无论使用的是何种工具，该工具都需要能：

• 监视跨整个工作流发生的以及在各个过程中发生的那些复杂的动态交互。
• 能简洁直观地显示结果数据，以突出所存在的问题（以及在门户工作流中发生的位置）并让管理员能快速向下钻取（如果需要，可钻取至各个portlet 或事务）以发现问题的根源。
• 总结整体性能以及关键的门户工作流领域（门户servlet、控件树处理、JSP backing文件、Java页面流、portlet、到后端系统的连接以及门户服务）中的性能。

应该监视什么以及常见问题

　　可能影响门户性能和可用性的潜在因素有几个。以下内容讨论了应该监视什么以及常见的问题有哪些。

门户请求响应时间

　　由于门户是个性化的Web应用程序，所以很有必要像最终用户所经历的那样测量门户的性能。通过测量事务响应时间，门户管理员就能在问题影响用户和业务之前提前采取相应措施。

控件树处理

　　前面提到过，WebLogic Portal 控件树代表门户内的所有结构元素，可充当构建新门户页所需的基础架构。在用户-接口设计中的所有元素都会对应于树中的控件。所以要监视在控件树内发生的复杂的处理以及它与门户的“查看”和“控制”元素间的交互。图 3 显示了性能调优工具是如何突现控件树中的性能问题的。

　　图3. 凸显控件树中的性能瓶颈

Portlet

　　应用程序、基于 JSP 的 portlet、Web Services 或其他可用的 J2EE 资源均可作为portlet 公开。如果出现了性能下降，应用程序支持人员就应该能立即确定引起性能下降的是哪个portlet。在portlet 生命周期，处理回发数据和预呈现的那些过程对于性能监视尤其重要。

Portal Framework 服务

　　JSP backing 文件与 JSP 协同工作，允许表示逻辑与业务逻辑分离。Backing 文件总是在JSP之后运行，它包含大量的定制呈现代码（另外，一些开发人员还会向终端系统进行callout 来获取额外的呈现数据）。不佳的性能常常预示着定制呈现代码可能不正确。

　　在 Java 页面流，页面流本身完全由开发人员定义。速度上的减慢常常能由其作者诊断出来，并不会对终端系统造成很大的影响。将 J2EE 标准页面流与门户控件树处理架构关联起来还可确定某个页面流与哪个desktop 相关，这一点也非常有用。

WebLogic Portal 服务

　　Entitlement 系统为各个门户资源提供了基于角色的授权。Entitlement 被门户的所有方面大量使用，所以任何的减慢都会影响到整个系统。通常，延时的响应和迟滞的线程大多都是由支持Entitlement的后端系统，比如LDAP，内存在的问题引起的。此外，对太多的对象进行细粒度的授权也会加大Entitlement 系统的开销。

　　Personalization 服务通过advislet 实现，用来修改在门户首选项中显示的信息。Advislet 可使用多种机制，比如内部规则引擎、显式个性化，甚至事件。过度使用Personalization 系统也常常会引起性能问题。

　　User Profile 存储库包含额外的用户信息，比如联系信息。通常，延时的响应和迟滞的线程大多都是由于后端系统存在的问题，比如用于支持用户配置文件的数据库，引起的。

　　Content Management API 与很多可用的商业内容管理系统（比如Documentum）接口。如果这里产生了迟滞的线程，首先需要检查的就是后端内容系统是否工作正常。

结束语

　　我们非常希望本文能够提供有用的信息，以使您对由WebLogic Portal 应用程序的性能问题有所了解。随着企业门户所提供的内容的日益复杂和普及，管理其性能和可用性的挑战性也随之增加。借助合适的工具和处理，基于门户的应用程序还是可以信赖的，能够实现它们所预期的业务价值。