服务器能力计算

系统处理能力TPC估算方法

1 TPC 标准介绍

在对系统进行方案设计时, 通常会遇到以下问题：

a) 配置什么样的服务器设备?

b) 系统性能如何?

c) 系统能够满足多长时间的应用?

单凭历史经验给出一个经验值来评估整套系统显然是不够的, 必须拿出足够的理论证据来证明设计中已考虑到了上述问题。通常, 采用TPC 的基准测试来衡量硬件服务器的处理能力, 同时, 采用通用计算公式估算软件所需的处理能力。

1.1 TPC

TPC 是由数10 家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放, 但迄今为止,绝大多数会员都是美、日和西欧的大公司。TPC 的成员主要是电脑软硬件厂家, 而非电脑用户, 它的功能是制定商务应用基准程序的标准标准、性能和价格度量, 并管理测试结果的发布。

TPC 的测试结果和出版物是开放的, 可以通过网站( : // https://www.360docs.net/doc/cf19065643.html,) 获取详细信息。IBM、NCR、HP、SUN 等国际著名服务器供给商均是TPC 会员,这些公司旗下的产品均会在网站上公布TPC 的测试结果。目前, 国内的工程项目中大量采用了上述公司制造的服务器类产品, 因而这些数据对于设计阶段的性能估算很有参考价值。至今, TPC 已经推出了4 套基准程序( TPC- A、TPC- B、TPC- C 和TPC- D) 。其中TPC- A 和TPC- B已经过时, 不再使用。TPC- C 是在线事务处理(OLTP) 的基准程序, TPC- D 是决策支持的基准程序。目前, 工程设计中常见的系统均为在线事务处理型( 包括BSS、OSS 和OA) , 因此TPC- C 基准测试是本文关注的重点。

1.2 TPC- C 基准测试

TPC- C 是一种旨在衡量OLTP 系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多数据专业设计人员将TPC- C视为衡量“真实”OLTP 系统性能的有效指示器。TPC- C 基准测试是对硬件处理能力的考核标准。TPC- C 通过模拟一个批发商的货物管理系统,衡量硬件服务器的性能指标( 查询、统计功能的执行效率) 。TPC 对具体的测试环境, 也做了详细的规定。

1.2.1 测试环境

批发公司有W个仓库, 每个仓库供给10 个地区, 其中每个地区为3 000 名顾客服务。每个仓库中有10 个终端, 每个终端用于一个地区。在运行时,10×W 个终端操作员向公司的数据库发出5 类请求。

1.2.2 逻辑和流程

该系统需要处理的交易有以下几种。

a) New- Order: 客户输入一笔新的订货交易。

b) Payment: 更新客户账户余额, 以反映其支付状况。

c) Delivery: 发货( 模拟批处理交易) 。

d) Order- Status: 查询客户最近交易的状态。

e) Stock- Level: 查询仓库库存状况, 以便能够及时补货。

从上述定义可见, 数据库在逻辑上是分布的。而W 是一个可变参数, 测试者可以随意改变W, 以获得最正确测试效果。图1 示出的是TPC- C 测试逻辑结构图; 图2 示出的是TPC- C 测试流程图。

1.2.3 评测指标

TPC- C 基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务吞吐量。按照TPC 的定义, 流量指标tpmC 描述了系统在执行Payment、Delivery、Order- status、Stock- Level 这4 种交易的同时,每分钟可以处理多少个New- Order 交易。所有交易的响应时间必须满足TPC- C 测试标准的要求。最终的测试结果会在TPC 的网站上公布, 可以免费查询到绝大部分的系统测试结果。测试信息包括tpmC 得分、系统配置清单、测试环境以及日期等, 内容非常详尽。

2 服务器处理性能估算

2.1 估算方案

在方案设计之前, 必须详细了解用户需求, 特别关注以下几点。

a) 系统的设计使用年限。

b) 系统平均用户在线人数( 访问量) 。

c) 系统忙时, 用户的主要操作行为统计( 估值) 。

d) 软件开发商应提供的功能架构, 并能提供每个功能所引发的事务处理量。

