＋设为首页 ＋添加到收藏夹
简介 【程序编程相关:入乡随俗: 为 DB2 进行开发】
【推荐阅读:带有 DB2 UDB 表的 ASP.NE】 评估新应用所需要的计算资源通常是一件非常困难的任务,因为规划这些资源的获得及部署必须与应用程序的开发平行进行.这个任务对于使用单一中央服务器的客户/服务器应用已经相当困难,对于有多个服务器的分布式系统,比如企业复制网络（er）,就更困难了.虽然使用凭经验得来的配置规则与/或当前在企业中运行的其他类似应用程序的知识可以对一些较小规模的系统进行评估,但是要规划一个成功的 er 网络应用程序,则需要一些可以用来对可衡量的需求进行准确预测的性能特征数据. 【扩展信息:ADO.NET 和 Borland Da】本文将展示如何使用在少数系统上收集到的性能数据预测所计划的 er 网络的可扩展性与系统使用率.用一个经过修改的 tpc-c 工作负载作为在 集中的 与 分散的er 使用模型中的应用程序.本文展示了启用与没有启用 er 的系统的性能水平,以及将服务器加入到 er 网络中时资源使用率的变化.最后的结果是对使用这个工作负载时 er 可以扩展到什么程度的评估,并讨论了如何通过增加更多的计算资源来提高性能.
案例分析
使用经过修改的 tpc-c 应用程序作为工具,我们将给出在一个小规模的系统上收集数据的测试案例的结果,然后用它预测一个 er 网络的可扩展性.特别是,我们将考察如何利用收集到的数据来规划有大量节点的网络的需求,以达到所希望的性能与可扩展性水平.尽管这里所举出的例子是相当简单的,但我们的目的是帮助您深入了解这个过程,以便可以将其应用到其他更复杂的网络拓扑与使用模型中.下面是对我们测试案例的每一部分的特定细节与要求.应用程序
我们使用了一个从 tpc-c 基准测试程序 ( www.tpc.org/tpcc/)变化而来的应用程序进行性能测试工作,tpc-c 基准测试程序是一个著名的.用于联机事务处理(oltp)使用模型的性能基准测试程序.它有几种特性是性能测试所需要的,可以利用这些特性对它进行扩展与分割.但是,为了在 er 环境下使用这个应用程序,需要在模式级别与应用程序级别上对源代码进行一些修改.首先,我们需要对模式中的每一个表引入主键.这使表可以通过 er 复制（在3.9 版的 informix? dynamic server? (ids)中为 er 设计了一个增强,它将消除让用户指定主键的需要.相反每一行都将有一个服务器指定的惟一识别符,er 可以使用这个惟一标识符作为主键）.其次,我们需要增加一些外键约束以保证引用完整性,因为这样更能代表真实世界应用程序架构.主键与外键约束产生了一些隐含索引,这影响了不同事务的性能.只要多创建两个显式索引就可以提供与真正的 tpc-c 基准测试程序模式相等的一组索引.然而,增加的引用完整性约束对性能有显著的影响,所以不应该将测试结果与任何发表的基准测试结果进行比较.
集中与分散模型
在本案例分析中使用的集中模型利用了 er 的层次路由（hr）功能（在 ids 7.31.uc4 .9.20.uc2,以及以后的版本中提供）.这里假定有一个大的根服务器带有很多叶子节点,它们通过 er 向它传送事务.在我们的案例中,数据库在逻辑上分到了很多叶子上,根服务器包含数据库中所有数据的拷贝.这样,事务应用到叶子上,然后复制到根上.这样,根就是这个应用程序的"集中的"服务器.集中模型的反面是分散模型.在 分散模型下,根服务器将事务应用到数据库上,然后再通过 er 复制到叶子节点.对于这两种模型, 图 1 显示了这种分布式系统的连接情况.图 1. 简单的集中或分散使用模型的典型节点布置
对于这些简单的集中与分散模型可以有很多种变化,其中包括:
使用多个根服务器以得到冗余 同时将事务应用到根服务器与叶子服务器上,以得到结合的效果 在层次中加入非根服务器,以便在更多的地点（可能是一个区域总部）提供数据库（或子集）的副本.有关对 hr 功能的更完全的描述请阅读本文的姊妹篇"deployment planning for informix enterprise replication" （informix企业复制的部署计划）,该文作者为 steven miller,刊登在« tech notes»1999 年第 4 期第 9 卷上.在本文中,我们将让被检查的工作负载与使用模型尽量简单,以便使分析更加直观.然而,可以将这篇文章所描述的技术推广到更复杂的使用模型与网络拓扑上.
业务问题
... 下一页