英语原文共 7 页，剩余内容已隐藏，支付完成后下载完整资料

部署问题: 配置应用程序服务器性能和可靠性

Mukund Raghavachari Darrell Reimer Robert D. Johnson

国际商业机器公司 T.J. 沃森研究中心

19 天际线驱动, 霍桑, 纽约 10532

raghavac@us.ibm.com

摘要

J2EE的框架旨在通过处理大量并发性，事务和持久性管理的复杂性来简化开发企业应用程序的过程。 支持这样的框架的应用服务器实现了这些关注, 解放应用程序开发人员，使他们专注于实现应用程序的业务逻辑方面的任务。 在这样的框架中, 部署者, 配置应用程序服务器的个人使管理可以同时发生, 交易和持久性是正确有效的, 起核心作用. 部署者几乎没有帮助执行这个复杂任务的工具. 不正确的配置可能导致应用程序故障或严重不足. 我们概述了应用程序部署者所要面临的问题, 提出了一种可以帮助程序员完成配置应用程序服务器的任务的方法, 并提出两个案例研究，验证我们的方法论的有用性。

1 介绍

大型业务应用程序的开发可能涉及许多问题 - 并发管理，事务管理，持久性，安全性，演示，业务逻辑等。例如J2EE [8] 的框架旨在通过支持分离问题来简化此过程[7]。应用程序开发人员可以主要专注于实现应用程序的业务逻辑方面; 部署应用程序的应用程序服务器处理了大部分复杂的并发性，事务性和持久性的管理。在这个框架下，部署者，配置应用服务器并正确的，有效的地管理并发性，事务性和持久性的个人，起着核心的作用。

几个因素相结合，使部署者的任务变得复杂。首先，部署者必须很好的了解应用程序的语义学。例如，应用程序决定了哪些数据必须持久化到数据库。部署者的职责就是配置应用服务器的持久性管理以配合应用程序所需的语义。甚至拥有关于应用程序结构和行为的良好文档（这在实践中很少见），部署任务并不简单。我们将在本文的案例研究中看到，应用程序中对持久性数据的访问之间的微妙交互会影响应用程序服务器的配置。

第二，与应用程序交互的硬件和软件系统可能会显着影响其部署。应用服务器，运行的操作系统，网络特性，与之通信的后端数据库和/或旧式软件，机器的数量和系统的拓扑都会影响应用程序的可用并发和持久性功能。例如，应用服务器的配置根据后端数据库是专用还是共享的不同而不同。

最后，应用程序的工作量可能会影响应用程序服务器的配置。工作负载决定应用程序的哪些方面将被最多地使用，并且有多少并发是被需要的。预测工作量的能力不仅在调整系统方面是至关重要的，并且在确定系统的拓扑结构时，有多少机器用于运行应用程序，数据库的功能需要多大等等。

目前，部署者几乎没有任何可用的工具。应用服务器设计灵活，因为它们的性能取决于许多外部因素-应用程序语义，硬件/软件配置，工作负载；部署者提供了旋钮来调整应用程序服务器的所有组件。部署者可用的其他工具是根据使用情况数据建议配置的最佳实践指南[6,5]和基于规则的分析器（基于最佳实践）设置的。随着业务应用程序部署经验的增加，这些指南和剖析器的复杂性也在不断提高，这些指南和剖析器的复杂性已经有了很大的提高，但是它们面临着一个根本的问题。最佳做法是启发式，不可能涵盖整个应用程序空间，硬件/软件拓扑和工作负载。我们将在本文中提出案例研究，其中应用服务器的最佳配置与最佳实践建议相冲突。

没有足够的工具，应用程序服务器就使用经验法则，直觉和试验和错误的混合进行配置。不正确的配置可能导致应用程序失败或性能不佳。由于应用程序失败的自然趋势是在应用程序中承担错误，因此基于配置的问题通常难以追踪。

在本文中，我们专注于在给定硬件/软件拓扑和工作负载的情况下为应用程序配置应用程序服务器的问题。我们开发了一种解决应用服务器参数正确配置问题的工具/方法。本文的目标是三个方面：

1.在J2EE框架中部署应用程序时，介绍配置应用程序服务器时遇到的一些问题. 更多地采用J2EE和框架（如.NET和Web服务）使得开发工具可以帮助这些系统中的部署者至关重要。

2.去描述我们为便于部署任务而开发的工具/方法。

3.提供案例研究，验证工具/方法的有用性。

2 电子商务拓扑的简析

应用服务器部署的常规拓扑如图1所示。Web服务器（或HTTP服务器）用于将来自互联网的请求定向到应用服务器。应用程序服务器连接到企业数据持久化的后端数据库。

基于J2EE的应用服务器的结构如图2所示。应用服务器通常以Java本身编写，因此整个系统在一个或多个Java虚拟机（JVM）中执行。应用服务器相对于演示，业务逻辑和数据层而进行分区。Web容器对应于表示层。它管理着与Web服务器的交互。浏览器请求通过Web服务器路由到Web容器，其中返回静态HTML页面或启动Java Server Page（JSP）或Servlet的执行。JSP或者servlet可以反过来与业务逻辑层交互，最终合成返回给用户的HTML。Web容器通过控制一次可执行多少个线程来确定servlet的并发性。

图1.传统的基于J2EE的应用服务器部署的结构。

图2.基于J2EE的应用程序服务器的结构。 箭头描绘配置参数可能会影响行为的点。

EJB容器对应于业务逻辑层。 容器管理部署在服务器上的企业Java Bean（EJB）的创建和执行。 此外，它控制EJB的事务性行为，并发性和缓存。 它还控制EJB与数据源的对应关系，数据源与数据层对应。 数据源是数据库的抽象。 它管理连接池中与数据库的连接，以避免创建连接的昂贵操作。 当EJB不再需要连接到数据库时，而不是关闭连接，它将连接返回到池中以供以后重用。 此外，数据源维护一个语句高速缓存，用于降低处理频繁执行的SQL语句的成本。

