Web体系结构发展规划

表 3. 一个在线购物站点当前和规划中的评测结果

准确预测请求模式的能力是容量规划的重要要求。我们的预测技术部分基于构建一套数学方法和模型，这些方法和模型用来分离并确定网站请求模式中的趋势、相关性、季节效应、随机性以及其他关键行为（请参见参考资料中的 4、6、7 和 8）。例如，这包括与长尾分布组合在一起的分段自回归移动平均 (ARIMA) 的使用。图 7是准备用于我们的模型的请求模式范例；该图显示了长野奥运会网站 1 小时内每秒接收到的请求数。从这些结果中拟合出的曲线显示在数据点中间。

由于每个关键流量指数都可以在很大的范围内变动，我们使用一套数学方法评估未来请求模式中每种指数的强度，并将其调整到预计的强度（请参阅参考资料中的 4、7 和 8）。然后，我们将这些调整后的数学模型结合在一起，以确定并预测请求模式。通过使用我们的数学方法隔离、确定并预测请求模式中的趋势、相关性、季节效应、随机性和其他关键行为，我们研究出一种一般的方法，这种方法能够比当前采用的其他方法更准确、更有效地预测请求模式。

图 7. 长野奥运会期间一小时内每秒的请求数

我们的方法已被实践证明极为有效，已被用于预测短期和长期的实际站点请求模式。我们特意采用该方法对最近 IBM 主持的体育赛事站点的峰值小时请求容量进行了预测。在过去三年中，我们一直基于网站的请求模式以及 95% 的置信区间来作出评估。在其他方法中，我们采用了一阶变化率方法评估每年的流量密度伸缩因数。我们通过对 1997、1998 和 1999 年的比较得出了指数式增长的趋势。我们还使用 2000 年的预测伸缩因素，并结合我们调整 1999 年峰值小时流量模型的方法，预测出了 2000 年的峰值小时流量模型。结果与我们的预测相符：我们的预测与站点的实际峰值容量非常接近。另外，这些方法在预测将来季节性事件（如圣诞节在线购物高峰）的 请求模式方面也获得了同样的成功。我们还用此方法预测了短期（数天、数周）的请求模式；同样，预测与站点的实际请求模式相当一致。

步骤 4. 确定基础结构替代模型
您现在可以确定构建网站基础结构所需的组件了。现在您已经根据工作负荷模式的特定需求和目标确定了组件（也许在您的顾问或友好全球供应商的解决方案工程师的协助之下）。

IBM 正在为 HVWS 容量规划开发的技术依赖于图 8 中描绘的三种模型。

图 8. HVWS 容量规划模型

业务模型或业务使用模型定义了电子商务模式和工作负荷模式。每种工作负荷模式都有一个用户行为模型。每种工作负荷模式包含几类用户请求。每一类的抵达模式和路由（转换矩阵）站点访问者都包含用户行为模型。满足每类用户请求的软硬件资源和数量包含基础结构模型。

基础结构模型处理浏览、搜索和购买交易。该模型假定：

• 网站有多层机器，每一层处理特定的一组功能，如图9所示的站点。
• 负载均衡器（如网络调度程序）采用一种算法将请求发送给多个前端 Web 服务器，以在这些服务器之间平均分配请求。
• 前端 Web 服务器处理对静态或动态网页的请求。
• Web 应用程序服务器处理请求所启动的交易的业务逻辑。在图9中，帐户和报价服务器是应用程序服务器。
• 后端数据库服务器处理对动态网页的请求，这些网页涉及获取和更新信息；这类请求不通过负载均衡器返回。
  

图 9. 多层网站（不包括防火墙层）

我们设计了一个排队网络的类，用以确定多层体系结构的模型，以便分析不同级别的性能。我们还进一步得出了这些模型在不同输入流量模式和不同时间范围内的多 种解决方案。这一系列数学模型和解决方案非常通用，足以抽象当前软硬件的详细信息，但它同时又非常详细，足以生成有意义的性能结果。我们考虑一下排队系 统，其中每层的资源由多服务器队列模拟，这些多服务器队列之间存在特定的关系。这些关系通过评测或评估的工作负荷指数确定。我们然后根据一组用户需求解决 性能/容量问题，例如并发用户数、响应时间或吞吐率。我们还制定了一个独特的公式，使我们能够评估系统处于以下状态时的行为：峰值需求明显高于平均需求， 而且不可忽略用户访问大量数据的概率。

我们的方法具有极大的灵活性，可根据用户的需求和工作负荷指数确定水平和垂直方向的伸缩，或二者的组合。例如，我们可以通过添加另一台服务器，或者在指定服务器上添加另一个处理器来增加 Web 服务器的数量。有了适当的网站和工作负荷数据，我们就能够根据我们的性能模型和分析得到性能评估。

我们已为多家 IBM 托管的网站制定了容量规划。图 10就说明了这样一个网站，并反映了采用当前的网站数据，然后根据当前的数据、趋势和目标制定规划来校正我们的模型的过程。在图 10 中，前三个响应时间曲线反映了用于按步骤 2 中的方法校正模型的当前数据。通过分析当前的设计和组件信息，我们就可以对第四条曲线进行规划。

参考图 10，结果显示当请求流量较小时，一台前端服务器已足以处理负载。随着流量的增加，响应时间曲线保持平直，直至该前端 CPU 的利用率达到 90%（每小时 280 万次点击）为止。这时，负载的少量增加就会导致系统很快死机，前端服务器以越来越低的速度尝试处理越来越多的文件，这样几乎没有人能感受到令人满意的响应时间。这意味着前端服务器已成为瓶颈。因此，我们需要添加前端服务器，添加以后前端服务器的 CPU 利用率就会按我们的预期下降。响应曲线变成平直状态，直至前端服务器的 CPU 利用率重新达到 90%（每小时 510 万次点击），这时我们需要考虑添加另一台前端服务器。只有当大约 15 台前端服务器每小时处理约 2800 万次点击时，后端服务器才会成为瓶颈。

图 10. WebSphere 商务网站的伸缩

图 11 中的图形是我们在分析特定软硬件组件的性能目标时得到的范例。

图 11. 显示性能指数的图形范例。

小结
大容量网站的有效容量规划是一件棘手的事情，但并非不可克服。我们在本文中提出的方法可以指导您了解工作负荷模式和当前设计，分析趋势，设定未来的目标，并最终选择能够满足您性能目标的 IT 基础结构组件。分析特定工作负荷模式环境中的站点要求的能力对您作出正确的选择很有帮助。

当然，容量规划的课题还需继续研究。越来越多的有价值的信息可供您使用（请参阅参考资料中的 10），令人振奋的新工具正在不断出现，而且按需求提供容量的选择也将极大地增强对流量增长作出反应的能力。IBM 的 HVWS 着眼于发现并总结现代的设计方法，以提供更大的容量和可伸缩性。该小组将继续改进它的方法，开发包含该方法的工具，调整数学方法，并致力于诸如网络高速缓存和快速增长的企业对企业工作负荷这类领域所提出的更多挑战。在满足未来需求的同时有效规划并降低成本的前景十分广阔。

文章来源于领测软件测试网 https://www.ltesting.net/