在 WebSphere Application Server 中处理静态内容

来源：互联网发布：大数据开发工具编辑：程序博客网时间：2024/05/01 00:09

WebSphere Application Server 管理员关注如何使 Application Server 环境的功能发挥至极限。这个决定涉及到了决定在哪里服务静态内容和动态内容。作者 Kyle Brown、Bill Hines 和 Keys Botzum 对将静态内容和动态内容部署到 Web 服务器和 Application Server 上的几个不同的方案进行了评估。

引言

您刚刚带着您那崭新的超大 25 立方英尺的冰柜从 Bulk-Stuff-R-Us 回来。接下来您会把放在楼上厨房里的冰箱的冷藏室倒空，并将所有的东西都保存在放在地下室里的新冰柜吗？当然不会 ? 这样做是不经济的。在这种情况下，楼上空冰箱的贮藏与致冷功能将会被浪费掉，并且还使得您每次想享受一个冷冻比萨饼作为夜宵时，要走一段不必要的路程从楼上下来。作为一位 IBM®WebSphere® Application Server（以下称为 Application Server）管理员，您可能要面对完全一样的问题：您会把 Web 服务器放在楼上的“常用区”并把 Application Server 放在地下室的“安全区“吗？

回页首

问题

WebSphere 管理员常常关注如何使 Application Server 环境的功能发挥至其极限。I/T 管理人员则常常关注如何利用在硬件和软件上的投资以及如何节省成本。然而，采取最简单的途径来配置站点可能无法达到这些目的。新接触 Application Server 的管理员可能会采取最简单的方法，他们遵循 J2EE 的精神，将整个应用程序部署到 Application Server 上。使用这种方法，应用程序的运行时组件（servlet、JSP 和 EJB）和静态内容（HTML 文件和图形图像）都被部署到了 Application Server。一位更成熟的管理员明白这些静态组件会被这个拓扑结构的其他部分更加有效地服务（如同它们在“应用程序服务器”出现之前一样）。然后这个管理员会开始问道：“事实上静态内容应到哪里去呢？”

J2EE 的打包结构为所有的 WebSphere 应用程序回答了这个问题。在 Servlet 2.2 规范中，Sun 引入了 Web 归档文件（Web Archive（WAR））文件。WAR 文件是一个 ZIP 格式的文件，它包括所有已编译的、组成逻辑 Web 应用程序的 Java 代码。根据这个 servlet 规范，一个 Web 应用程序可以包含 servlet、JSP、实用程序类、静态文档、客户机端 applet、bean 和类以及描述性元数据（meta-data），这些元数据“将以上所有元素结合在一起”（Sun，第 43 页，主要指的是 web.xml 文件）。这里是一个层次结构示例：

图 1. 层次结构示例

WebSphere Application Server 4.0 和 5.0 要求所有的 Web 应用程序都被打包成 WAR 文件来部署到应用程序服务器上；WebSphere Studio 帮助把所有 Web 应用程序打包到一个 WAR 文件中。一个 WAR 文件可能不仅仅包括 servlet 和 JSP 的 Java 元素，还可能包含静态内容（HTML 页面、GIF 文件和 JPEG 文件）。像 WebSphere Studio 这样的工具使得打包变得容易，因为它们在静态内容和动态内容之间配置链接、验证链接并帮助识别和修复坏引用。

但是，尽管 WAR 文件的打包结构是 WebSphere Application Server 所要求的，但是请不要想当然地认为所有的站点都会用“将静态内容放置在即将被部署到 WebSphere Application Server 的 WAR 文件中”来回答这个问题（“应将静态内容放置在哪里？”）。首先，您应当回答这个问题，“用户可以从哪里获得静态内容？”

静态内容被返回到用户的方式至少有三种。它们是：

静态内容通过 WebSphere Application Server 中的 File Serving 功能从 WAR 文件返回（缺省情况）
静态内容从 Web 服务器返回
静态内容从 Caching Proxy Server 返回，如从 WebSphere Edge Server（以下称为 Edge Server）产品中的 Caching Proxy Server 返回。

