网格应用程序的性能 —— 找到最佳状态

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Marlon Machado (mmachado@us.ibm.com), 高级实现架构师

2004 年 9 月 01 日

当您用策略 1、2 和 3 对启用网格的应用程序进行调整时，本文教您的这种简单方法，可以帮助您在单位任务和结果集之间取得平衡。这三种策略是 David Kra 在 developerWorks 上发表的系列文章中定义的。

简介

网格计算正在企业中发展壮大，这要感谢遵循 developerWorks 系列文章 “ Six strategies for grid application enablement”中描述的启用策略 1、2 和 3 在已有应用程序中的网格启用。

正如在所有的新兴计算领域内一样，我们期望在不久的将来看到更多的集成（或启用）工作，然后完整地迁移到基于 SOA 的世界中。（有关 SOA 的更多信息，请参阅 developerWorks 的 SOA and Web services内容专区。）

集成任务通常需要进行调整。为了实现调整，您可以在最高层上将被集成的系统想像成一个黑盒。这样您就可以先致力于对系统的输入流（任务单元）和输出流（结果集合）的大小与结构进行调整。当您将已有的应用程序集成到面向批处理的网格基础设施中时，由于很多情况下实际的产品是与平台相关的，因此不能够调整，这时上面的方法就特别有用了。

除了输入输出之外，集成的系统中还有很多方面也会出现性能的瓶颈。这些瓶颈中的大多数都是与特定产品和技术相关的，解决这些问题超出了本文的讨论范围。一般情况下，一种产品或技术在集成系统中是否成为瓶颈，这依赖于它在系统中的角色，以及与系统中其他部分交互的情况。在启用网格的应用程序中，您可能遇到性能瓶颈的领域包括共享文件系统、网络、与其他不兼容系统（常见的是 SAMBA）之间的连接器、数据库、许可管理器、安全机制等等。随着时间的推移，我们将学会如何解决这些技术中的共有问题。

不过现在，还是关注一下大多数集成系统在实现前三种启用策略时都会遇到的高层性能问题吧。

回页首

启用场景与性能概况

图 1 展示了两种类型的网格基础设施软件，它们分别适合用于较低和较高级别的网格启用。

如图所示，面向批处理和基于 SOA 两种网格基础设施软件的分离定义了适用不同网格采用程度的网格启用场景的类型。同时还有助于为每一种场景定义性能特征。

选择何种启用场景？

一般情况下，用最低的三种网格启用策略在已有应用程序中启用网格，这在大多数情况下是一种 部署场景。而在另一方面，如果在面向 SOA 的网格基础设施软件中启用应用程序，则需要从底层开始构建面向服务的应用程序，这是一种 架构与编程场景。两种场景具有各自不同的特征。

什么是性能特征？

性能特征一词指的是一个系统在面对变化的负载条件时表现出的整体行为。性能特征是一种模式。打个比方，如果进入的工作负载的增加以一种一致的可以预测的方式转变为 CPU 利用率的提高，那么我们可以说这个系统具有 CPU 密集型的性能特征。这里， 系统一词所指的是具有多个节点的网格。

下一节我们将从整个系统的层次检验一下部署场景的性能特征。

回页首

较低层的性能

在每一种部署条件下，性能特征中都具有调整系统性能的核心要素。就像所有的“可调节”系统一样，让这些核心要素具有最佳的组合，系统就能够以最大的性能运行。

当您在面向批处理的网格基础设施产品中部署已有应用程序时，关键的要素有下面这些：

• 任务单元—— 用于将用户的信息通过客户机驱动程序和网格基础设施软件传递给应用程序。这就是批处理作业 —— 即包含了供给应用程序的参数的信封。任务单元可以用简单的文本文件或 XML 编写，也可以是数据库表。只要应用程序知道如何读取，可以采用任何格式。
• 结果集—— 在各个节点上由通过网格基础设施提交的每一项批处理作业产生。这就是应用程序的输出，即根据提供给应用程序的参数获得的信息。结果集与任务单元一样，可以是任何形式，只要用户能从中提取出信息即可。

回页首

任务单元与结果集之间的关系

一般情况下，部署场景的性能特征体现了每一次作业提交中产生的三种类型的任务：

1. 任务单元的处理—— 通常由作业提交驱动程序执行。
2. 应用程序运行—— 由部署在网格节点上的应用程序执行的实际工作。
3. 结果的聚集—— 将来自每一个网格节点的单个结果集组合成一个更大的结果集，然后将其送回用户。

因此，系统的整体性能可定义为：

P = A - U - R

P 是系统表现出来的黑盒性能。 A 是应用程序的性能（这是一个常量）。 U 代表对任务进行结构化处理所需的工作。 R 是创建最终的结果集所需的工作。

为什么应用程序的性能是常量？

当已有的应用程序按照策略 1、2 和 3 在网格上启用运行时，这个应用程序通常是与特定平台相关的程序，它将批处理作业作为输入信息。那么，假定在更坏的情况下，我们认为无法使它在网格中运行时的裸性能比在单台机器上运行时更高。