为了本文的目的，我们将集中在一小部分配置参数中，这些配置参数在表1中列出和描述。

表1.本文中考虑的应用服务器配置参数

3 应用服务器配置

一般来说，应用程序的部署者面临的问题如下：部署者有一定数量的资源 - CPU时间，内存，I / O - 必须分配给应用程序服务器的组件。 理想情况下，部署者可以使用分析模型来确定资源的适当分配。 对于在实践中发现的业务应用程序，分析模型的推导很困难，原因如下：bull;应用程序是复杂的，分布式的和多线程的，其中系统组件之间的交互无法被轻易识别。

不同的硬件和操作系统对于线程，JVM性能等都有不同的性能特征。

服务器的性能可能取决于外部因素，如数据库负载，网络拥塞等。

应用程序服务器的组件不是独立的。 将更多的CPU资源分配到Web容器将导致执行更多的servlet，这反过来又会对EJB容器和数据库上的EJB造成更大的需求。

此外，由于应用程序必须部署在服务器上才能进行压力测试，所以部署者的任务变得复杂。因此，当应用程序出现故障或表现不佳时，很难确定问题的正确来源 - 应用程序错误或部署错误。鉴于这些障碍，部署者通常依赖直觉，经验和最佳实践来将资源分配给应用程序服务器的不同组件。当这些失败时，确定和解决问题的原因是耗时且昂贵的。

在本节中，我们提出了一种简单的方法，用于确定使用此方法的良好配置和案例研究。

3.1 寻找良好配置的方法

我们发现在确定应用程序部署的良好配置值方面有用的方法如下：

1. 对于感兴趣的每个配置值，选择一个合理的范围。例如，对于JVM堆最大值，我们可以选择256-512 MB的范围。
2. 对于感兴趣的每个配置值，从步骤1中为其选择的范围生成随机值。
3. 使用步骤2中生成的一组配置值部署应用程序。
4. 驱动应用程序服务器的工作负载和测量性能特征，例如响应时间和吞吐量。
5. 必要时重复步骤2-4。我们将参考执行步骤2-4作为运行的实验。

该方法的目的是随机探索配置空间，并从结果中学习应用程序的特性，配置值之间的交互以及良好的配置集。为了使我们的方法成功，应用程序必须有一定的一致性，也就是说，给定配置的性能表现不会很大。当应用程序满足此要求时，性能发生变化。

表2.感兴趣的每个配置参数的值的范围。

跨运行可归因于配置值更改的影响。然后可以使用诸如多元回归的统计技术从运行结果中推断出有用的信息。我们现在将使用两个案例研究来证明这种方法的实用性。

3.2 案例研究 - 制造应用

我们首先研究一个模拟制造公司运营的应用程序。应用程序和工作负载驱动程序是独立开发的，我们的任务是将应用程序部署到应用程序服务器上。

在表2中，我们列出了我们考虑的每个配置参数的值的范围。这些被选择来涵盖对于这样的应用被认为是合理的价值范围。我们已经开发了一种在配置空间中生成随机点的工具，使用这些配置值部署应用程序，为应用程序服务器驱动工作负载，并以自动化方式记录吞吐量和响应时间。随机配置值的生成执行简单的一致性检查，例如，Web容器线程池的最小值小于最大数量。一次运行所需的时间约为15分钟，其中12分钟用于驾驶工作量。

我们的部署拓扑如图3所示。我们在单独的机器上在同一台计算机和数据库（DB2 7.2 fixpack 5）上运行Web服务器（IHS 1.3.19）和应用程序服务器（WebSphere 4.03）。应用服务器和数据库机器是一样的机器。我们详细描述了应用程序的结构，以指导我们。

如前所述，第一步是验证应用程序对给定配置的确定性行为。我们使用相同的一组配置值进行了15次实验，发现了低方差在运行吞吐量（stdev / mean = 1.1％）。

1.6 Ghz IntellistationM-Pro，2GB RAM Linux 2.4.9-12

图3.实验中使用的硬件配置

图4显示了具有不同组配置参数的25次运行的结果。从图中可以看出，应用服务器的配置可以对性能有实质的影响。获得的最大吞吐量是最小吞吐量的14倍。事实上，应用程序的行为似乎是双峰的 - 峰值和低谷相当一致。为了更好地解释这个差异的原因，我们将重点关注这个行为的原因的两个参数：EJB容器线程池大小和数据源连接池的最大值。

在图4b中，我们将吞吐量作为最大数据源连接池大小与EJB容器线程池大小之间的差异的函数。可以看出，当数据源连接池的最大值大于EJB容器线程池大小（区别是正数）时，系统的吞吐量是好的。当相反的时候，系

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[488238]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

您可能感兴趣的文章

• 现代单元结构在压缩载荷作用下的影响外文翻译资料
• 水下浇口凸轮衬套注塑模设计与分析外文翻译资料
• 机械微机械加工的最新进展外文翻译资料
• 考虑尺寸效应的物料流动特性建模外文翻译资料
• 智能移动机器人的无人监督人体活动分析外文翻译资料
• 手臂的视觉感知操纵着触觉的体验快感外文翻译资料
• 稀土元素对6061铝合金真空钎焊接头组织和性能的影响外文翻译资料
• 定向凝固铝硅镁共晶合金的组织、力学和电学特性研究外文翻译资料
• 机床进给传动装置外文翻译资料
• 数控机床工业设计方法的研究及其实现和应用前景外文翻译资料