假设 Web 服务器和 Application Server 被部署到不同的物理机器上。那么各个文件应放到哪里，同时部署静态内容和动态内容（servlet 和 JSP）的最好方法又是什么呢？

让我们考虑一下我们在前面的讨论中提出的三个逐渐复杂的方案，然后再考虑一下适当的解决方案。

方案 1：通过 File Serving servlet 服务内容

图 2 显示了所推荐的以一种可伸缩的方式使用 WebSphere Application Server 的拓扑结构。我们顾客的大多数都实现这个方案。Application Server 和 Web 服务器被分开放在不同的物理机器上。

图 2. 分离的 Web 服务器和 Application Server

这个图没有显示（但是暗示了）一个或多个负载平衡路由器（load balancing router），如 WebSphere Edge Server 的网络分派器（Network Dispatcher）组件，或者是 Cisco® 的 Local Director，它均衡整个一组 Web 服务器机器上的请求。这个配置有几个优点：

这个配置考虑到了故障转移。WebSphere ApplicationServer 通过其 Web 服务器插件支持这个配置，这个 Web 服务器插件允许单个 Web 服务器支持多个不同的应用程序服务器，并且还允许单个 Web 服务器支持单个应用程序服务器的多个“克隆”。Web 服务器插件根据 URL 和插件的配置（ plugin-cfg.xml ）文件中的信息，对每一个传入的 HTTP 请求进行检查，并确定将把这个 HTTP 请求转发到哪一个应用程序服务器实例。
这个配置让您在 Web 服务器和 Application Server 间插入了一道防火墙，使得应用程序服务器逻辑和数据更加安全。在这个配置中，Web 服务器驻留在“常用区（demilitarized zone）”即 DMZ 中。

如果您正在使用这个拓扑结构构建一个系统，并且静态文件是逻辑 Web 应用程序的一部分，那么它们是如何被返回到客户机的呢？答案是它们通过 WebSphere Application Server 的缺省的文件服务行为返回的。当一个针对包含在 WAR 文件中的文件（例如，这个文件的 URL 包含在 Web 应用程序的上下文根中）的请求产生时，一个特殊的名为 file serving enabler 的“隐藏的”servlet 便被调用。这个 servlet 将相应的文件从 WAR 文件中适当的目录中取出，然后将它作为这个请求的响应返回。

通过选择应用程序装配工具（Application Assembly Tool）中 Web 模块属性的 IBM extensions选项卡中的 File serving enabled复选框可以启用这个功能。这个复选框在缺省状态下是选中的。相应的条目 fileServingEnabled="true"位于 WAR 文件下的 WEB-INF 扩展中的 ibm-web-ext.xmi 文件中。通过研究 plugin-cfg.xml 文件中相应的条目，您会明白上下文根下的每一个请求都被委派为由 Application Server 服务：

<UriGroup Name="Weather/WeatherProj_URIs">
        <Uri Name="/WeatherProj/*"/>
</UriGroup>

使用这种方法的优点是它很简单。这些文件只被保存在Application Server 文件系统上，因此您不需要将它们保存在 Web 服务器上。然而，这种简单性是以巨大的性能损失为代价的。对于所有由 Application Server 服务的文件来说都需要额外的网络跳数，如图 2 所示。并且使用这种方法服务文件需要 Application Server 做额外的处理工作，这削弱了 Application Server 处理更多重量级的业务逻辑和处理更多事务的能力。

方案 2：在 Web 服务器和 Application Server 之间划分文件

如果您禁用 Application Server 的文件服务功能，那么只有 JSP 和 sevlet URL 由 Application Server 提供服务了。当插件文件被重新生成时， plugin-cfg.xml 中的条目会如下所示：

<UriGroup Name="Weather/WeatherProj_URIs">
        <Uri Name="/WeatherProj/UpdateWeather"/>
        <Uri Name="/WeatherProj/WeatherDisplay.jsp"/>
        <Uri Name="/WeatherProj/DisplayWeather"/>
        <Uri Name="/WeatherProj/*.jsp"/>
        <Uri Name="/WeatherProj/*.jsv"/>
        <Uri Name="/WeatherProj/*.jsw"/> 
        <Uri Name="/WeatherProj/j_security_check"/> 