这一假设是成立的，因为在很多情况下，为应用程序启用网格的原因并不是要让一个程序运行得更快。在很多场景中，为已有应用程序启用网格背后的想法是让它在多个节点上并发运行。这也正是我们假定 A 为常数的理由。

U 和 R 情况如何？

U 的值依赖于需要输入数据的节点个数。 U 也依赖于将任务单元划分成包以满足网格基础设施的传输协议（如 WSDL 封装的 SOAP/HTTP 等）的需要，以及将输入数据传递给网格节点之前对其进行平整（如数据序列化等）的需要。

一般来说，对于任意的 n 个节点， U 的定义如下：

U = n(u) + w

这就意味着生成 n 个任务单元所需的工作总量等于生成单个子任务单元所需的工作量 u 乘以节点数目 n ，再加上所有与节点数目无关、可能用于支持整体部署的工作 w 。

对于 R ，我们可以假设一种最好的情况，其中生成单个结果集 r 所花费的代价与生成单个子任务单元所花费的代价 u 。如果我们能够从单个子任务单元中生成两个、三个、甚至多个结果集，那就好了。不过没有人能有那种运气。因此，在上述条件下，我们可以说对于任意 n 个节点， R 的定义如下：

R = n(r+g) + w

其中 w 仍然是所有与节点无关但与支持整个环境有关的工作， g 是将单个结果集聚集成这项作业最终结果集所需的工作。

请记住， w 和 g 的值是与应用程序的特性、实际使用的网格基础设施软件以及网格部署的拓扑结构有关的。换句话说， w 和 g 可能是任何值。我们挖掘这一因素的原因在于，您应该了解需要搜集多少数据，才能在创建任务单元和结果集时估计不同类型的工作量。因此，如果您尚未配备好的监视工具，就一定要弄一个。

现在我们可以开始寻找最佳状态了。

回页首

寻找最佳状态

一般情况下，对任务单元和结果集的处理与应用程序实际要执行的任务无关。这项工作是应用程序启用网格带来的副作用。因此，我们需要避免这项附加任务给系统的整体性能带来的压力，至少应使其最小化（请参阅 表达式 1）。无论如何，我们的想法是尽可能无缝和透明地实现网格启用。

因此，处理原则非常简单。根据生成任务单元和结果集的本质，以及表达式 1， P 的值越高，性能就越好。这意味着我们应该使 U 和 R 尽可能接近于零。换句话说，我们启用网格时应该不付出代价；不需要在生成任务单元和结果集方面进行投资。然而实际情况并非如此。

我们所能够做的就是让网格任务与环境任务相隔离，然后在这两者之间找到平衡。这也就是最佳的状态。

识别网格任务与环境任务

理想情况下，您需要将所有与处理任务单元和结果集的任务隔离在网格节点之外，如图 2 所示。这样您就可以有效地从网格基础设施任务中分离出应用程序的任务，并使您清晰地了解系统的性能特征，以便进行调整。相信我，不这样您就无法对系统进行调整。

如果您再次检验一下图 2，您将发现，首先将任务单元划分成子作业的工作既可以由用户完成，也可以由作业提交驱动器来完成。这就意味着 U 可能完全发生在网格之外。

如果我们用表达式 2 中定义的 U 来表示一下图 2 中的场景，就能很容易地推断出， n(u) 对应于作业提交驱动器用于生成所需数目的子作业的工作量。同时我们可以看出 w 至少表示将用户或门户提交的原始任务单元传递给作业提交驱动器所需的工作量。

其次，您可以看到，将结果子集聚集为单个结果集的过程出现在聚集器一级，别无它处。然而，如果您详细看看就会发现，生成并聚集结果集所需的工作量实际上分离为网格本身（ r ）、环境（ w ）和结果聚集器（ g ）三部分，其中每一部分都位于网格之外。

现在，让我们看看到现在为止所获得的信息意味着什么。首先将表达式 1、2、3 组合起来，根据所代表的任务类型重新排列一下结果表达式中元素的顺序。得到的结果如表达式 4 所示。

P = [ A - n(g) ] - [ n(u+r) + 2w ]

表达式 1显示，性能是流入系统中的数据的函数。表达式 4 从另一方面将性能描述为系统需要完成的任务特性的函数。

表达式 4 中有一个 与网格有关的因数 G ，其定义为 G = A - n(g) 。 G 由两部分构成：一部分是常数（ A ），另一部分与生成结果子集的节点个数有关。同时，表达式 4 还包括 与环境有关的因数 E ，它描述了 u 和 r 之间的关系： E = n(u+r) + 2w 。