e) 系统采用的操作系统和数据库平台。

在充分采集系统信息后, 可对系统所需服务器性能进行3 个方面的估算。

a) 数据服务器处理能力估算。

b) 应用服务器处理能力估算。

c) 存储容量估算。

值得指出的是, 应用服务器和数据服务器是2个不同的概念。应用服务器提供访问商业逻辑的途径以供客户端应用程序使用。数据服务器主要负责计算和数据存储。在大型系统中应用和数据会独立使用各自的服务器, 降低服务器压力并尽可能保障数据安全和独立。

2.1.1 数据服务器性能估算

测算服务器在忙时的数据库访问峰值(X) , 代表主机处理峰值应能到达每秒X 个连接; 每个连接平均需要访问Y 个数据表。每个数据库访问相当于服务器Z 的处理能力。数据服务器处理性能( Ls) 的估算公式为

Ls=XYZ/( 1- β) /γ( 1)

式中:

X———用户连接数(连接/s)

Y———数据表连接数

Z———数据访问值( tpm)

β———系统自身消耗值, 取值范围为25%~35%

γ———系统忙时比例因子, 取值范围为60%~80%

2.1.2 应用服务器性能估算

1) 方法一: 估值计算

应用服务器处理性能( Ly) 的估算公式为

Ly=Lsα( 2) 式中:

α———综合系数(见表1)

2) 方法二: TPC 公式计算

TPC 建议使用式( 3) 估算所需处理能力。假定在系统发出的业务请求中, 位列前三项的功能( 如查询、更新、统计功能等) 分别命名为A、B、C, 则应用服务器需要的处理能力为

Ly=U1N1( T1+T2+T3) /3XY/Z ( 3) 式中:

U1———系统同时在线用户数(人)

N1———平均每个用户每分钟发出业务请求次数(次/人)

T1———平均每次A业务产生的事务数(次)

T2———平均每次B业务产生的事务数(次)

T3———平均每次C业务产生的事务数(次)

X———一天内忙时的处理量和平均数的比值

Y———经验系数(实际量和估算量的比值)

Z———服务器冗余值

方法一和方法二均为常用的处理能力估算方法。方法一更为简便, 但相对方法二缺乏说服力和准确性。因此, 建议尽量使用方法二进行估算。

2.1.3 存储容量估算

系统的存储空间主要包含4 大内容数据。

a) 软件系统自身所需安装空间。

b) 系统运行环境所需安装空间( 操作系统、数据库软件、其他第三方软件等) 。

c) 系统运行产生的数据。

d) 系统日志所需空间。

实际存储容量(G) 计算公式为

G= 〔(AB+F) ×365C/1 000 000〕+D+E

( 4)

设计存储容量(Gs) 计算公式为

Gs=G( 1+Z)

( 5)

式中:

A———每条记录占用存储空间(Byte/条)

B———每天产生的记录条数(条)

F———每天系统日志占用空间(Byte)

C———设计使用年限(年)

D———软件系统自身安装空间(GByte)

E———运行环境所占安装空间(GByte)

Z———存储冗余

通常情况下, 为了确保数据安全性, 系统备份时会将数据存放在其他独立的备份设备中。因此, 在存储容量估算中暂不考虑系统备份所需的容量需求。

通过前面3 个步骤的计算, 就能大致掌握系统数据服务器、应用服务器以及存储容量上需求值。结合TPC 网站上公布的测试数据和厂商提供的相关设备的tpmC 数据, 就能做出比较明确的判断。同时, 计算数据也是设备选型和设备配置的重要设计依据。2.2 案例分析

某建设单位委托设计一套基于B/S 技术的传输资源管理系统。通过采集用户需求并咨询相关软件开发商和硬件厂商, 获取了以下信息。

a) 系统设计使用年限5 年。

b) 项目实施后, 用户之间可以通过系统查询现网的传输架构和资源使用情况。同时, 用户可以定期统计传输资源使用情况并及时更新系统信息。

c) 估算系统平均用户在线人数100 人。

