| 本文介绍了 IT 专家用于确定其网站能否满足未来需求以及评估网站工作负荷与基础结构变化的方法。同时也介绍了基于对不同组件如何组合才能最好地满足特定工作负荷模式性能目标的分析来配置网站的概念，利用这一概念就可能削减原型设计和强度测试的成本。 本文包括特定的数据和和图形范例，以及您可用来分析用户在在线购物、银行业务和贸易站点上的行为的方案脚本范例。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 电子商务的增长使得以下一点变得至关重要，那就是必须确保支持网站的 IT 基础结构能够为公司的信息、产品和服务提供可用、可伸缩、快捷以及高效的访问。CIO 及其小组面临着前所未有的挑战，那就是必须将停机时间和网络瓶颈降至最低程度，并最充分地利用构成其电子商务基础结构的软硬件。 支持最大容量网站 (HVWS) 的 IT 基础结构一般包括多层机器，常常称为层 (tier)，如图 1 所示。每层包含多台机器（从两台到数百台）来提供该层上所运行功能的容量和可用性。每层提供一组特定的功能，例如提供内容（Web 表示服务器）、提供集成业务逻辑（Web 应用程序服务器）或处理数据库事务（事务和数据库服务器）。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
图 1. 电子商务的多层基础结构 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 虽然复杂性越来越高，但仍可以分析典型的 IT 基础结构并开发相关的模式，以协助对如何满足未来需求作出预测和规划。 容量规划方法 IBM 的 IT 专家一直与 IBM 的多家客户合作，对大型网站进行分析并帮助客户实施可伸缩的网站（请参阅参考资料中的 1）。部分客户已在同 IBM 共同利用和促进开发中的容量规划技术。我们的方法基于这一正在进行的研究（参考资料中的 4、5、6、7、8、9）以及 IBM 的电子商务模式。 我们的容量规划方法基于对多家大型网站（包括 IBM 的网站）的分析，以及我们与那些寻求改进网站性能、精确地规划工作负荷、进行基础结构更改以满足未来需求的的大型客户的不断接洽。该方法包括以下四个步骤：
本文将集中介绍容量规划技术。实施这些技术将影响您的 IT 组织、流程和人员；本文并不涉及这些相关的含义。 我们小组的容量规划技术是对 IBM 的电子商务模式的补充（请参阅参考资料），因为您可以将我们描述的每种工作负荷模式对应到站点设计的一种电子商务模式。无论您使用哪些方法设计您的站点，这种容量规划方法都可作为那一工作的补充，并为管理您的容量需求打下基础。 步骤 1. 确定您的工作负荷模式 因为容量规划主要是大容量网站的问题，所以在本文中我们将假定您的工作负荷容量大而且正在增长，而且需要提供动态数据并处理交易。除此之外，您必须考虑到其他指数，例如交易复杂性、数据变更率及安全性。在进行分析以后，您就可以将工作负荷模式分为 5 类：发布/预订、在线购物、客户自助式服务、交易、或企业对企业。适当地确定您的工作负荷模式可确保我们的方法中的其余步骤获得最佳结果，并使您的网站能最大程度地满足未来的需求。（如果您以前是按我们小组的系列论文做的，则您无须检查工作负荷模式，并可跳至步骤 2。） 请参考以下的工作负荷模式说明（或参阅工作负荷模式概览以了解其本质，并将其汇总到表格中）来确定您的工作负荷模式：
步骤 2. 评测当前站点的性能 在分析您的当前站点时，要记住将网页的设计考虑在内。IBM 的研究表明您可以遵照许多惯例来减少您的网页的下载时间。网页都具有相同的组件和指数，如页面大小和项目数，因此，您可以而且应该着眼于将其下载时间降至 最低程度。做“正确”的事并不是总能成功，而且有些组件或指数是网页设计员无法控制的。另外，对站点性能感兴趣的人员都应该了解这些因素以及其相关的负面 影响。表 1 汇总了 15 个不同网站的页面设计。设计各不相同，但都强有力地表明网页设计是一个重要的性能成分；如果管理得当，则它们可以提高网站的容量。在这个彩色的表中，良好 或优秀的设计标为绿色；稍差的设计标为琥珀色，而很差的设计标为红色。有关优化您的网页以便加快下载的详细信息，请参阅我们小组的前一篇论文，" Design pages for performance"。 表 1. 网页设计范例。绿色表示良好；红色表示很差；琥珀色表示勉强。
合理确定您的工作负荷模式，为评测和了解站点复杂性做好准备。每一种工作负荷模式都有一类相关的用户需求。图 2 显示了与在线购物工作负荷模式相关的用户需求类别范例。 每个类别是按照请求抵达网站的方式以及满足请求所需的资源来划分的。影响抵达的主要因素包括标准（临界）分布、相关性结构和季节性。总之，IBM 的分析表明，复杂行为包括短尾和长尾分布、短距离和长距离的相关性、强季节性和周期性以及地理效应。在这些条件下，站点请求的独立指数输入时间间隔这一典型假定不成立，所以必须采用非传统假定来解决问题，这需要复杂的数学算法。IBM 对这些指数的数学研究使人们能够开发更好的模型，以便了解并预测这些关系和行为的影响。 图 2. 每种工作负荷模式都有相关的一类用户请求  | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分布和相关性 Web 流量显示了突增、长尾和相关的抵达模式。流量突增指请求的随机到达，其高峰期的流量远远超过平均水平。这种突增现象由不可预测的事件（如股市动荡）或特殊 事件（如圣诞节和情人节）引起。这些事件会产生请求间的相关性（例如，更大的突增易于在邻近的地方发生）、长尾分布（例如，流量增长的波动幅度极大）以及 相关性和长尾分布的结合。随机变量的长尾分布是指分布曲线的尾端呈指数下降。对于这些分布，会产生极大一个值。成批抵达过程显示了这种长尾行为，并且成批 请求的大小趋向于密切相关。在容量规划中，获得流量突增、长尾和相关抵达的实际结果并非易事。 突增和变化极大的点击率是影响站点性能和可用性的最显而易见的工作负荷模式复杂性之一。在传统模型中，各个请求相互独立，流量突增幅度的变化相对较小。这些分布属于短尾分布类。HVWS 的流量突增引起了长尾分布和强相关性结构。1998 年长野奥运会的流量模式恰好说明了这一点，如图 3 所示。这种请求突增是由某些特殊事件引发的，例如，在这次奥运会上，日本获得了跳高滑雪项目的金牌。请比较亚洲的长尾分布和当日欧洲的短尾分布之间的差异。另外，请注意每天、一天中以及不同地点间的独立性结构。 图3. 1998 年长野奥运会流量模式  IBM 的 Wimbledon 2000 网站也在最忙碌的一天，2000 年 7 月 7 日，显示出极度突增现象。 图 4 绘制了那天的破记录站点流量，当时的每分种峰值点击次数达到 963,948 次，且每天峰值点击次数总计达到 281,605,872 次。 图 4. 破记录那天 IBM 的 Wimbledon 网站  非传统请求流量对 Web 服务器造成压力。长尾分布的流量突增所产生的性能下降要比短尾分布所产生的性能下降大几个数量级。与短尾模型相比，长尾分布发生极端流量突增的情况更频 繁。另外，相关性结构可导致在邻近的地方发生流量突增现象。对于这种输入流量特性，性能评测结果，尤其是响应时间，与输入流量具有相似的指数。这有助于解 释为什么一些体育和电子商务网站比相对简单的网站（例如只提供静态内容的大学网站）更难维护。 就 SLA 而论，长尾分布的同级服务比独立的短尾请求流量要求具备更为强大的一组服务器。为了确保获得优良的性能，您必须注重流量的高峰期，因为请求的巨增是导致性能降低的首要元凶。这有些繁忙站点需要更多的峰值储备空间（空闲容量）来处理这些容量，例如大容量在线贸易站点用 3:1 的比例来保留空闲容量。 季节性 季节性是指请求模式的周期性。季节流量主要由网站用户的正常日活动量来表示。例如，每天当开盘和收盘时，一些电子交易网站都有一致的交易高峰期和低谷期。季节性流量也可以按月观测，例如，在用户月终付款时，或在指定周期（例如节假日）内。 图 6 显示长野奥运会网站季节性流量范例。该图绘制了从 2 月 9 日到 16 日间每 5 分钟内所有服务器接收的请求数。尽管每天的周期变化很大，但请注意每天包含三个峰值，总体流量密度在每个工作日开始增加，然后在周末减少。这些模式每周反复，说明了与周周期对应的季节性变化。 图 5. 用长野奥运会一周的流量来说明的季节性范例  季节性请求会降低 Web 服务器的性能，因为在高峰期内，同一时间内将会出现大量的请求。关键问题在于这个峰值有多“高”，以及高峰期会持续多长时间。这两个问题的答案对 Web 服务器的功能应有多强才能有效处理特定的 SLA 有极大的影响。为了圆满处理请求流量，Web 服务器的容量应该与峰值请求时的容量接近，并且还要留出一定的峰值贮备空间，以防意外的增长。 确定工作负荷模式的其他因素包括页面浏览量和交易量、搜索的容量和类型、交易复杂性、数据变更率以及安全性考虑。 本节后面的内容将介绍可用来获取完成容量规划所需的评测结果的方法。 获取站点评测结果 每种工作负荷模式都需要特定的评测方法。表 2 提供了一个在线购物站点当前的评测结果方法范例，“当前”的评测结果将用作规划基准。 表 2. 一个在线购物站点的基准评测方法范例
脚本 1. 在线购物方案的脚本范例
图 6. 在线购物访问的转换矩阵范例  步骤 3. 分析趋势并设定性能目标 您的网站工作负荷正在不断增长，当前的设计无论有多么优秀都必须改进 — 同时必须改进的还有构成基础结构的软硬件的能力。在这一步骤中，您要分析趋势以确定未来峰值容量的指数，然后为步骤 2 中确定的每种设计设定目标，并采用适用于未来需求的任何新设计。表 3 提供了一个在线购物站点当前以及规划中的评测结果范例。性能目标一般受业务目标推动，例如：缩短对首选客户的响应时间。 表 3. 一个在线购物站点当前和规划中的评测结果
由于每个关键流量指数都可以在很大的范围内变动，我们使用一套数学方法评估未来请求模式中每种指数的强度，并将其调整到预计的强度（请参阅参考资料中的 4、7 和 8）。然后，我们将这些调整后的数学模型结合在一起，以确定并预测请求模式。通过使用我们的数学方法隔离、确定并预测请求模式中的趋势、相关性、季节效应、随机性和其他关键行为，我们研究出一种一般的方法，这种方法能够比当前采用的其他方法更准确、更有效地预测请求模式。 图 7. 长野奥运会期间一小时内每秒的请求数  我们的方法已被实践证明极为有效，已被用于预测短期和长期的实际站点请求模式。我们特意采用该方法对最近 IBM 主持的体育赛事站点的峰值小时请求容量进行了预测。在过去三年中，我们一直基于网站的请求模式以及 95% 的置信区间来作出评估。在其他方法中，我们采用了一阶变化率方法评估每年的流量密度伸缩因数。我们通过对 1997、1998 和 1999 年的比较得出了指数式增长的趋势。我们还使用 2000 年的预测伸缩因素，并结合我们调整 1999 年峰值小时流量模型的方法，预测出了 2000 年的峰值小时流量模型。结果与我们的预测相符：我们的预测与站点的实际峰值容量非常接近。另外，这些方法在预测将来季节性事件（如圣诞节在线购物高峰）的 请求模式方面也获得了同样的成功。我们还用此方法预测了短期（数天、数周）的请求模式；同样，预测与站点的实际请求模式相当一致。 步骤 4. 确定基础结构替代模型 您现在可以确定构建网站基础结构所需的组件了。现在您已经根据工作负荷模式的特定需求和目标确定了组件（也许在您的顾问或友好全球供应商的解决方案工程师的协助之下）。 IBM 正在为 HVWS 容量规划开发的技术依赖于图 8 中描绘的三种模型。 图 8. HVWS 容量规划模型  业务模型或业务使用模型定义了电子商务模式和工作负荷模式。每种工作负荷模式都有一个用户行为模型。每种工作负荷模式包含几类用户请求。每一类的抵达模式和路由（转换矩阵）站点访问者都包含用户行为模型。满足每类用户请求的软硬件资源和数量包含 基础结构模型。 基础结构模型处理浏览、搜索和购买交易。该模型假定：
 我们设计了一个排队网络的类，用以确定多层体系结构的模型，以便分析不同级别的性能。我们还进一步得出了这些模型在不同输入流量模式和不同时间范围内的多 种解决方案。这一系列数学模型和解决方案非常通用，足以抽象当前软硬件的详细信息，但它同时又非常详细，足以生成有意义的性能结果。我们考虑一下排队系 统，其中每层的资源由多服务器队列模拟，这些多服务器队列之间存在特定的关系。这些关系通过评测或评估的工作负荷指数确定。我们然后根据一组用户需求解决 性能/容量问题，例如并发用户数、响应时间或吞吐率。我们还制定了一个独特的公式，使我们能够评估系统处于以下状态时的行为：峰值需求明显高于平均需求， 而且不可忽略用户访问大量数据的概率。 我们的方法具有极大的灵活性，可根据用户的需求和工作负荷指数确定水平和垂直方向的伸缩，或二者的组合。例如，我们可以通过添加另一台服务器，或者在指定服务器上添加另一个处理器来增加 Web 服务器的数量。有了适当的网站和工作负荷数据，我们就能够根据我们的性能模型和分析得到性能评估。 我们已为多家 IBM 托管的网站制定了容量规划。图 10 就说明了这样一个网站，并反映了采用当前的网站数据，然后根据当前的数据、趋势和目标制定规划来校正我们的模型的过程。在图 10 中，前三个响应时间曲线反映了用于按步骤 2 中的方法校正模型的当前数据。通过分析当前的设计和组件信息，我们就可以对第四条曲线进行规划。 参考图 10，结果显示当请求流量较小时，一台前端服务器已足以处理负载。随着流量的增加，响应时间曲线保持平直，直至该前端 CPU 的利用率达到 90%（每小时 280 万次点击）为止。这时，负载的少量增加就会导致系统很快死机，前端服务器以越来越低的速度尝试处理越来越多的文件，这样几乎没有人能感受到令人满意的响应时间。这意味着前端服务器已成为瓶颈。因此，我们需要添加前端服务器，添加以后前端服务器的 CPU 利用率就会按我们的预期下降。响应曲线变成平直状态，直至前端服务器的 CPU 利用率重新达到 90%（每小时 510 万次点击），这时我们需要考虑添加另一台前端服务器。只有当大约 15 台前端服务器每小时处理约 2800 万次点击时，后端服务器才会成为瓶颈。 图 10. WebSphere 商务网站的伸缩  图 11 中的图形是我们在分析特定软硬件组件的性能目标时得到的范例。 图 11. 显示性能指数的图形范例。  小结 大容量网站的有效容量规划是一件棘手的事情，但并非不可克服。我们在本文中提出的方法可以指导您了解工作负荷模式和当前设计，分析趋势，设定未来的目标，并最终选择能够满足您性能目标的 IT 基础结构组件。分析特定工作负荷模式环境中的站点要求的能力对您作出正确的选择很有帮助。 当然，容量规划的课题还需继续研究。越来越多的有价值的信息可供您使用（请参阅参考资料中的 10），令人振奋的新工具正在不断出现，而且按需求提供容量的选择也将极大地增强对流量增长作出反应的能力。IBM 的 HVWS 着眼于发现并总结现代的设计方法，以提供更大的容量和可伸缩性。该小组将继续改进它的方法，开发包含该方法的工具，调整数学方法，并致力于诸如网络高速缓存和快速增长的企业对企业工作负荷这类领域所提出的更多挑战。在满足未来需求的同时有效规划并降低成本的前景十分广阔。 参考资料（序号与正文的引用对应）
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
冯晓凯 2010-12-27
Good
请 登录 后发表评论