想看数学推理过程... 下面是导出表达式 5 的实际过程。 首先从表达式 1 开始，用表达式 2 和 3 将与网格有关的任务和与环境有关的任务分别放在一起。 P = A - U - R P = A - [ n(u) + w ] - [ n(r+g) + w ] P = A - n(u) - w - n(r+g) - w P = A - n(u) - n(r) - n(g) - 2w P = [ A - n(g) ] - [ n(u+r) + 2w ] 现在可以有效地识别这两部分：与网格有关的元素和与环境有关的元素，并用它们来定义系统的性能。 下面一步是应用一个一般性的假设，比方说我们需要在与网格有关的任务和与环境有关的任务之间找到平衡点。请记住，对于 A 我们无能为力。因此在最坏的情况下我们的最佳策略（同时也是基本假设的一部分）就是试图将我们所做的所有工作最小化（请参阅 表达式 1）。 在这样的情况下，我们所做的一切就是希望整体性能不会下降。这意味着我们希望 P = A ，也就是说我们希望 G - E = A 。如下： G - E = A A - n(g) - E = A -n(g) - E = 0 n(g) = -E n(g) = -n(u + r) - 2w 对公式进行化简，最后得到表达式 5，它很好地体现了 u 和 r 之间的关系与平衡。

再次假设一种最差的情境， A 保持不变，然后返回最初的策略，寻找网格任务和环境任务之间的平衡。下面的表达式 5 体现了生成和处理单个子任务单元和单个结果集的工作量之间的最佳状态。

回页首

含义解释

上面公式的意思非常简单：生成单个结果子集的代价等于生成并处理相应的单个任务子单元的代价，加上将任意单个结果子集聚集成最终结果集的代价，再加上实现任务单元和结果子集处理的工作量除以执行任务的预期节点数。

您的脑子有些晕吧？不要紧。表达式 5 中体现的最重要的信息是，用结果子集花费的资源代价来估计在应用程序中启用网格的成本。

您也可以把表达式 5 解释成为将任务单元划分成多个更小的子任务单元所付出的性能代价。这一点可从下面的表达式 6 中体现出来。

表达式 6 表示，您为任务单元所付出的代价将分布在网格和周围环境中。它提供了一种方式来体现比例，体现对给定数目的任务单元生成结果集的成本。

回页首

结束语

我们已经讨论了在简单批处理、独立并发批处理或并行批处理等部署场景下为应用程序启用网格时的一般情况。然后又分析了部署场景中的典型性能特征，并识别出定义性能特征的三种任务类型。

接下来，我们用表达式 1 所体现的一种简单数学模型描述了这种性能特征。我们用这个模型，并根据最坏情况下的假设，在任务单元和结果集之间找到了一个平衡点。我们称这个平衡点为 最佳状态，并分别用为应用程序启用网格的代价（表达式 5）以及将系统输入划分成更小的子作业所付出的代价（表达式 6）对它作了描述。

所有这些都意味着，不论何时发现自己在用策略 1、2 或 3 为已有应用程序启用网格，只要在确定网格输入信息的粒度之前，都必须从资源利用的角度考虑它给结果的生成造成的影响。

表达式 5 提供了一种可视化的方法，从性能的角度体现出单个结果子集的成本。您接下来面临的调整就是估计下面这些数据的平均值：

• 生成子任务单元的成本（ u ）。
• 聚集结果子集的成本（ g ）。
• 实现这一切所需的额外工作（ w ）。

您可以使用监视工具来搜集数据，以便对 w 和 g 的值进行估计，用什么单位描述它们都可以，只要能够描述出您所寻求的性能即可。您可以使用 Mbps、每秒请求数、每分钟事务数，以及任何您认为有意义的单位。

我希望这种简单的方法能帮助您更好地处理启用网格的环境在重负载之下的性能。请您记住，这种方法只对用策略 1、2 和 3 启用网格的应用程序有效。我们还要继续研究架构与编程场景，这样就可以为基于 SOA 的网格启用项目提供更简单的方法。好心情和好运与您同在！

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 您希望学习的系列文章“ Six strategies for grid application enablement”（ developerWorks，2004 年），作者 David Kra。
  
  
• “ 在已有应用程序中启用网格”（ developerWorks，2004 年 6 月）向您展示了，在与特定平台有关的分布式应用程序（包括单点应用程序和模块化应用程序）中启用网格，以及在应用程序（包括以 servlet 为中心的和以数据库为中心的）中启用 Web 时需要考虑的问题。
  
  
• 阅读“ 网格中的带宽管理”一文（ developerWorks，2003 年 9 月），了解如何从网格中获得最佳性能。
  

关于作者

		1996 年，Marlon Machado 作为一名 ISSC 组织（现在是 IBM 全球服务部门）的程序员在乔治亚州亚特兰大加入了 IBM。在那里他从事了多种与分布式架构相关的项目。1998 年，Marlon 加入了位于德州奥斯汀的 SanFrancisco Technology Center。后来，他成为了 IBM ISV and Developer Relations 的一名实现架构师（Enablement Architect），现在他在公司的职位更高了。Marlon 是“Think Grid”的作者和首席教师。“Think Grid”是 IBM Innovation Center 在全球提供的高级开发人员训练营。Marlon 生活在德州奥斯汀和洪都拉斯美丽的加勒比海岸，不过他的大多数时间都穿梭于世界各地，为 IBM 的 ISV 合作伙伴提供协作。可以通过 mmachado@us.ibm.com与他联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首