</UriGroup>

Application Server 已经智能地重新生成了插件文件，以便让 Web 服务器服务静态内容。插件文件将 servlet 和 JSP 的动态 URL 传递回到Application Server。在这种情况下，您还必须配置 Web 服务器来对 WeatherProj 静态 URI 加以识别。在 Apache/IBM HTTP Server 中通过使用诸如以下所示的 Alias 伪指令来很容易地做到这一点：

Alias /WeatherProj/ "C:/IBM HTTP Server/htdocs/WeatherProj/"
Alias / WeatherProj /images/ "C:/IBM HTTP Server/htdocs/ WeatherProj /images/"

请确保在这次更改后重新启动 Web 服务器。仍然存在的问题是，如何将静态内容从 WAR 文件中取出再传递到 Web 服务器中。管理员们想通过可重复的处理来做到这一点以避免错误。这种类型的处理有以下几种可能性：

操作系统 shell 脚本与 FTP 命令结合起来对内容进行解压缩（unzip）（如果所部署的 EAR 还没有被解压缩）并将它们路由到所有 Web 服务器的文档根。构建工具（如 Ant）通过在构建过程中将静态内容放置在它自己的 ZIP 文件中而起了帮助作用。
已经在使用中的智能内容管理软件将这些文档在它们被更新时自动路由到整个网络。

这两种方法中任意一个都可以达到目的，但是应当选择哪一个将取决于您的环境。

不使用 file serving servlet 的可取之处

处理功能已在 Web 服务器和 Application Server 之间分割开来，因此您可以在根据您的站点中动态内容与静态内容的分割情况来变换分配在两者之间的功能总量。如果您的站点服务许多静态内容，那么从许可证发放角度看，这样做是有用的。如果 Web 服务器和 Application Server 执行相同的任务，那么添加更多的 Web 服务器比添加更多的应用程序服务器更合算。

不使用 file serving servlet 的不利之处

从内容管理角度来看，这个解决方案的问题是它变得难以管理。若要部署一个新文件，您需要知晓目标机器。机器也可能会与应用程序服务器上要请求一个不在 Web 服务器上的资源的 JSP 失去同步。

方案 3：Web 服务器、Application Server 和 Caching Proxy

在本方案中，我们将一个 Caching Proxy Server 放置在 Web 服务器前面，如图 3 所示。这个图包含了一个上面描述的负载平衡解决方案。

图 3. Caching Proxy Server

Caching Proxy Server（如 Edge Server 的 Caching Proxy 组件）从一个大的内存或磁盘服务，它们将以前通过其 URL 所请求的静态内容进行高速缓存。某些 Web 服务器也在更加有限的能力内提供了这个功能，如 IBM HTTP Server 中的快速响应高速缓存加速器（Fast Response Cache Accelerator）。

当用户首先请求一块静态内容（GIF、JPEG 和 HTML 文件）时，那么便由其中一个应用程序服务器为这个请求服务（请参见图的最右边）。这个内容在代理服务器中被高速缓存。所有到这个特定 URI（来自任意用户的）的后来的请求都由代理服务器处理。这个内容从高速缓存中被检索，然后返回到用户。这个过程会继续，直到高速缓存条目被基于时间的或基于事件的算法视为无效为止。

对于每一个静态内容来说，这个解决方案明显地比同时通过 Web 服务器和 Application Server 要快。这个解决方案还考虑到了一个更安全的环境，因为您不仅可以在 Web 服务器和 Application Server 间放置一道防火墙，还可以在 IP 喷射器（IP sprayer）前面（也就是在 Caching Proxy Server 后面）放置防火墙。所有的文件都在两道防火墙后受到保护。这样，将文件放置在不安全的区域或 DMZ 中都不会产生问题（在这些区域中文件会被修改而损坏您的 Web 站点，因为被高速缓存的文件只保存在防火墙前面的内存中）。

