眼看巨浪来袭，生还的惟一希望是相信直觉，这样才能安然度过灾难。当处理令人头疼的应用程序响应时间时，具有数百名终端用户的企业或许会发现自身正处于上文所述的类似境况。应用程序部署以后随时可能会出现用户不满浪潮，特别是在您对自身的基础架构不自信
眼看巨浪来袭，生还的惟一希望是相信直觉，这样才能安然度过灾难。当处理令人头疼的应用程序响应时间时，具有数百名终端用户的企业或许会发现自身正处于上文所述的类似境况。应用程序部署以后随时可能会出现用户不满，特别是在您对自身的基础架构不自信，并且部署前没有花时间运行相关压力测试的情况下。
近期的趋势和技术文章1 表明，如果企业选择关系管理系统 (RDBMS) 但却不了解 RDBMS 如何或者是否能够正常升级，随着用户负载的不断增加问题可能会接踵而至。然而，许多软件编辑器（包括 Cisco Systems 和 SugarCRM）现已考虑向自身支持的平台添加 IBM® Informix®，因为其他 RDBMS 编辑器已无法提供足够的性能和稳定性。如今在技术论坛中，有关将各种 RDBMS 实施项目迁移至 Informix 的相关问题出现得越来越频繁。
运行 IBM Informix 的企业发现产品升级行之有效，但事实上还有一些用户从未留意过饱受压力的 Informix 的 CPU 消耗量，近年来也未发布过真实的统计数据。为什么不呢？是由于竞争对手要“埋没”Informix、缺乏与竞争对手产品的实际性能对比数据，还是普遍而言的市场冷漠性？答案无关紧要；重要的是要确定基础版本的 IBM Informix 的每个联机事务处理 (OLTP) 应用程序平均能够承受多少个终端会话。
事务处理性能 (TPC) 委员会负责发布 DBMS 基准评估的规范、场景和结果。该机构会遵循“尽可能贴近现实生活”的准则，制定不同类型的 DBMS 基准以设置等级。
当前的 TPC 基准包括 TPC-C、TPC-E 和 TPC-H，但 TPC-C 是最具代表性的 OLTP 活动基准。虽然用户可以在 Internet 上找到大量开源 TPC-C 运行程序，但其中绝大部分均以 Java 语言编写。下列测试采用的运行程序由西班牙巴利亚多利德大学团队开发、由 Diego Llanos 教授负责管理，用来与 IBM Informix 执行运行对比测试。
测试目标
由于未采用 TPC 委员会颁发的正式 TPC-C 副本且未获 TPC 委员会批准，因此这项测试不能作为 TPC-C 官方基准。然而，测试过程中严格遵循 TPC-C 基准制定的所有规则。基本上，这项操作已对 Informix Innovator-C 运行压力测试，以便指出单一 Informix 服务器上能够同时运行多少个终端会话（即事务监视器中运行的 TPC-C 用户会话）。
预备步骤与选定配置
首先使用源代码启动操作，只需很少成本。以下是基准测试的必要准备步骤：
1) 依据以下规格安装基于 Linux 的服务器（Fedora 14，内核 2.6.35.14 x86_64）：
单插座 Intel 四核 Q9400（四个 2.66 Ghz 处理器）
16 Gb DDR-2 RAM
四个 500 Gb SATA II，7,200 rpm 磁盘驱动器
请注意，上述配置成本低于 900 欧元。
2) 在 Linux 服务器上安装和配置 IBM Informix Innovator-C Edition。
Innovator-C Edition 是免费的，所以没有成本。所选的版本是 11.70 FC4。
3) 采用巴利亚多利德大学推出的 TPC-C 应用程序（最初在 PostgreSQL ESQL/C 开发）以运行 IBM Informix。这项任务相对轻松，因为根据 Informix 服务器机制调整对 PostgreSQL 进行修改是整个任务的主要修改。此外，最初的数据库创建语句已经过优化，以便充分利用 RAW 表和预处理语句。同样，这项基准测试不会测量数据库加载语句，因此加载时间越短越好。
4) 编译和调试应用程序。
5) 优化 Informix。
6) 运行测试，逐渐增加压力直到出现系统性能下降。严格遵循 TPC-C 规则，确保测试通过。
IBM Watson
IBM Watson文字转语音
20 查看详情 
基准规则
即使是开展非官方测试，也必须遵循以下规则：
不要修改数据库模式。TPC-C 数据库包含九个表，每个表均包含预定义结构、经过确认的索引和完整性约束。不得修改、添加或删除其中任何元素。
不要修改表的基数。表基数均存在严格的规则限定；例如，一个仓库将托管 100,000 个项目，一个区将包含 3,000 名客户等。
不要修改事务的应用程序代码。TPC-C 采用五个不同的事务，旨在反映典型 OLTP 应用程序的运行状况：新订单、付款、交货、订单状态和库存水平。最后一项指标包含非索引列的查询数量（不同的）和 WHERE 子句，因此需要施加少许压力放置数据库引擎。
各事务类均规定了最大允许响应时间。对于各事务类，至少有 90% 的事务必须按照如下方法执行。如果出现负值，则测试失败。
各项测试均包含等候（或预热）时间和测量时间（性能测量间隔）。等候时间有助于服务器适应不断增长的负载，这样即可在性能稳定时过渡至测量时间。
检查点间隔没有制定确切的规则，只是规定测量时期内必须至少测试一个检查点。这在使用 Informix Innovator-C 时根本无关紧要，因为检查点仅会阻止极少量的事务。本测试采用 15 分钟间隔，现实系统也是采用这一间隔。
磁盘实施也没有任何规则。同一 SATA 控制器上的全部四个 SATA II 7,200 rpm 磁盘全部得到应用，从而尽量准确地平衡各表和索引的位置。
同一台计算机上的所有 Informix Innovator-C 实例共享内存量均限制在 2 Gb。此项测试完全使用这 2 Gb，同时还要预留 SHMVIRTSIZE 空间，以便执行排序及类似操作。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/481216.html
微信扫一扫 
支付宝扫一扫 