d) 软件开发商提供的系统参数, 包括主要功能操作所产生的事务处理个数、每条记录占用的存储空间等信息。

e) 软件指令行数估计20 万行左右。

f) 数据库系统为Oracle 9i, 并采用RAC 方式。

特别说明, 该项目采用Oracle 9i 数据库平台,并使用真正应用集群(RAC) 方式。RAC 是Oracle 9i数据库中采用的一项新技术, 也是Oracle 数据库支持网格计算环境的核心技术。使用该技术能大大提高数据处理效率并降低安全风险, 是目前最为流行的数据库平台之一。RAC 技术能使多个服务器上的多个Oracle 实例同时管理一个数据库, 因此必须配置2 台以上数据服务器组成数据集群。综合用户需求、厂商建议和机房勘察结果, 拟选用1 台服务器作为应用服务器, 2 台数据服务器组成数据集群, 以满足Oracle 9i RAC 的需要。

图3 示出的是系统逻辑拓扑图。

在掌握基础数据后, 根据上一章介绍的估算方案对数据服务器、应用服务器和存储容量进行需求量计算。

2.2.1 数据服务器TPC- C 计算

每秒峰值为6 000 连接/s, 即主机处理峰值应能到达6 000 连接/s; 每个连接平均需要10 个数据表访问, 按照经验, 每个数据库访问相当于服务器3~4tpm 的处理能力。系统本身要消耗30%的系统资源( 厂商提供参考值) ; 系统忙时比例因子为70%( 厂商

提供参考值) 。将上述值代入式( 1) 有:Ls=6 000×10×4/( 1- 30%) /70%=489 796因此, 数据库双机系统TPC- C 要求大于或等于500 000 tpm, 考虑实现Oracle 9i RAC 后, 双机性能约是单机的1.8 倍, 因此, 单机TPC- C 值不能小于500 000/1.8≈278 000 tpm。

2.2.2 应用服务器TPC- C 计算

1) 方法一: 估值计算

本系统程序指令行数约为20 万行, 属于中型系统。根据式( 2) , 可得到应用服务器所需处理能力。

Ly=500 000×0.5=250 000 tpmC

2) 方法二:

TPC 公式计算系统最大同时在线用户数为300 人; 估算平均每个用户每分钟发出

3 次业务请求; 系统发出的业务请求中, 更新、查询、统计各占1/3; 平均每次更新业务

触发10 个事务; 平均每次查询业务触发15 个事务; 平均每次统计业务触发30 个事务; 一天内表2 建议配置表忙时的处理量为平均值的8 倍; 约定经验系数为1.6( 实际工程经验) ; 服务器冗余值为30%。根据式( 3) , 可得到应用服务器所需处理能力。Ly=300×3×( 10+15+30) /3×7×1.6/0.7≈264 000 tpm方法一和方法二计算的结果比较接近, 建议采用较大的值作为最终估算结果。

2.2.3 存储容量计算

传输资源管理系统中主要存统计报表数据以及日志管理信息。在已经考虑了数据冗余的前提下, 约定: 每天每个功能模块生成20 个统计报表; 目前系统共有10 个功能模块; 每条报表记录平均占用存储空间300 B; 每年的预算数据存储容量需求为21.9GB; 每月的日志数据存储容量需求为0.1 GB; 设计使用年限为5 年; 软件系统自身安装空间为1 GB;运行环境所占安装空间为5 GB ( 包含操作系统和数据库) ; 存储冗余为30%;

全年总共所需存储容量为：21.9+12×0.1+1+5=29.1 GB

5 年存储容量为：5×29.1×( 1+0.3) =189.15 GB

2.2.4 配置说明

完成数值估算后, 建议把计算结果以表格的形式进行归纳总结( 见表2) , 方便用户查阅。

总结：系统处理能力TPC 估算方法是一种工程参数结合经验参数的通用计算方法。但是, 由于计算公式涉及的参数较多而且一些参数为经验值, 计算的结果仅能作为系统配置和选型的参考。尽管有这些不足, 基于TPC- C 标准的系统处理能力估算仍不失为一套简单有效的系统性能计算方法。