这个解决方案的不利之处是购买 Caching Proxy Server 并管理它们需要您付出额外的代价。您可以通过减少到后端应用程序服务器的流量来部分地补偿损失，因此可以减小在这些机器上的整体负载。

回页首

不同选项性能开销的样本

为了对以上的方案进行测试，我们配置了三台如下所示的单 CPU UNIX 服务器（每一台服务器的内存为 512 MB）：

Server 1：这台机器配置有 Edge Server，具体来说是 Caching Proxy 组件。我们没有安装网络分派器负载平衡组件，因为我们并不是对服务器组进行测试。

Server 2：这台机器配置有 IBM HTTP Server，其功能相当于我们分离的 Web 服务器。WebSphere Application Server 插件被配置在该服务器上以与 Server 3 进行互操作。

Server 3：这台机器配置有 WebSphere Application Server 高级版 4.01（WebSphere Application Server Advanced Edition 4.01）和 IBM HTTP Server。安装 IBM HTTP Server 是为了对额外的方案进行测试，以说明并列的 Web 服务器和分离的 Web 服务器间的性能差异。一个分离数据库服务器被用于 WebSphere Application Server 管理数据库，这个数据库被认为对于这项测试并不重要。此外，我们安装了 Sun 的 Pet Store J2EE 样本应用程序。这个应用程序可在很多地方得到，并为 Java 开发人员所熟悉。其页面包括图形格式的关于各种宠物的内容，如图 4 所示。

图 4. Java Pet Store

我们使用 IBM 内部负载测试工具（AKStress/IBM Web Performance Tools）来运行我们的测试，这个工具是运行在 IBM Thinkpad T23 膝上型计算机上，它是单 CPU 的基于 Intel 的 Windows® 2000 机器。我们用 50 个模拟的带有四个线程的浏览器（每一个浏览器总共有 500 个页面请求）来运行这台机器。这些测试的持续时间相当有限。建立它们的主要目的是测量服务的静态内容而非典型的事务负载测试，事务负载测试要进行的时间范围较长。我们对以下方案进行了五到十次运行。

找到 Server 3 上的 IBM HTTP Server 实例，Server 3 带有 WebSphere Application Server，由它服务静态内容，并且打开了 file serving enabler。
找到 Server 3 上的 IBM HTTP Server 实例，Server 3 上有 Application Server，但是要关闭 file serving enabler 并且打开 IBM HTTP Server 的 serving static content。
找到 Server 2 上的 IBM HTTP Server 实例，它服务静态内容，并将所有内容都传递回在 Server 3 上的 Application Server。
Server 1 上的 Edge Server 将静态内容高速缓存到 Server 2 上的 IBM HTTP Server，然后再到 Server 3 上的 Application Server（file serving enabler 是打开着的）。
Server 1 上的 Edge Server 将静态内容高速缓存到 Server 2 上的 IBM HTTP Server（它服务静态内容），然后再到 Server 3 上的 Application Server（fileserving enabler 是关闭着的）。

图 5 中用图表示了这些方案。

图 5. 静态内容方案

以下是所有这五个方案的测试结果（也显示在图 5 中）。

测试结果

完成时间（秒） 页／秒 请求数 请求数／秒 1.156.5 3.24 4309.8 27.95 2.99.4 5.03 4329.2 43.56 3.93 5.48 4311.8 47.24 4.94.75 5.29 4345.3 46.00 5.83.4 6.00 4326.4 51.89

图 6. 测试运行结果

尽管这些测试运行是最低限度的，但它们提供了一些有用的数据。首先，用分离的 Web 服务器服务静态内容（这些静态内容来自与 Application Server 分离的机器）明显有好处。正如数字显示的那样，性能有了明显的提高。如果 IBM HTTP Server 与 Application Server 在同一台机器上，或者如果 Application Server 服务静态内容，那么 Application Server 机器的 CPU 利用率比其他几个方案的都高。当 Application Server 不服务静态内容时，CPU 利用率会较低并且在测试运行期间错误也较少。Application Server 机器一般执行紧急任务，这说明最好不要让 Application Server 机器服务静态内容。

另一项重要的研究结果是添加了 Edge Server 高速缓存代理的方案比类似的没有高速缓存代理的方案的性能有所提高。因此，方案 4 比方案 1 明显要快，而在这两种情况下，Application Server 都服务动态内容。这些并不是完全类似的，因为在方案 1 中 IBM HTTP Server 与 Application Server 位于同一台机器上。方案 5 也比方案 3 要快。在方案 3 和方案 5 中，IBM HTTP Server 通过一台与 Application Server 分离的机器对静态内容进行服务。在方案 3 中的情况下，结果虽不太明显，但仍然值得关注。

最后，方案 5 通过结合使用两种关键技术而提供了最优的性能，这两种技术是：从分离的 Web 服务器服务静态内容和使用高速缓存代理服务器。

如先前所述，我们有意将这些测试做得简单以证明一个简单的观点。您不应依赖这些数字作为绝对的真理，而应当计划在自己的环境中用更重、更持久的负载运行更有现实意义的测试。为了确定对于您的环境的最好的方法，您应当添加服务器组和负载平衡器。还有，带有大批可高速缓存的动态内容的应用程序会在动态高速缓存的使用中受益。动态高速缓存是一个您可以只在 Application Server 4.x 中单独配置或者与 Edge Server Caching Proxy 串联配置中的功能。

回页首

选择正确的选项

在什么情况下您会选择每一个先前所描述的选项呢？您如何权衡每一个解决方案的利弊呢？下面一组指导原则可以帮助您对静态内容作出决定：

如果您在 WebSphere 的安装中性能不成什么问题，那么请不要想那些更复杂的设置。将您的静态内容保存在 WAR 文件中然后让 file serving servlet 服务它们会比较容易且更加节省成本。
如果在 WebSphere 的安装中性能是个问题，那么就请将文件解压缩，这样会提高您站点的整体性能。但是，解除打包与替换静态内容可能影响效率，除非这个过程可以通过使用上面提到的技术来重复。
如果您有性能需要，并且有能力支付这项花费，那么从长远看最好的解决方案是使用高速缓存代理服务器。像 WebSphere Edge Server 这样的产品（包括执行诸如负载平衡、动态（JSP/servlet）高速缓存以及内容管理这样任务的组件）可以提供额外的性能帮助。

不论您选择的是哪一个方案，请确保对您特定的应用程序和环境进行一丝不苟的测试以测量不同方法间微小的增益，以确定哪一种方法对于您的环境来说是正确的。

回页首

使用浏览器高速缓存会怎么样？

大多数浏览器用户意识到他们的浏览器可以高速缓存静态内容。有些用户注意到当访问带有相同静态内容的页面时，Web 服务器会返回“304-Not Changed”响应，而非将内容保存起来。这些对于将来从相同用户请求是有用的。在服务器端进行高速缓存的思想是：在第一个用户访问内容之后，接下来的不大可能在他们的浏览器高速缓存中有这些页面的用户可以利用在这个服务器上已被高速缓存的结果。

这导致了到后端应用程序服务器的流量减少。并且，浏览器的缺省状态经常被设置为对从 SSL（HTTPS）连接返回的静态结果不进行高速缓存。您可以对这个设置进行更改以使浏览器的性能更好。

回页首

结束语

本文对将静态内容和动态内容部署到 Web 服务器和应用程序服务器上的几个不同的方案进行了评估。这些测试是粗略的，仅仅是让您大致明白不同方案的作用。每一个开发组织都会通过分割静态内容来对每一个方案的益处和花费进行评估。结果取决于您的站点包含有多少静态内容，您需要多少来自 WebSphere Application Server 储备的处理能力以及上面讨论过的其他因素。最后，您应该将相同的原理应用到 WebSphere Application Server 以后的版本（如版本 5.0）中以及任意一台 J2EE 应用程序服务器上。

回页首

致谢

众作者愿在此对 Tom Alcott、Harvey Gunther、Ken Ueno 和 Cathy Hickey 表示感谢，感谢他们在本文的准备过程中给予了批评与建议。

回页首